The Interledger Community 🌱

Cover image for Optimal implementation of the exclusive content demo
Eric Burel
Eric Burel

Posted on

Optimal implementation of the exclusive content demo

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.


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:

This article from Plasmic also describe a similar approach for A/B testing:

I've got an article waiting for publication that precisely targets the use case of exclusive content within a web page.


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)

graeme profile image

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!

ericburel profile image
Eric Burel • Edited

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. " ( => 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.

laka profile image
Alex Lakatos

Those are great questions. Let me take a stab at them:

  • Can Web Monetization be used during server-side rendering?
    • Not really. Or at least not while it's being shimmed by an extension. The future browser implementation can send those details on the HTTP request. This way, the extension isn't part of the initial page request, and can only access the contents of the tab it after the GET request initiated. Monetization only starts after the page is loaded, rendered, and a meta/link tag with a valid payment pointer has been found on page. The delay can be a few seconds until that happens. What you're looking for here might be more along the lines of returning a 402 Payment Required status.
  • If yes, can Web Monetization be used using only HTTP requests server-side?
    • This use case doesn't feel like Web Monetization - streaming payments for content continuously while I consume the content. It feels like a single time payment for content. There are other options for that use case. Web Monetization wasn't designed for that use case.
  • Where's the crypto???
    • There's no crypto. That's why you're having a hard time finding it. Web Monetization uses the Interledger network to send the money. I understand the "ledger" in the name makes some people think of crypto, but in here it refers to what a ledger used to be before it was appropriated by crypto: a book of accounts that records transaction. By that definition, a bank, a mobile money provider or a financial institution is a ledger. Even Starbucks is a ledger (you have an account with them, it holds some of your money, and it records your transactions). Interledger was created to provide a bridge between all these disconnected places where we store money. There are a bunch of reasons why this is happening, worthy of a whole blog post on itself. Actually, I have a talk that goes deeper into this -

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.

radhyr profile image
Radhy • Edited

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:

  • Like Alex Lakatos said, currently, you can only know which paid users client-side, once the real money starts streaming. So more traditional redirects between paid and free contents in form of JSON or any returned data from backend/serverless might be more useful than picking a redirect between two different version of web pages in Netlify/Vercel edge handlers. Better yet: pick between two different static JSON in client-side and fetch them directly from CDN without having to set up any backend would do the trick just fine.
  • Another alternative from redirecting is just render it once but encrypt some of the content for free users, then send the key to unlock it once we already confirm the user is a WM subscriber. Or render contents in a page separately and only ships the rest once the payment is verified. This method is useful since we don't need to wait for verifying payment to start showing some of the content. (Maybe create unlock banner for subscibers to like how Medium does while we're at it)
  • Speaking of waiting for payment to verify, as I mention this before, the place I think needs more attention to is the the receipt verification server. I tried using the public receipt server but it was too slow for production back when I tried it. Hosting the receipt verification server myself might yield better result but I doubt it will fast enough to make users have to patiently wait for it. Focusing on how to strategize UI/UX around the gap created when receipt is being verified might be better for overall perceived performance.
chrislarry profile image
Chris Lawrence

@laka @vineel check this out

chrislarry profile image
Chris Lawrence

Welcome Eric!

chrislarry profile image
Chris Lawrence

@radhyr you might dig this post