---
# System prepended metadata

title: Towards Web Monetization

---

# Towards Web Monetization

## Introduction
It's funny how scholarship essays can prompt thinking on topics you thought you've forgotten, and spark new thoughts even after you've penned your profile and sent it off to the selection committee. I applied to something recently, in which I had to go through the usual drivel of describing far-off plans for my future. I talked a bit about open source and a bit about leadership, but the part that's stuck with me was a part about impacting the future of the web. 'Reinventing the web' seemed a bit lofty and grandiose, so I chose to focus a bit about my experience with Web Monetization.

[Web Monetization](https://webmonetization.org/) is something that's been on my mind's back burner since the hackathon [Dev.to](https://dev.to/devteam/announcing-the-grant-for-the-web-x-dev-hackathon-winners-1nl4) hosted. (I've written a post about the hackathon over [here](https://kewbi.sh/blog/posts/200531/), if you're interested.) If you're not familiar with Web Monetization, I highly recommend checking their website out, and looking at some of the projects and discussion that's sprung up around it. A four-way partnership between Mozilla, Creative Commons, Dev.to, and Coil, the hackathon encouraged people to build new toolkits to implement WM to work with and extend web environments. I'd initially gone into it purely for the technical challenge, and had approached my second project, a GitHub revenue sharing Chrome extension also based on WM, with a similar perspective.

However, as I've continued to see articles pop up every now and again about WM, I've started to think a bit more about the monetization models of the web today, and how WM can potentially augment, extend, and change them. For example, there's these big tech giants who are *stealing all our data* and *greedily injecting ads wherever they can* and generally not doing very privacy-, or even human-friendly things. There's the counter-argument and justification that content has to be paid for in some way in order to produce it with any acceptable quality. There're perfectly rational people who would really rather not have to pay for anything, but have gotten roped into a couple larger publications and subscription instead of smaller, indie ones because bigger sources provide a higher sheer volume of content to consume - and hey, that technically equates to better money spent, right? There's the Substack revolution, and the rise of the independent web while people espouse the benefits and inherent aesthetic qualities of a more open web. There've been ad-blockers, ad-blocker blockers, and ad-blocker blocker blockers, and who knows how long the war between corporation and Chrome extension will go on.

Web Monetization, to me, is a better fit for the 'indie web', as they call it, rather than larger, more clunky companies. With clear examples of hiding ads for paying users (a model that exists already), adding new content for paying consumers (augmenting the private subscription model), and sharing revenue (simplifying a model), they've come up with an alternate pathway for monetization besides slapping ads between a couple paragraphs. Most of the sites I can see potentially adding this are the types of sites that don't even have ads in the first place, and it's an interesting possibility to investigate this more passive stream of revenue.

I've been thinking about Web Monetization and the opportunities it presents ever since I wrote the essay. It's an interesting way to add new monetization streams on the web and rework existing ones - however, like most things, I think there's still some steps to be taken before we can see how WM will evolve and adapt[^1].

## Project Check-ins
Before I step into some of the issues and future possibilities I see in WM, I'd like to check in on the state of some of my own projects in the WM area, and see how they're doing as WM evolves.

Let's start with [kewbish/revshare](https://github.com/kewbish/revshare). Long story short, it's a Javascript library with a couple custom web components to split payment. Instead of sending everything through to a central payment pointer and letting whoever's in charge of accounts to share revenue, all users need is a single JSON object linked to a rather janky component. This would update the monetization tag that's required to stream micropayments, and therefore change the stream of revenue. (Imagine an editor, writer, and photographer working together on an article - this way, they can split money according to their agreed-upon percentages, without having to deal with doling out the cash themselves.) People seem to still be using the project somewhere (or perhaps the NPM statistics are simply lying to me) - as of the writing of this post, I have something like 6 downloads this week. It's a small number, but it's infinitely more than what I'd expected, and it's nice to know people are out there somewhere in the world using it.

Interestingly, as I was checking up on the general state of Web Monetization earlier this year, I noticed that WM had linked their own [revshare generator](https://webmonetization.org/prob-revshare), which does the same thing as Revshare, but in a probably easier-to-use format. While I'm slightly miffed (no, I'm really not, no one much was using the revshare project anyway, and I'm happy that there's an easier way to split payments than loading in a JSON object and using scuffed custom web components), it's good to see that they've started coming up with some of their own tools to facilitate solving some of the issues I'd been having when I started out.

The second project I've worked on involving WM is [kewbish/revshare-gh](https://github.com/kewbish/revshare-gh)[^2], which is Revshare, but with GitHub Sponsors payment pointers and a little dependency kickback. GitHub Sponsors has a custom field or two in which project maintainers can fill in a WM payment pointer from whatever provider, which then gets added to the monetization tag, feeding creators a bit of revenue while people browse the repo. It also splits about 50% to whatever dependencies the project uses, if a WM payment pointer is present in the dependency repo's GH Sponsors tag. The idea was that open source maintainers could make a bit of cash off people browsing their repos, and also give some back to the projects that helped build it up.

As I've continued to think over this idea, I've realized that there's two main issues. One, there's a bit too much friction between the user (not the owner of the GH repo, but the user who'll be paying). Revshare-GH was built in the form of a Chrome extension, and I'm not sure people would be willing to take the time to install and add their GH token to provide more support to maintainers. Even if you're paying, there's not any value added to the repo, and I don't think any fancy special content can be loaded, since Markdown doesn't have access to Javascript. Yes, I could rig up an external service to connect exclusive content locations to people who choose to donate, but I think that's best handled on the GH side of things. If GitHub itself includes WM tags as a repo option, this friction would be gone, and I'd be inclined to think that people would be more enthusiastic about the project. Two, the amount of revenue kicked back to the creator would be minimal, and I'm not sure if people would bother to include their payment pointer and ask their consumers to set something like this up for a couple cents a week (more on this a bit later). From my own browsing habits, I tend to only check repos out for a couple minutes, skimming the README and perhaps looking into a bit of the code if I'd like to borrow a technique. If I'm looking at the documentation, I'll stay for a bit longer, but oftentimes docs are hosted elsewhere from GitHub, meaning that the standard method of WM would likely work better there anyway.

Regardless of the problems I've found, I'm still happy with these two projects. They solved problems back when they were being created, which was the entire point of the exercise of working on them anyway.

## We Need More Providers
Coming back to WM itself, I think one of the more glaring issues seems to be adoption, specifically with WM providers. There are only a couple wallet providers, one or two search engines and browsers, a handful (though a healthy one at that) of platform integrations, and only one payment provider, Coil. That seems to be a bit sparse.

Part of this seems to be the feedback loop where companies don't see the benefits of investing in creating a payment processor for a niche area of monetization when there isn't widespread adoption and low profits to be made. In turn, because there's low adoption among existing companies, users perhaps don't see the point of creating a whole new account and subscribing to yet another service. Developers see that few people have accounts, and without a wallet at one of the few providers, might decide that the possible revenue would be too low to bother spending valuable time on it. And without high-profile companies integrating WM into their products, competing companies wouldn't bother to use WM, and so the cycle continues.

When I was participating in the Dev.to hackathon, I'd honestly not have bothered to make a Coil account if they weren't giving a couple months of it away for free. (I'm also not legally allowed to reap any of the benefits yet, which is part of the reason I haven't bothered to WM any of my sites or posts, but perhaps I will sweet talk my parents into something if I ever feel like it.)

Perhaps another part of this is that the [spec itself](https://webmonetization.org/specification.html) hasn't been finished yet, and hasn't gone through whatever magic goes on at Google and Mozilla and all the tech giants before something gets integrated into major browsers, if at all. There still seems to be a good amount of activity on the spec and the GitHub, so I'm excited to see how WM will spread and be adopted if something like Chrome adds it as an API. With it as a default option available in the browser, the potential audience of WM work is opened up from just tech-nerds with niche browsers (no shade), to a more general audience[^3]. Developers, payment processors, wallet providers, and content creators will be more inclined to start WM'ing their content - instead of a couple cents here and there, perhaps WM can start augmenting and eventually acting as a proper stream of revenue.

## For The Consumer 
Articles on WM generally center around the possibilities of revolutionizing the monetization models prevalent on today's web by shifting away from ads and towards user-initiated micropayments. While WM certainly has the capabilities to prompt a move away from ads (it even has a handy example on its docs detailing exactly how to do so), I think it'll take a lot of time and promotion before WM starts growing to something that even a decent fraction of an app or content creator's userbase will readily have.

With the ads-based models that seem to be the standard on the web, users don't have to physically (well, digitally) fork over any payment. The money creators make is not *directly* from you, but is still from you - your data, your analytics, and your preferences. The important thing, though, to note, is that the consumer never sees any of this, and even though the news has hopefully blasted the fact that companies are building scarily accurate profiles about you without your knowledge, it's taken for granted that things are 'free' on the web. I've asked my parents about this before, and they seem pretty nonplussed ('I have nothing to hide - try to make me buy whatever you want').

Even if people pay, things seem to be easier and seem to be more 'worth it' by supporting existing, larger organizations. A subscription to an online newspaper gives a reader access to exclusive breaking news, and hundreds of stories. A Patreon subscription might only give access to a couple of posts - and same goes for some of the new custom platforms creators are using to sell early access, special, or otherwise gatekept content. In order for WM to gain a wider adoption, I think it's necessary to shift people more towards indie sites, or towards sources of monetized content, so people feel comfortable with the process. Besides the technical limitations today (I don't think managing ILP wallets is something that most people would bother with to get started - I'd think twice), it'll take time for the internet to shift to accept these models of monetization, and to trust in paid content. An interesting thing to note about the Substack revolution (is that what they're calling it?) is that it's hopefully prompting people to ask where they get their content from, and to contemplate the value of what they consume - is it worth a couple dollars a month? Hopefully, this, and other micro-monetization movements will pave the way for WM, and get people more comfortable with the idea of having to pay for things.

## Conclusion
WM is genuinely pretty cool. I think it's a possible stepping stone in the long pathway towards a more indie web community, and in the meantime, a nice way to get a couple cents where you otherwise might not have. It might also be a step to get people to more actively seek ways to control who's taking their data and money, but at the cost of having to knowingly give away money. It's interesting to ponder how WM can potentially rework monetization models that are now the norm, but it'll take a lot of adoption and investment into spreading the API first.

There are a lot of 'but's in the thoughts I've been having about WM, but (haha, another one) I think it'll come with time. The recent uproar around NFTs (hey, even the local news aired a segment) proved that people are interested in this whirlwind of new money coming into cryptoart, and who's to say the same attention won't eventually turn to micropayments and other methods to monetization? Hopefully, widespread adoption and user comfort will increase with time, and we'll get to see WM as a cornerstone of a new age of the web.

[^1]: Also, in an interesting turn of events, another article about Web Monetization popped up on [HackerNews](https://news.ycombinator.com/item?id=26375857) just as I was going to write this, and there's some interesting discussion happening in the comments.

[^2]: I have a vague feeling that if I don't mention Aadi for giving me the idea (thanks buddy), he'll be at least somewhat annoyed, so I'll add this here.

[^3]: They say RSS died away because it was never integrated directly into the browser, with explicit features to follow and interact with feeds. I'm not entirely sure of the truth behind that, but I think that by increasing the size of the WM userbase, people will be more incentivized to use it, especially if it's built into a popular browser in an easy-to-understand way.
