DEV Community: Matt Mankins

What If a Reward System was Built Into the Web?

Matt Mankins — Wed, 06 Apr 2022 12:41:43 +0000

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.

A Journey of Monetization: Subscriptions, Ads, and Web Monetization

Matt Mankins — Wed, 06 Apr 2022 12:18:09 +0000

Part II: 'On Subscriptions, Ads, and Web Monetization' in a an overview of a study in alternative business models for the web. Part I: Monetization for Digital Economies. [Part 3: What if the Web had Rewards?]

How much is my content worth when I put it online? A reasonable answer would be "it depends"–on the reader and their current context. But how can we arrive at the right price for a particular reader? What if that amount is less than the transaction cost–the cost our providers charge us to make a transaction? For many content producers the question isn't "what's the right price" but "how can I earn anything from my content?".

In looking at alternative business models for the web–my mandate for 2021–I found myself looking at existing systems to see what I could learn from each. One of the surprising things for me was looking at how the dominant forms of monetization evolved themselves into their winning position as a chosen monetization method.

I found though that the real opportunity in web monetization is unlocking the long-tail of content where per-unit revenue is less than the transaction cost of transferring money from a user. Because of this large transaction cost we've been left with blunt instruments to monetize content, namely advertising and subscriptions.

Lorem Ipsum Books: A Study in Pricing

I used to own a bricks and mortar bookstore called Lorem Ipsum Books where I experimented quite a bit with pricing. For a while we stopped putting prices on our pricing stickers, instead asking our customers to "Ask Us". Then every day before the store opened we'd run a pricing algorithm to change the price of books–or entire categories of books–that weren't selling. Or we'd increase the price for books we know would sell immediately. I learned several things from this experiment, the most important being: customers hated it.

When someone came into Lorem Ipsum, they wanted to find something to buy. They were our customer to lose once they walked in the door. An inability to understand the price of a book turned out to be a good way to have someone leave empty-handed. Many potential customers didn't want to ask. Many more thought the pricing absurd: $5.17 was a common price–why not $5.25, or $6 as in other stores, they'd ask?

This Lorem Ipsum experience reminds me that customers are a key part of the story of monetization. New methods need to be put out into the wild and tested or it's all theory. We have web-scale systems that work at a mind-boggling scale to maximize revenue per page view, yet these are closed systems that are meant for corporations, not individual content producers.

What can we learn from ads?

Advertising is a Micropayment

Ultimately it was advertising that fueled the growth of our early web, but unfortunately it has come at the cost of tremendous complexity and lack of trust and transparency in the usage of our data.

Part of this complexity is how modern ads work. It used to be that everyone saw the same ad, since ads were built into the web page. Have a look at Yahoo! from the 1990s and you can see ads directly served from the yahoo.com domain. Everyone got the same ad because it was hard-coded into the page. (Up until recently these ads were still hosted on www.yahoo.com so anyone with cached HTML would get the same page layout as in the 1990s.)

But in 2021, my ad experience is different from yours, and the amount of money generated per page-view is in constant flux, depending on the whims of the advertisers–or data available. For content producers it's not always clear how much money is being made until the deposits happen, often months after a given page view. On the one hand, this variable pricing is a strange arrangement: if you sold cars this way it simply wouldn't work, as there are fixed costs involved in auto production. Yet consuming digital content has an incremental cost near zero–yet definitely not zero–and so a different set of rules apply to ad economics. (Or maybe the same rules apply but the per-unit pricing has more wiggle room than the average car salesperson?)

It's remarkable to think that the rules defining digital advertising organically emerged as a means of extracting the most value possible from a random person on the internet viewing a given web page.

At first ads were hard coded into the page, like in the Yahoo! example above.

Next we figured out that we could sell ads capped to a certain number of views.

Previously we'd sell ads based on time, like you might in a print world that is issue based: "buy the homepage on March 7th". When this was coupled with some server logic, we had the ability for an ad on the same page to be sold by multiple ad sellers.

Rather than linking to a static file, this dynamic link would first serve an in-house ad, but if we'd already sold our ads, we'd redirect to a third-party ad seller who might have inventory available. We'd set that provider up so that if it didn't have any ads available it would go to the next highest valued tranche of ads.

This all worked fine, but centralization of the "ad server" made this easier to maintain.

Furthermore, centralization has many benefits, including that ads would be served from a single domain, giving the ad server the ability to develop a profile about the user to "serve better ads" by looking at the user's http "cookies". With this centralization, the ad server grew incredibly valuable and was able to extract large amounts of money from the content ecosystem for its operating company.

We're still grappling with these tradeoffs today, reigning in where possible without toppling the house of cards that is today's ads-based revenue streams.

I see opportunity in the story of ads. If we squint we can see that advertising is a form of micropayments: readers viewing a web page generate money for its publisher along with a slew of intermediaries that know a little bit about that reader, web page, or other bit of valuable context. These bits of payments are regularly measured in units that need to be multiplied by 1000 to be on a currency scale we're used to using. We don't regularly call advertising a micropayment, but it is.

