3 ms·

Thanks for coming to this thread, I'm curious what the other person meant though. Yes, there is a stack and heap limiting the amount of resources that a comman

Thanks for coming to this thread, I'm curious what the other person meant though. Yes, there is a stack and heap limiting the amount of resources that a command can use. So what? Design your application with that limitation in mind. Focus on what you can control, its a one-step one-click funnel that is inherently a payment and insatiable demand right now from the users. A Web 2.0 dream, I've sat through so many useless OKRs and KPIs meetings trying to figure that out, and now its just here for any individual willing to look, apply the same concepts and use it. What do you mean about the amount of reads can be played with? I don't see how it matters. You can read the state of a smart contract or any account for free. Not really sure how this is a point.

kovek 4y ago
I didn’t understand you. But, imagine a DDOS attack on the nodes serving the blockchain. I don’t see why “pay once read forever” works financially.
- vmception 4y ago
  > But, imagine a DDOS attack on the nodes serving the blockchain. Okay. > I don’t see why “pay once read forever” works financially. A separate issue thats not really your problem. Its the node operators problem. When your use case expands to that being a viable problem for you, then you'll need to become a node operator or at least keep a copy of the state yourself. You can design applications around that. Or maybe you can't. Just rule those out or keep using AWS or some other company for those applications?
HideousKojima 4y ago
>Focus on what you can control, its a one-step one-click funnel that is inherently a payment and insatiable demand right now from the users right now is the really, really big issue here. We're talking about pay once read forever, not pay once read right now, or pay once and read while there's still interest or demand in running nodes.
- vmception 4y ago
  Can you elaborate on what your concern/criticism/cynicism is? What use case are you trying to imagine? I think its been very easy and very competitive to design applications around using these redundant blockchain nodes as event-driven compute nodes, when compared to AWS Lambda or even addons to a paid Vercel plan or hosting my own microservice somewhere. The uptime has been on-par and the system design gives some assurances of the ability to maintain the uptime where it could theoretically be a concern.

kovek 4y ago

I didn’t understand you. But, imagine a DDOS attack on the nodes serving the blockchain. I don’t see why “pay once read forever” works financially.

vmception 4y ago
> But, imagine a DDOS attack on the nodes serving the blockchain. Okay. > I don’t see why “pay once read forever” works financially. A separate issue thats not really your problem. Its the node operators problem. When your use case expands to that being a viable problem for you, then you'll need to become a node operator or at least keep a copy of the state yourself. You can design applications around that. Or maybe you can't. Just rule those out or keep using AWS or some other company for those applications?

HideousKojima 4y ago

>Focus on what you can control, its a one-step one-click funnel that is inherently a payment and insatiable demand right now from the users right now is the really, really big issue here. We're talking about pay once read forever, not pay once read right now, or pay once and read while there's still interest or demand in running nodes.

vmception 4y ago
Can you elaborate on what your concern/criticism/cynicism is? What use case are you trying to imagine? I think its been very easy and very competitive to design applications around using these redundant blockchain nodes as event-driven compute nodes, when compared to AWS Lambda or even addons to a paid Vercel plan or hosting my own microservice somewhere. The uptime has been on-par and the system design gives some assurances of the ability to maintain the uptime where it could theoretically be a concern.