The future of web monetization

In this article we’ll talk about the future. The immediate future mostly consists of a proper web monetization standard. For the more distant future the crucial question is how much interest there will be in web monetization, and whether the current model will remain intact or will change — and if so, how.

Standard

Coil is working on properly specifying web monetization, including the <meta> tag and API we discussed, with W3C. A draft standard is already available, but, as usual, these things take time.

The proposed draft is currently under discussion in the Web Platform Incubator Community Group, where proposals for new standards from unexpected corners can be discussed and, ideally, groomed for official W3C status.

What a WICG proposal needs most is practical implementation and usage data. Typically, this is easy to do for a browser vendor that can just include the proposal in its browser and see what happens next.

It’s harder for parties such as Coil who do not own a browser. That’s why uptake of the extension and creative use of the API, is so important: not only will user feedback improve the eventual specification, it will also convince other parties (read: browser vendors) that there is a serious use case for web monetization and a specification.

Eventually, web monetization should be supported natively, but that requires buy-in from the vendors. Right now only Puma implemented the proposal. Samsung Internet added the Coil add-on to the curated on-device list, which indicates a solid interest in web monetization — though without a Blink implementation it cannot proceed any further. The other browsers have not yet taken any steps.

New features

As soon as a proposal is implemented people start asking about new features, or updates of existing features. This is no different for Web Monetization.

One question is about RSS. If you monetize your blog, but you also offer the full content as an RSS feed, could you monetize that feed? It turns out that Atom already has a <link rel="monetization"> that could be used — provided RSS readers start doing something with this information, most likely transferring it to the page’s <meta> tag. As far as I know no RSS reader actually does so as yet.

Another interesting set of questions was asked around future functionality of the Web Monetization agent (currently the extension, but in the future the browsers). Would users be allowed to decide when they pay and how much? Either on a per-case basis or with block and allow lists?

And what if you have multiple extensions of different vendors installed. (That’s currently not an issue, since Coil is the only web monetization provider, but it might well become a problem in the future.)

What about donating a one-time sum to a specific page? That would be great for newspaper sites, who could decide to open their content to anyone who tips at least, I don’t know, $0.50 or so. One question is how long these users would retain access to that content, and if it’s for more than just the current session, where the fact that they have paid for the content will be stored. There are privacy issues here.

One question I have is if there should be a CSS way of showing extra content in addition to the JavaScript way. Something like this:

@media all and (monetization: monetized) {
    #extraContent {
        display: block;
    }
}

This sounds cool, but exactly when is a page monetized? When monetization has started (and the monetizationstart event fires in JavaScript)? That sounds reasonable, but it may take a few seconds, so it may take a little while before the extra content becomes visible, which could lead to a jagged user experience. On the other hand, the current extra content scripts that use monetizationstart have the same problem. A media query would not make things worse.

I’m not saying that this is the greatest idea ever. Instead, I want to encourage you to think about a broad range of topics in order to figure out whether monetization, or the tools we have at our disposal, can be extended even more, and in which ways. Creative thinking is very useful in this phase of the specification.

The future of web monetization

Still, new features are only part of the story. The other, and perhaps more exciting, part is how web monetization is going to develop in the future and how it will change the web.

Stephanie Rieger wrote a great paper about that future, and if you’re interested in web monetization beyond the details of the current implementation I recommend that you read it.

I won’t attempt to summarize it here, but Stephanie’s main focus is describing three possible futures for web monetization and using these as a a lens to discuss some problems we have to solve.

Will web monetization

  1. allow the web to continue to work as it has in the past, just with more money for independent content creators? This is the most likely short-term outcome.
  2. lead to one or two large monetizers that maintain payment streams from users to creators, leading to tiered access system akin to cable TV that concentrates on in-network content, however that may be defined — but the definition is being done by these large monetizers.
  3. be extended to a complete virtual wallet system, where users may donate whatever they want, and monetization providers allow users to buy gift baskets with various tips. Also, there may be micro-subscriptions for a limited amount of time, or even donations for a specific image, phrase, or other bit of content — something you would retweet today.

Stephanie treats pros and cons of each model without extolling one over the others. It’s possible that one of her models is exactly on the mark, or that the future of monetization is found in a mix of these models.

Above all, reading this paper allows you to think ahead and decide what kind of future you would prefer, and why. And that, more than the details of the current system, is what’s most important in this exciting start-up phase of Web Monetization.

22