Subscriptions

Media before the web was supported with advertisements, but also with direct consumer revenue in the form of profitable newsstand sales and slightly less profitable–but more reliable–subscription revenue. (Print and television had their own particular versions of this, but generally the point is that revenue for media was and is multifaceted.) It should be noted too that when you purchase a subscription to a publication you get the publication ads and all. It's not advertising or subscription, but you're supporting with both.

In 2021, "subscriptions" encompasses a few different sub-genres: paywalls, tipping, and premium email content are all different implementations of the same basic principle: a user is asked for money on a regular basis which supports the site or content. This direct payment from the reader to the publisher is less likely to go through many different third-parties, but often involves higher development and operating costs. (Like advertising this can be a significant portion of the cost of goods sold.)

If not ads, then what?

Case Study: MollyMail

My first subscription web service was a web-based IMAP email client called MollyMail.com, started in the mid-1990s as a demo service for EMUmail, my company's webmail software. MollyMail was used by people who needed to check their existing email on the go when they were away from their desktop mail client. Somewhat surprisingly MollyMail had amassed a user base of hundreds of thousands of active users per month. We were running the service out of a datacenter in Los Angeles, and it needed more hard drives to store all the emails we were processing. We didn't have capital to buy more hard drives, so we came up with an idea: "Let's charge users for the service."

In no time we had a paywall setup, so that when you logged in the first time it would tell you this was a free trial for 24 hours. After your day access was up, you got a "No" and needed to buy a pass. Giving someone a reason to pay–the ask–is crucial for subscription revenue. This can be a soft ask, like Wikipedia does regularly, or can be a hard paywall like the Wall Street Journal.

I remember the difficult part for us was deciding how that pass should work. Ultimately we settled on a day pass for $15, a three-month pass for $25, and an annual pass for $45. Our conversion rate was 7% and we definitely had money for the hard drives we needed to keep the service running.

One of the reasons we made the pass expire in three months is that we didn't have the infrastructure to automatically re-charge a user's credit card, so we built a pass system instead of subscriber access. A pass that automatically renews is a subscription, so it's certainly close.

Interestingly the harder the paywall the more incentives users have to find alternatives. Content creators (or "suppliers" in the case of some information-based services) are constantly looking at their messaging and the permeability of their paywalls to find the right balance for the long term. While MollyMail had a high conversion rate for the first year, the annual renewal rates gradually decreased until it was no longer profitable for the company to maintain as a service. A short term bump in revenue may tailspin towards insolvency if you don't monitor your metrics closely.

Since this first paywall experience I've gone on and built paywalls for many sites, and have always been amazed at the transition from paywall-free to gated. It always brings in some money, but it's not always worth the effort to build, maintain, and operate the paywall as users search for free alternatives.

I'm really interested in low-effort solutions to help content creators monetize their content in ways that readers find agreeable in the long term that don't rely on large operations teams or infrastructure.

I have trouble imagining the ideal paywall system, because I think the ideal paywall is no paywall. Similarly I think the ideal ad is no ad. But if not these two methods, then what can we do? Everyone is a content consumer. Everyone is a content creator. We all need to eat. What's next?

Web Monetization: Like Ads plus Subscriptions

What is new in monetization? Web Monetization. Web Monetization is a proposed standard that enables the streaming of payments from a user to the website enabled by a privacy-preserving provider like Coil. In the future, users can pick from providers including some that charge a fixed amount per month, with small micropayments made to publishers based on time spent on a site.

One of the intriguing things about Web Monetization is that it's a combination of ads and subscriptions, bits of inspiration from both. When readers visit websites that include a "payment pointer"–an address in which to send money–a small transfer is made to the publisher of that web page.
Unlike advertising this is done in a privacy-preserving way so that the publisher isn't able to know more than whether or not you're a subscriber or not. Each pageview generates money for the publisher from a fixed allocation on the user's side. There's no "mental transaction cost" of deciding if you want to support the site or not, it's an automatic allocation. Web Monetization is an open standard and itself promotes another open protocol, Interledger.
Currently Web Monetization "streams" money to publishers as a reader visits various websites on the web. There's an opportunity here to take this standard and keep evolving it, just like the ad ecosystem evolved to find the right way to maximize value for all parties. In order for that to happen Web Monetization needs more adoption from sites large and small.

In the next part in this series I'll go through a few waypoints in my journey through the land of alternative business models for the web, starting off with some things Web Monetization could do to evolve itself into an increasing prominence as measured in total web value transferred per month. In case you missed it, here's Part I: Monetization for Digital Economies

Monetization for Digital Economies

Matt Mankins — Wed, 06 Apr 2022 12:01:19 +0000

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. [Part 3: What if the Web had Rewards?]

What does a purely digital economy look like? If you started with a clean sheet of paper–or rather an empty document–and built a set of rules that would support digital life, would you end up with the same economic primitives that define our current digital transactions? Or would a bits-first approach build an economy with slightly different rules than the one created in the age of atoms? It's easy to imagine that things would be different if we started with bits rather than atoms, yet not as obvious what the differences would be.

