Hey folks, thanks for your valuable insights! Here's what I conclude from there:
Not a blockchain
"Interledger is not a blockchain, a token, nor a central service. Interledger is a standard way of bridging financial systems. " (interledger.org/rfcs/0001-interled...) => perfect then.
I am not obtuse to blockchain as a technology but I think sharing content on the web is not a use case critical enough to deserve spending massive amounts of energy (neither is speculation but that's another topic:)). Let's keep the web sober.
Static vs client-side rendering
Ok so it seems that page-level staticness is not a fit for Web Monetization. I should instead treat it similarly to videos, 3D, interactive charts, and all those things you don't care about server-rendering.
The pattern I propose is still a good fit for rendering page skeletons efficiently, but web monetized content should be considered as client-side rendered islands within the page.
Right now I am testing Capri, which I recommend a lot because contrary to other static site generators, it doesn't try to involve its own custom specific templating language and stick to React or Vue. It is Vite based and can already provide an island architecture. It's limited to static content but can be a good fit in certain scenario.
I can't wait for Next.js to land server-side components, which will allow to develop similar architectures with mainstream technologies.
Loading encrypted data
About loading encrypted data, I think I would use that as an optimistic pattern like this:
1) user has Web Monetization installed? Get the encrypted data
1b) user doesn't have Web Monetization installed? Get nothing
2) successful payment stream start? Decrypt the data
Because if you load encrypted data systematically you pay a lot of bandwith. I am not sure this is actually doable though.
For further actions, you may consider blocking this person and/or reporting abuse
Hey folks, thanks for your valuable insights! Here's what I conclude from there:
Not a blockchain
"Interledger is not a blockchain, a token, nor a central service. Interledger is a standard way of bridging financial systems. " (interledger.org/rfcs/0001-interled...) => perfect then.
I am not obtuse to blockchain as a technology but I think sharing content on the web is not a use case critical enough to deserve spending massive amounts of energy (neither is speculation but that's another topic:)). Let's keep the web sober.
Static vs client-side rendering
Ok so it seems that page-level staticness is not a fit for Web Monetization. I should instead treat it similarly to videos, 3D, interactive charts, and all those things you don't care about server-rendering.
The pattern I propose is still a good fit for rendering page skeletons efficiently, but web monetized content should be considered as client-side rendered islands within the page.
Right now I am testing Capri, which I recommend a lot because contrary to other static site generators, it doesn't try to involve its own custom specific templating language and stick to React or Vue. It is Vite based and can already provide an island architecture. It's limited to static content but can be a good fit in certain scenario.
I can't wait for Next.js to land server-side components, which will allow to develop similar architectures with mainstream technologies.
Loading encrypted data
About loading encrypted data, I think I would use that as an optimistic pattern like this:
1) user has Web Monetization installed? Get the encrypted data
1b) user doesn't have Web Monetization installed? Get nothing
2) successful payment stream start? Decrypt the data
Because if you load encrypted data systematically you pay a lot of bandwith. I am not sure this is actually doable though.