FediForumTM

Virtual Unconference

@fediforum@mastodon.social

FediForum September 2023:

Session: Web Monetization for the Social Web

/2023-09/session/4-a/

Convener: Jeremiah Lee

Participants who chose to record their names here (12 total):

  • Jeremiah Lee (@Jeremiah@alpaca.gold)

  • Christel van der Boom (@xtel@flipboard.social)

  • Anca Mosoiu (@anca@mastodon.xyz, @anca@allpeep.social, @anca@peep.anca.tv)

  • Lisa Dusseault (@lisarue@mastodon.geekery.org)

  • Andreas Sander (@andi1984@social.saarland)

  • Tom Cross (@decius@ioc.exchange)

Notes

Jeremiah presentation on building micropayments into federated social media, to support creators in a passive way.

Client-side:

Existing micropayment solutions are not yet set up for social web

Browser would provide the UI for micropayments

Issues w/ monetization in native apps might be on the mobile app stores

ServerSide Payments

Payments for interactions, payments based on number of followers, etc.

FEPs

[My complementary suggestions from FairPay perspective: https://www.fairpayzone.com/2021/04/web-monetization-and-payments-meet.html (Richard Reisman @rreisman@techpolicy.social) also https://www.fairpayzone.com/2018/11/the-case-against-micropayments-from.html]

Web Monetization is the name of a proposed standard for streaming micropayments within the W3C Web Platform Incubator Community Group. https://webmonetization.org/specification/

Build payments into the platform

Lots of companies have tried to do micropayments on the Web and they’ve all failed so far. I think the biggest reasons have been a distrust of a single vendor, US-centric offerings, and the challenge of walled garden social networks where most creators host their work. Great idea worth iterating on and if we build micropayments into the Web platform as a feature, just like we built social on top of the Web platform, in an open ecosystem way, a better outcome is possible.

The Web Monetization proposed standard is an attempt to do this. It can be implemented via a browser extension, but major browser vendors have expressed interest in the proposal at the last 2 W3C TPACs.

Browser extension work: https://github.com/interledger/web-monetization-extension

Here are the parts involved.

  • Websites

    • <link rel="monetization" href=""> A link monetization tag allows specifying a payment pointer, which is an Open Payments API endpoint. This is basically the recipients digital wallet address.

    • onmonetization events the webpage can listen for and react to.

  • Digital wallet providers: Because we’re dealing with money, we need regulated financial account serving entities. These can be banks and other similar providers. Any provider that implements the Open Payments API specification can participate in the ecosystem.

  • Browsers

    • UI to link wallet provider

    • payment streaming

    • UI indicator, management

For end users, it will involve linking their digital wallet to their browser and setting a budget. Then, as they browse the Web, their browser will stream micropayments to creators as it encounters content that’s been tagged. Websites can then decide what to do when they detect a payment, like turning off ads, disabling a pay wall, or providing other benefits.

As for how much money are we talking about, that’s up to the user to decide, but I like using the Big Mac index. It is based on the theory of purchasing-power parity which states that currency exchange rates should equalize identical goods and services in any 2 countries over the long run. So take that price, divide by the average amount of time you spend consuming content online a month and that’s a good rate. https://www.economist.com/big-mac-index

Web Monetization for the social Web, not just the Web

The challenge with the fediverse is that people don’t go to a creator’s website to see the creator’s work. People see content aggregated on their instance, or more actually, they see content that has been pushed to them by the people they follow. So creators need to attach a payment pointer as meta data to every Activity Streams object they post. The fediverse server needs to store that meta data and also serve that meta data in the Web front end as a tag so that someone’s browser can stream micropayments to the creator.

Jeremiah working with the Web Monetization standards group on how they want that meta data to be declared on Activity Streams objects and will then submit a Fediverse Enhancement Proposal https://jeremiahlee.github.io/web-monetization-vocabulary/index.html

Other challenge is that many people use native mobile apps to browse the fediverse. And Android and iOS have strict requirements regarding anything payment related. We could easily build a native SDK for fediverse apps to include to stream payments, but native apps would risk getting blocked by the Apple or Google app stores until both of those companies embrace Web Monetization beyond the browser. (Example: https://www.computerweekly.com/news/365534673/Developers-say-Apple-and-Google-are-running-app-store-monopolies )

Approach 1: Just use Web Monetization for streaming micropayments like intended

Approach 2: use Web Monetization payment pointers, but don’t use streaming micropayments. Instead, people would set a budget/period and then that money gets distributed amongst their community server, everyone they followed, every post they hearted, and every post they boosted that week or month. Still requires payment pointer meta data, just used for payments at end of period instead of streaming.

Example: 1.00 / week 0.10 credit card fee 0.15 community server 0.75 following, favs, bookmarks, boosts

Servers: 7.80/year per user Creators: 1000 FFBB and follower follows 500 people, €1.50/week 50k FFBB: €3900/year

Who is leading this?

Fynbos (US), Gatehub (EU), and other financial institutions working to implement Open Payments API to serve as many countries (100+) as possible as soon as possible

Open Payments Spec - support subscriptions

Is there an example for “Patreon” for Web Monetization? Will try and find it

Question: How do we get this adopted?

Question: So does this allow for different models, or is it only pay per click? Yes. Browser-based, streaming (Streaming Micropayments), and server-side

Igalia : https://www.igalia.com/ working on Chromium implementation

  • contributes code to multiple browsers, working on micropayments features to contribute to Chromium right now

Jeremiah’s 15 minute presentation on the fediverse, creator economy, and Web Monetization

https://community.interledger.org/jeremiahlee/interledger-joins-the-fediverse-30fi

Also NanoPayments https://blog.orchid.com/introducing-nanopayments/

TigerBeetle ledger database used by Rafiki,, an implementation of the Open Payments API specification https://tigerbeetle.com/blog/2023-09-19-64-bit-bank-balances-ought-to-be-enough-for-anybody/ https://github.com/interledger/rafiki

I did not say this in the session but wanted to add a note about it later - it would be very helpful if Mastodon instances had a standardized way of advertizing a place where they can receive electronic payment, even if other facets of a micropayment architecture are not realized.

An architectural problem with Mastodon is that clients (like mobile apps, or Feedseer) contain the user interface (and thus have the ability to demand payment from users) but much of the cost associated with infrastructure and moderation are borne by server instances. If there was a standard location that instances could receive payment, this would, at least, enable clients that collect payments to route some of that revenue, systematically, to the instances that support their users (and I think users would appreciate it if they could support both their client and instance with a single payment).

Adoption of such a standard by Mastodon might help spur other parts of a micropayments system to come online even if it does not, in and of itself, address every question or issue raised by payments.