Part III in an overview of a study in alternative business models for the web. Part I in an overview of a study in alternative business models for the web. Part 2: A Journey of Subscriptions, Ads and Web Monetization
I love the phrase "What If". As an optimist it's the start of a journey down the perfect path towards a dreamy destination without the interference of an undoubtedly messy reality. But "What If" also serves as a conversation starter and framework for figuring out how to make some hard, seemingly impossible mission a reality. For the past year I've been a Mozilla Fellow studying alternative business models for the web. As part of that work I've looked at a lot of really neat ideas, but what motivated me can be summarized in the question "What if there was a reward system built into the web?"
The WWW is amazingly powerful in part because of its simplicity. With a global address space–the URL–we arrive at a web page. Our "user agent"–the web browser–translates the page into interactive content. One company doesn't own the web, but a set of standards and protocols enable people to view the same web page regardless of their physical location, computation device, or language. This standardization is amazing and is the result of decades of hard work by organizations and individuals who shared in Sir Tim Berners-Lee's "What If" listed on his first website:
The WorldWideWeb (W3) is a wide-area hypermedia information retrieval initiative aiming to give universal access to a large universe of documents.
We get a hint at the context behind its creation in the executive summary too:
The project is based on the philosophy that much academic information should be freely available to anyone.
Yet as Sir Tim's "web initiative" took off, "webs" of academic information were quickly joined by commercial "webs". The WWW was suddenly more useful as there were more webs to be found. The protocol would come to include a status code, "402" which meant "payment required", yet its implementation was "reserved for future use". The groundwork was laid for charging for each web request, yet the implementation wasn't completed.
Implicit in my year's mandate is the idea that what we're currently doing–ads and subscriptions–isn't enough to take us into the future. I wanted to share a bit about my journey, go into detail about some points of reflection along the way, and arrive at a framework that hints at one such alternative method for monetizing the web.
Previously I've worked in both media and startup environments, and have my own history of doing alternative business models for the web. In thinking about how things could be, I'm driven by a few beliefs that influence my desires:
- Prefer protocols over platforms.
- Data is an asset (and should be shared explicitly if at all possible).
- User attention is scarce and forcing a user to context switch should be avoided.
- We can build new layers, but prefer to ask existing technology to do more.
- Feedback loops are needed for growth.
- Information wants to be free.
When the year began I started with the idea that if there was going to be an alternative to ads and subscription paywalls, then it would need to have a place in which it would surface to the user. The plan was to build a set of libraries that websites could use to have conversations with users: "How do you want to pay for this?". Eventually there was a hope that we could arrive at a place where sharing information made the creator more money rather than less, without the parties having any conversation about payment.
Waypoint 1: Web3?
I started this exploration in January of 2021, and began by talking with as many people as I could. I spoke with old friends and new, explaining the rough mandate and my plan for tackling the year. An unexpected early waypoint was when several people started to ask me if I was looking into Web3? I wasn't, but did.
Web3 imagines the creation of new layers that integrate into the web experience, giving access to new cryptographic browser primitives, wallets, and a horde of creators who want a better way forward.
While interesting, I found the crypto vs fiat conversation as orthogonal to my work. Should governments be able to print money like crazy? Probably not, nor should it be so easy to lose access to a wallet. Everyone has work to do, yet my exploration is more about the interface between people and content–digital goods–than in which technology for storing value is the best for a given situation. With that said, web3 ideas definitely infiltrated the rest of my fellowship year.
Waypoint 2: Who is the Reader? (We Don't Know)
I began building a universal paywall interface. The idea is that if users saw the same interface on multiple websites, they'd begin to understand the value they get for a particular paywall, or rather collective of joint paywalls. A collective paywall would need to solve both the technical hurdles involved in creating a paywall–the reigning in of cookies, etc–as well as clearly articulate the value for the reader. This work caused me to pass my second waypoint: the web is built to make anonymous access easy; email is built primarily for authenticated access. As a product developer you have to fight to get a user's id in a web application.
If we were going to take something like metered paywalls to a collective, we'd need to know who the user was across websites on multiple domains. As it turned out this isn't super easy to do at web scale (by design!), and our workarounds, while fun, seemed too hacky for use. We explored using WebAuthn and a single domain–ident.agency–to "hang" our authentication cookies off of. This would mean that every time you visited a new domain the browser would redirect to the shared domain, retrieve your authentication cookie, and do some math using the El Passo scheme and send over a consistent, but domain-specific id. Data would be shared explicitly with the domain, and the user would be in control of this interaction.
While this worked, it wasn't super easy to use and we were left feeling that the web browser itself should be doing more to help facilitate these kinds of interactions. Google is able to do something similar to this today with Login with Google, but this goes against our principle of protocols over platforms.
We ended up getting fairly deeply involved in the sandboxing for cookies and other data storage. It was during this research that I came to understand how freeing something like "web3" is, as it allows you to reimagine whole layers of user interactions, providing the ability to have multiple ids as you browse, selecting between them as the case requires. There's an enormous opportunity for existing browsers to do more to address the use case.
Since we're on the subject of multiple ids, Web Monetization doesn't make rewarding multiple content creators per page view easy. There are work-arounds, but having multiple content creators is the norm rather than an exception, so I hope that future versions of the protocol will support multiple ids and payment pointers.
Waypoint 3: Payment Preferences
After exploring shared ids across sites, we moved on to look at allowing users to set a preference in their browser that gave a signal to the sites they visited as to which payment method would be acceptable to the user. What would a monetization ecosystem look like if there were multiple ways to pay for content? How would a website choose which method to charge the user if there were multiple available? All of this "how do you want to pay for this" user experience is taxing to the user, is there an automated way?
As it is now, users install extensions like ad blockers that alter the client-side user experience to not show ads. We were interested in passing along this signal–"I don't want ads"–to backend servers to construct a better page for the user's desires. A user might not want ads, but would be perfectly happy with a micropayment scheme like Web Monetization, for instance. Without a mechanism to pass along this signal, implementers are left to guess or special code every single method. Our web pages become overrun with monetization boxes: ads, paywall nags, tip buttons, and whatever other new thing we come up with. How can we reign this in and simplify?
We envisioned something like MIME types for monetization methods: ads/*, ads/behavioral, webmon/coil, for instance. Each of these monetization methods could then be passed along to the server via HTTP headers, similar to the Accept: headers already in widespread use. Ultimately this conversation between the user and the site would allow new players to enter the monetization economy, each with their own idea on how to best reward the content producer for the value received. We furthermore imagined a client-side API to give access to these payment preferences, allowing them to be set in a consistent interface.
Waypoint 4: A New Model
It was around this time that we realized just how enormous a change a new payment scheme would be technically, but also socially. My "What Ifs" began to disregard current implementations and play outside the web, looking at improving digital interactions in general through micropayment capable interfaces like Interledger.
What if it's our economic understanding that needs to shift? What if supply and demand curves are not the best way to set prices in a digital world? How else could we do it?
Interestingly many implementations of micropayments don't actually make real-time payments, instead having a value-recording phase and a separate money transfer transaction. My own first foray into micropayments, In-a-Moon, did this explicitly:
- Pay $10 at the start of the month to In-a-Moon.
- We record the sites you visit.
- At the end of the month, we proportion out your money according to how much time you spent at each website in the month.
FairPay, Coil, and many others ultimately share this kind of implementation, as it's the most practical way of creating micropayments in the age of pennies. The first phase we might call "attribution" and the second "settlement".
Previously I had thought about what it might take to create an "Attribution Economy" and set out this list during a "What If" session. The ideal system should:
- Work equally well for big and small entities without regard to their size, social status or even corporality.
- Reward the attribution source rather than the artifact.
- Promote distribution, social sharing. Good ideas should be incentivized to spread.
- Be unfettered and free to explore, discover, and add; look back, using time as the arbiter of value obtained.
- Be reversible [auditable] so tricksters have their work cut out for them.
The Attribution Economy is alive on social media, where @mankins is enough of a feedback loop to notify me that someone attributed something to me, perhaps coaxing me to join the conversation or create more. This feels natural to us in 2021, but what's missing is acknowledging the value created.
With my recent experience with Web Monetization in mind, I began to formulate a new set of rules for how a digital economy might capture and reward value:
Imagine a journal of all the digital creators that give you content. You might have a log of all the websites you visit (h/t Doc Searls). This might include all the authors, illustrators, editors, copywriters or a rollup id for the "publisher" that might include all these individuals as well as the financial team responsible for paying them and the rest of the organization. The point here is that it could get granular and maybe that's ok. The first step is to record these attributions.
As a second step, we'd use the journal of attributions as a guide for distributing money. This is the "settlement" phase mentioned in the micropayment overviews above. You could imagine converting your subscriptions into a single payment, paying "creators" instead of individual corporations. If we can get more participants into the top of the funnel, everyone wins.
Now where this might get really interesting is using the reputation of a user for supporting a content creator in the past to allow for future access. FairPay includes one such implementation that works out in detail various parameters that might be desired. Web Monetization allows a man-in-the-middle approach to view receipts that can then be passed along to websites as proof of entitlement. I'd argue that we'd like something a little simpler to start with, although these are likely good methods to keep in our toolbox as edge cases necessitate their usage.
Waypoint 5: Kudos
Starting from the idea of two phases, I sketched out "Kudos" as a payment system for open source software–although it's applicable just the same for web sites, it was slightly easier to implement for this use case.
In Kudos, we generate "kudos", store them in a log, and then take real money and distribute it to the members of the log…or choose not to. In this way we can call kudos "maybe money". It's more of a record of value, but a useful one for digital rewards.
A "Kudo"–there is no such thing as a kudo–is kind of like a JWT token, recording an ID, a timestamp and optional magnitude, signed by the log owner's private key. These Kudos are easy and "free" to create. Kudos would be recorded in a Kudos log which is a transaction similar to entering a journal entry in accounting. You'd likely want to store these with some metadata, like tags or dates.
With Kudos you have a list of people–or ids more generally–that helped you. This is an acknowledgement that you've derived some value, however miniscule, from these ids. It's a feedback loop that generates data that acknowledges this value transferred, without an associated currency or unit monetary value.
Facebook's Like is a Closed Kudos System
Interestingly, clicking the Facebook "Like" button is similar to creating a Kudos: it's a signal that the user derived some value. Facebook doesn't share this data however, and uses the stream of Likes to improve its algorithms and make money. Your Likes are actually currency, promoting good content. What I'm suggesting with Kudos is similar to these Likes, but instead of keeping the data inside Facebook, it would be owned by you. You would be able to use this data to reward the places that gave you "value".
You could choose to do nothing with your Kudos, or you could choose to reward these Kudos by sending money to your Kudos in an act called "settling." To settle Kudos you take the log (maybe filtered by tag or date range) and split a fixed amount of money amongst all the ids that have corresponding payment connections. This relies on a universal id system–like the URL–that maps between ids and payment connections (payment pointers, wallet addresses, etc.).
When settlement is complete, we receive a receipt that we can then add to our reputation. We can use this reputation to prove to a site that we've supported them in the past. (You could also imagine blinded receipts or throwing away the receipt entirely.)
With Kudos for Open Source you'd have a step in your build process that records the GitHub handles of the coders who contributed to your build. You'd record this into a Kudos Log. Then at the end of the month (or whatever period of time you want), you'd set up a process that distributes a fixed amount of money to the Kudos Log entries that have a corresponding payment method setup. In this way you'd be supporting the software you use, but fixing your costs. The receipts generated can be used to create badges that you display on your website, or attach to GitHub Issues to prove that you're a supporter and your query should be prioritized.
Reward System for the Web, But Why Pay?
I started out by saying that I was looking to explore the creation of a reward system for the web. Web Monetization is one such reward system, allocating funds to content creators of websites that have raised their hand, signifying "I want to be paid" by configuring their pages with a bit of HTML.
Web Monetization is a simple opt-in system, but it doesn't say why you should subscribe. This messaging is better left to the websites that employ Web Monetization to craft the message for the circumstance. This flexibility could be considered a strength or fatal flaw. I happen to believe that the choice lets sites develop contextual messaging or paywalls around some premium content, but do worry that without scale there is no network effect so usage stays low.
Where systems like Web Monetization or Kudos falter is transitioning users through the threshold of payment. I believe that these systems can see widespread usage if we reduce user context switching and make payments automatic and supported in the default user interfaces of our browsers.
For a global system to be practical we'd need to integrate these abstractions deeper into our web infrastructure. I see opportunities to have our web browsers act like true "user agents" and perform payment functions for me without thinking much about it. If we built a Kudos Log into our web browser, this would be the first step at understanding where we derive value monthly. From there we can choose to send money to each of the Ids that we gleaned some value from.
What's Next?
I'm looking forward to building out some of the ideas generated from this fellowship and taking them into the "real world". In particular I'm looking to use Interledger as the basis for funding Kudos for Open Source software development. I believe that the experience of making this software and its corresponding protocol will provide the clues to how a web-focused product should behave. I suspect it's similar to what's outlined in this document, but we'll learn quite a bit by doing.
As for outstanding research questions, I have many, but see enormous opportunities in modifying the apps we use to interface with the internet. I see the possibility of having an ecosystem of "user agents" each helping us as we interface with our digital world. It's not about having a web browser and an email client and a wallet but some suite of functionality that brings together a simple, multi-protocol experience that helps us view, create, manage and of course monetize and monetise our own web of data.
If you haven't already, be sure to check out Part I in an overview of a study in alternative business models for the web and Part 2: A Journey of Subscriptions, Ads and Web Monetization, or connect with me at @mankins on Twitter.
Top comments (0)