The Interledger Community 🌱

Cover image for Web Monetization on the Social Web — ILF Grant Final Report
Jeremiah Lee
Jeremiah Lee

Posted on

Web Monetization on the Social Web — ILF Grant Final Report

Note: I will use the term ‘social web’ instead of ‘fediverse’ to refer to federated, decentralized social networks.

Digital creators of all kinds across the world will benefit when they can fully own their social media presences, content distribution, relationships with their audiences, and compensation methods. The Interledger Foundation’s support enabled me to make significant contributions towards realizing this goal by adding support for micropayments to social web apps.

There’s a line in The Lion Tracker’s Guide to Life: “I don’t know where I’m going, but I know exactly how to get there.” It means that sometimes you know the end goal, but the path to it is not obvious. Instead of worrying, you trust your skills and work methodically towards the goal.

My technical goals for my ambassadorship were to publish a Fediverse Enhancement Proposal that defined how to include payment pointers in the Activity Streams 2.0 specification and to submit a pull request to the Mastodon project implementing the FEP. These remain my goals, but they are not yet accomplished. I completed significant portions of both goals, but releasing them publicly at this point would be counterproductive to achieving the goals.

I believed the most significant risk to my work was triggering strong opposition to the introduction of monetization to the social web. Early adopters previously were critical of the introduction of full text search and I did not want to repeat that situation. I attempted to mitigate this risk by engaging with many Mastodon community server operators, social web app developers, and end users. I participated in 3 community events to workshop ideas and conducted over 20 interviews.

Community server operators are concerned about how to fund the increasing cost of providing service. Creators are unsatisfied with their monetization options on Mastodon compared to centralized social networks. While skeptical of monetization proposals and vendors, early adoptions of the social web are open to ideas.

Few people had heard of the Interledger payment network prior to my conversation with them. The recurring immediate questions were if it was cryptocurrency (no) and if it was the most viable option (maybe). The Interledger payment network appealed to these people because it was globally focused, championed by a non-profit, and federated in design—just like the Web. However, the lack of operating wallet providers and a browser extension kept people from embracing my proposal.

The Interledger payment network only gets one shot at a first impression. It has to be strong. I am withholding the introduction of a Fediverse Enhancement Proposal and Mastodon pull request until I can demonstrate everything working end-to-end with real money, without demo hacks, and reproducible by others.

Like a lion tracker, I don’t know where I’m going, but I know exactly how to get there—and I will get there.

Even without the FEP and Mastodon pull request published, my ambassadorship resulted in:

  • improvements (1, 2) to Google Cloud Platform’s official Terraform provider (Interledger Foundation’s cloud infrastructure provider)
  • eased Mastodon deployment on Google Cloud Platform
  • bug fixes to Mastodon (1, 2)
  • the launch of
  • tentative refinements to the proposed Web Monetization specification
  • broadened community outreach and engagement with digital creators and early social web users
  • actionable research findings on digital creator monetization methods
  • participation in the Interledger Summit as a panelist, presenter, and hackathon judge
  • the launch of the Stockholm Social Web Meetup and plans to support expansion in more cities
  • advising Interledger community members on strategies and technical approaches

I am proud of this work and am grateful to have had the foundation fund it.

Open questions about open payments

By meeting a complex, real world use case, the proposed Web Monetization specification draft has been tested. The Web Monetization specification drafts have focused on a single-author, webpage-centric use case. The Mastodon use case is a web application with content aggregated from multiple authors. Both are valid use cases of the Web platform and need to be accounted for in Web Monetization’s design.

One such detail was how to specify a payment pointer in JSON-LD, the data format used by Activity Streams 2.0 and other W3C specifications. The current Web Monetization specification draft only defines how to specify a payment pointer in HTML. Progress was made, but open questions remain and block completion of my work. The Web Monetization working group decided to establish a namespace on, but continues to debate whether to rename payment pointer to wallet address and whether to adopt Decentralized Identifiers (DIDs) as the data format.

Another detail was how to handle multiple monetization tags. Earlier drafts permitted one monetization tag per webpage. The 2023-09-20 draft supports multiple monetization tags, but leaves several implementation details unanswered.

  • What happens in a Tweetdeck-like view when there are 30+ posts with unique monetization tags visible at once?
  • How should user agents send payments when the number of active payment pointers exceeds the user agent’s limit on concurrent HTTP requests?
  • If there were 30 active payment pointers, is the payment rate being multiplied by 30 (spending 30x as much) or being split 30 ways?
  • How frequently should the user agent / monetization provider send a payment anyway?

While W3C specifications vary in specificity of implementation details, I believe the current Web Monetization draft is too vague and that these implementation details will determine its success or failure. Technical specifications exist to create certainty in the user experience across user agents.

Lastly, I believe the 2023-09-20 draft of the Web Monetization specification needs additional functionality to meet how users expect micropayments to work. This belief is based on my interviews with digital creators and countless conversations at events during my ambassadorship. While my ambassadorship has ended, I continue to work on an additional proposal and hope to share that in the next week.

Real progress on audacious goals

I want to change the primary revenue model of the Web from invasive advertising to audience-supported creation.

This can be accomplished by building payments into the browser as a platform feature of the Web and by adding a social interaction layer onto websites to liberate creators from controlling, closed content platforms (eg Instagram, Twitter, TikTok).

Once the Interledger payment network is production ready and Web Monetization matches user expectations for passive, attention-based creator compensation, audiences will be able to support creators on the social web. This will accelerate the virtuous cycle of attracting more creators to the social web away from centralized platforms which will attract more people to join the social web.

I am grateful for the support from the Interledger Foundation and community during my ambassadorship. I intend to keep working in this domain as much as I can. A better social media experience for people and creators is possible, plausible, and within reach with continued support.

You can follow me on the social web at

Top comments (3)

gfam profile image

Well done Jeremiah! What do you think would need to be in place for you to be able to demonstrate everything working end-to-end with real money? Does it require work from Fynbos and/or Rafiki? Or something else?

jeremiahlee profile image
Jeremiah Lee

To demonstrate everything working end-to-end with real money, we need:

  1. The new Web Monetization browser extension to be ready
  2. An account servicing entity (or 2) using Rafiki or their own implementation of Open Payments protocol
  3. Final approval from Web Monetization working group on my proposal for representing wallet addresses (fka payment pointers) in Activity Streams
  4. A Mastodon instance (or 2) running my feature branch
gfam profile image

Ah, thanks for putting that together so clearly!

Even though I've been in this space for so long, I still get confused with all the technical requirements, but hopefully 2024 brings all us all those remaining pieces.