During my time as a Fellow at Mozilla studying alternative business models for the web I imagined potential incremental changes to our existing systems in the name of digital progress in the areas of openness, fairness and inclusion. By the time I started this work in 2021 digital platforms had grown away from favoring open protocols that defined the early Internet era, instead choosing the creation of closed platforms that gave a larger degree of control. In 2021 large tech companies produce tremendous value by leveraging these closed platforms which are cleverly monetized often without up-front money from web readers. For my research I wanted to explore ways we can revive protocols to enable creators large and small to earn money from their digital lives.

My fellowship was sponsored in part by Coil, a company that is using Interledger to build a better way for creators to earn in a fair, open, and transparent way.

All It Takes Is Eyeballs

I can remember when the commercial web was taking off I'd ask my customers–I was selling webmail software–how they planned to make money and they almost always mentioned the word "eyeballs". At the time eyeballs was shorthand for "I'm not sure, but we think if we get enough people using our site we'll be able to sell our user base to someone else with ads or some other arrangement." These early entrepreneurs were right in acknowledging business was about to change profoundly as a world of customers became addressable, yet wrong about their own businesses. Most of these early ventures failed to find a revenue model that supported their particular form of value creation for the long term. I think it's never been as easy as it should be to convert digital value into a currency on the web, in part because this was never a design goal of the web.

We haven't (yet?) found a magical technology or model because there isn't one that will work for everyone in every circumstance. Instead we need a multifaceted approach to monetization, exchanging value for money at the moments with the least friction for the parties involved and the magnitude of value exchanged. With that caveat, I think there's more we could do by introducing new digital-first payment rails while continuing existing efforts to reduce friction at exchange points to our traditional banking system.
At the start of the year I saw the problems of monetization as being closely aligned with the problems of friction. Friction in the digital sense is a gradient of woes from "a bit longer to complete a task" to "I forgot my password" to "Where's my wallet?". By the end of the year I still believe that incremental progress matters, yet am more convinced than ever that profound change is needed to unlock the potential value stored in our digital economy. Fixing identity is part of the way forward, but so too is updating our economic models to give us digital-first primitives and easy to understand techniques to transfer value.

How Many Ways Are There To Earn? Do We Need Another?

Thinking back to my days selling webmail in the early commercial web in the 1990s, we made money every way we could: we embedded ads in the free version of our software, sold enterprise software licenses with support contracts, had a software as a service offering called SMTP.com, and had ads in a free consumer version of our software called MollyMail which was eventually "paywalled" requiring a monthly subscription. Each of these monetization methods required a large development effort–at least for my small business. Ideally new monetization techniques are universally available, without the need for risky technology development, capital outlays or infrastructure. This simplicity requires coordination with core web software like our web browser (or possibly new protocols and user agents) to make it easy for all parties.

There are tradeoffs involved in any implementation. How many ways are there to earn, and do we need another? Cash is a good example of a value transfer technique that's easy to use for all, but it comes with the requirement of governments needing to print it. Sending a website cash per web view isn't practical, but using Web Monetization to compensate the site is possible, if not yet universally available.

Auto-Compensation

Stepping back a bit, let's look at how a system for rewarding intellectual output might function. Intuitively, if I'm creating value, I would like to be compensated by society for that value. In an ideal system it would be automatic–auto-compensation–I don't want to think about it or have the people that derived value from my work have to think about paying me. Just as early intellectual property laws featured copyrights, patents, and other primitives, we could imagine that a digital system that promotes production and rewards consumption would create models of its own to help us nudge society towards this dream. It may take some more work to get to these primitives, but stick with me.

In the physical world my compensation was easy to quantify in terms of wages for a day's labor or an artifact of my construction that I could barter. When we shift temporally our existing economic frameworks no longer provide easy tools to help us figure out how to be compensated for our production of a song, a story, a poem, a movie, a web page, etc. When the incremental cost of spreading the output of our work tends towards zero, the unit pricing models seem to make no sense. We've made intellectual property rights laws to work around the conundrum, but in the Age of Digital Reproduction these laws are fragile limiters of production rather than the robust catalysts they aspired to be.

Imagine the perfect way to earn a living. For me the ideal way to live life would be to think and do things that are interesting to me. Somehow I'd get paid for that to be able to support my family. I believe that we almost have the tools to make this dream a reality through automated money transfers on value recognition. We're not yet there, but this is the dream: make society better and it will support you too.

Engineers, designers, and business leaders will continue to push to make the experience of paying for web access as easy and painless as possible. For this they will need new concepts, such as micropayments as well as new technology stacks, such as Interledger (which Coil is built on top of) which is a sort of universal transport layer to access and transfer value.

In the rest of this series I will look a bit at existing monetization methods, and then introduce a new framework called Kudos, that is what I imagined when thinking about the rules for a purely digital economy.