Tired of Google’s unending efforts to track you down and sell your data? Hoping there would be more traction in the open and federated platforms like #peertube #owncast or maybe #wordpress ? But creators want to make money… How do we solve that? How about a simple standard for differed micro-donations? A like turns into a small gift.

Introduction

Here’s the situation in 2023. We all consume contents in short bites, be this audio, video, or text. We rely on a large network of content creators to get us entertained and educated. Yet most of us are struggling more and more with a disturbing reality: the platforms who bring the content to us, and get us to know the creators, are… well, a bit evil. At least when you consider how they treat your data. The majority of the business model relies on advertising, itself powered by incredibly invasive tracking (just check this latest finding on how perverse the advertising industry has become).

Many of us no longer agree with this, but the big platforms aren’t ready to give up on that business model. The alternative one, paying them money, isn’t great either: they’ll pocket a large share of the money, in an opaque manner, potentially leaving scraps to the creators that matter most to you. And by giving them money, we help them maintain their evil-ish oligopoly on content.

Many people now advocate for an open and federated model for the web. But how can creators, many of whom have started entire companies to create high-quality content, give up on the big platforms?

The idea of a standard for micro-donations

Here’s how I think this could be addressed, with just 2 parts that need to work in unison:

  1. On the website publishing the creator’s content, we include a hidden reference (probably a header) that can be: either an encoding of how to give money to this creator (paypal:[email protected] or patreon:@nickname, or, why not, several of those); or a unique ID that can be used to retrieve the donation options from a “catalogue” of creators somewhere. I prefer the former as it’s less complex and less centralised.
  2. Browser extensions (and perhaps SDKs for content viewing apps beyond browsers) that detect those references in pages and add a button (either in-page or just through the extensions’ icons) to make a micro-donation of a pre-configured amount. The logistics of the actual payment could be either centralised via the maker of the extension, through a back-end of theirs, or decentralised with the micro-payment happening on the fly. I’m not sure the latter would work easily (due to identification on the payment sites etc.) so I favour the former, whereby the experience could be tweaked nicely to make the consumer feel good about what they are doing (monthly review of pending payments, single payment that gets dispatched into smaller payments, last-minute adjustments before confirmation, etc.)

Thus the experience for a content consumer would be as such:

  • follow a link to a nice video on some PeerTube instance
  • enjoy the video so much that they think the creator should be compensated, since they’re not getting anything from the instance the video was watched on
  • click the “Give 10 cents” button in the page or browser, just like they would click a Like button today
  • go on about their lives
  • at the end of the month, get a reminder from the extension creator that they have donations they can now fulfill. They would then:
    • review them
    • optionally make individual changes (still time to change your mind)
    • optionally readjust the amounts automatically to match a desired total monthly spend (I’ve clicked a lot, but I want to spend no more than $10)
    • confirm and go through all the payments in one go. Ideally, they’d make one payment to the centralised platform and then the platform would dispatch the money - if that can work.
  • down the road, we could even imagine having statistics on who the user gave money to over the last year etc. This would help people feel good about supporting creators they like.

Note that this approach is a bit too desktop-centric. Although the Firefox browser is about to get support for extensions on mobile, other mobile browsers don’t offer this. Since many people consume content from mobile devices, we need a solution for this too. A first thought could be the inclusion of buttons with custom protocols, triggering either the extension (on desktop) or an app (on mobile) to process the page and retrieve the embedded donation references.

Illustrations

Here are a few of the world’s ugliest diagrams I did in 5 minutes to illustrate a bit better.

On-site experience: a simple confirmation toast after a one-click micro-donation is earmarked diagram of a website and the micro-donations extension

End-of-month donation review and confirmation diagram of a donation review screen

Recap of the cash flows in the case of a centralising entity aggregating payments diagram of cashflows between content consumers and content creators, centralised through an entity, with a single monthly payment for each consumer, and a single monthly incoming contribution for each creator

Would this help at all?

I think it could. Here’s the kind of virtuous circle I envisage, if critical mass can be achieved:

Positive reinforcement loop diagram

About centralisation

It must be highlighted that this system includes a centralising party, to collect and distribute the payments, which may lead people into concluding: “why replace one type of centralisation with another?”. The answer however is quite clear: we’re talking about very different types of centralisation.

One the one hand side, we have monopolistic companies with extremely strong lock-in effects, and borderline racketeering redistribution policies. Which come hand-in-hand with all the privacy abuse we want to avoid.

On the other hand side, we would have completely replaceable entities, fully independant from the places where content is hosted. People could choose to switch entities without any side effect if they so desire. Those entities would be compelled to promote transparency and reasonable processing costs, lest another, better entity spawns and replaces them. Zero lock-in, and no need to compromise privacy. We could even see variations of the flows I’m proposing here, using the same underlying standardised data embeddings, bringing more diversity to the picture. To me, this is a clear case of “bad centralisation” vs. “good, contained centralisation”.

How do we start?

I believe a core set of platforms to start with would be:

  • PeerTube
  • Owncast
  • Wordpress

I’ll add that I’m not an expert in the fediverse or other open platforms, so my selection may be good or may not be good. But the main thing that matters is that the platforms joining the early effort have no conflict with the initiative, in that they do not rely on advertising to get financed.

Of course, the specs for the standard itself, and a proof-of-concept browser extension would be needed to convince anyone to come onboard. For now I was thinking of a meta header:

<meta 
  name="open-micro-donation-channels" 
  content="paypal:[email protected]; kisskissbankbank:username; tipeee:username" 
/>
<meta 
  name="open-micro-donation-identification" 
  content="SuperCreator"
/>

The purpose of the open-micro-donation-identification header would be to help the donation app remember who they decided to give money to.

Caveat: I see a risk of people re-hosting (stealing) content and diverting revenue to their accounts. Some kind of identity verification would help. Maybe the idea of one or more centralised address books gets some more viability from this consideration (it works, for example, for public PGP keys for email encryption). Or we could tie this with the <link rel="me"> concept used to show the same-owner relationship between pages. I welcome ideas about this!

In addition, as mentioned earlier, a custom protocol would be useful. Browsers seem to support custom protocols starting with web+, so URI such as web+microdonation:https://original.content/page or possibly directly web+microdonation:[email protected];tipeee=userid;url=original.content/page to avoid having to reparse the page, could be the direction to go.