Hey everybody,
I am new to Web Monetization, but a seasoned full-stack developer. I've started by digging the documentation thoroughly.
Bear with me, this posts is long but if you are into web development you wont be disappointed.
Exclusive content demo with client-side computations
As you may already know, the example implementation considers some exclusive content, that would be revealed only to paid users using Web Monetization API.
The naive implementation shows a client-side only version with JavaScript, which is of course unsafe.
A more advanced implementation relies on a system of receipt. I am still trying to grasp it but I get a rough idea of the architecture.
Source: https://webmonetization.org/docs/exclusive-content/
Usual implementation
It turns out that I've studied extensively the use case of exclusive content, from the web developer perspective.
Usually, you will use either client-side rendering (so JavaScript in the browser), or per-request server-side rendering (think PHP) to handle this display.
This is because you need to figure out if the user is paid everytime you display the page.
Client-side you can use the Web Monetization API, server-side you need to process each request to check for payment.
A static version
I've designed a pattern named "Segmented Rendering", which rely on static rendering instead.
You render at build time a paid version and a free version of your page, once for all
You select which version to display using a tiny redirection server. Hosts like Vercel and Netlify have edge runtimes that are a perfect fit for this.
This article describes an implementation with Next.js: https://blog.vulcanjs.org/render-anything-statically-with-next-js-and-the-megaparam-4039e66ffde
This article from Plasmic also describe a similar approach for A/B testing: https://www.plasmic.app/blog/nextjs-ab-testing
I've got an article waiting for publication that precisely targets the use case of exclusive content within a web page.
Eco-friendliness
The main takeaway is that this architecture is more performant and most probably more energy efficient than traditional client-side rendering SSR.
I say most probably because I am an honest person: we lack empirical study to definitely prove this, a lot of factors are involved in real life. But the mathematics says it does less computations.
With CSR/SSR, the same exclusive content delivered to 1 billion people means 1 billion expensive computations.
With Segmented Rendering, for 1 billion people, you have only 1 expensive computation, done in advance at build-time.
You still need a redirection for each request.
However this redirection happens at the edge. JavaScript edge runtime are lighter than Node.js and located near the end user, reducing the global impact of the request. It costs less than running a React server-render or hitting your main server, and (most probably again) will therefore cost less energy.
Where things are getting complicated
Now, I have a few question:
- Can Web Monetization be used during server-side rendering?
As far as I understand, the HTTP request might contain information that I can in turn use server-side to confirm that the user is a paid user, and then serve the content? It's not the easiest part of the architecture so if anyone has open source code samples of this even in other programming language it would help a lot.
- If yes, can Web Monetization be used using only HTTP requests server-side?
Edge runtimes are more limited than traditional Node.js server, they are not meant to handle persistent connection (yet). I wonder if we can check if a user is a paid user with just very basic JavaScript and "fetch" API to a distant server.
- Where's the crypto???
This architecture only makes sense if Web Monetization isn't itself consuming tons of energy, to the point that my rendering issue would be insignificant.
When reading Web Monetization documentation, my brain screams "at which step are they going to sell me some crypto crap"?? It's a caricature but you get the point: is the ecological impact of Web Monetization as it is currently implemented already known or measured, at least in terms of energy consumption? are there expensive computations involved or does it require its own nuclear plant to properly work? is it better or worse than current architectures (advertisment based business models for instance)? etc.
Thanks in advance for your answers, references and feedbacks, so far I've been enthusiastic about what I've discovered when reading Web Monetization. I hope to be able to produce a cool Next.js implementation if everything goes as I expect.
Top comments (7)
Hey Eric, these are good questions, I hadn't thought about how WM works on the server side for static sites.
Prototypr setup is next.js too, and uses Next static site generation, so I'll have a look too and let you know!
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.
Those are great questions. Let me take a stab at them:
Hopefully that answered some of your questions, and let me know if you have more. I think what you're trying to do here is super cool, and I'd love to help if I can.
Thanks for the mention @chrislarry! Can't believe I miss this post. Turns out many wants to figure out WM on Jamstack sites too!
First of all - Welcome to the community Eric! 👋 Just noticed you joined very recently!
I love your take on how computing at once at build time and only rely on redirect to serve paid content since that kind of efficiency is really my thing - which is something that I really dig in my project ProgNovel. I also was exploring premium content on static data previously, but since receipt verification server was too slow for production I settled only with hiding premium content with JavaScript. I will try exploring deeper on this later after new WM spec rolls out once the API becoming more stable.
As for my findings when exploring premium content in Jamstack environment, I'll try recall them:
@laka @vineel check this out
Welcome Eric!
@radhyr you might dig this post