A new payments company has many hard problems, and distribution is the hardest of them. Rails, fraud, settlement reliability, compliance: none of it matters until you reach the users, and most consumer fintech startups don’t die from broken rails. They die from never getting there. The crypto-native answer (token incentives, airdrop campaigns) works for some segments but is structurally wrong for the creator economy. The people you most want using the rail are musicians, photographers, writers, podcasters, and livestreamers. They aren’t onchain natives, and they aren’t going to become onchain natives because someone airdropped them a governance token.

The open-source creator stack is where the audience already lives. The communities are real and growing, the projects are explicit about needing payment primitives they can’t build themselves, and the data structures payments would need to settle against are already in their public APIs. A self-hosted music server logs every play. A live-streaming server fires a webhook the moment a viewer joins and again the moment they leave. A photo library knows who took each picture and how many times each shared link has been resolved. A feed aggregator emits a stable identifier for every item it passes through. None of this data has had a payment layer attached because, until very recently, the per-event unit was uneconomic to settle. The fee floor that constraint imposed is what the Liberapay Comparison section below explains, and what rail-level batched settlement (Gateway-style nanopayments, x402 on top) has finally moved out of the way.

The build path falls out cleanly. Eight concrete companies, in the order we’d ship them, are written up below as a Request for Payments Founders:

  1. The Subsonic-Protocol Scrobble Sidecar (music)
  2. The MusicBrainz Payee Registry (music metadata)
  3. The Owncast Per-Second Streaming Webhook Sidecar (live video)
  4. The Jellyfin Per-Minute VOD Sidecar (personal-media VOD)
  5. The PeerTube Payments Plugin (federated VOD)
  6. The Mastodon Donation-Campaign Provider (fediverse fundraising)
  7. The LLM Crawler Citation-Toll Layer (feeds)
  8. The Settlement Core (the durable substrate under all of the above)

Each one names a concrete thing to build, the upstream surface it attaches to, and what makes it the right next thing. The rest of this post is the supporting evidence: why the fee floor finally dropped, what each community has accepted in its PR history, where the data structures already live that a payment layer would read against, and which projects have shipped their own end-to-end payment stack and therefore call for a different value chain.

The Landscape · The Liberapay Comparison · Choosing an Integration Shape · What’s Already Been Accepted · Music: Scrobble Logs · Video: Per-Second Webhooks · Photo: Shared-Link Resolves · Feeds: Citation Tolls · When Permissioned-Only Wins · Where to Start · Conclusion

The Landscape

The projects in this space sort into eight categories by what they do for creators. The categories aren’t a strict taxonomy. They overlap (a podcast host is also a publishing CMS, a Subsonic server is also a music client through its API). But they’re the cuts that matter when picking where to attach payments.

Category Major projects What it emits
Music server + protocol Navidrome, Koel, Mopidy, Snapcast, Lidarr, Ampache, Polaris, Gonic, Airsonic, plus Subsonic clients Feishin and Supersonic Per-listen scrobble events via the Subsonic protocol
Music metadata Beets, Picard, Maloja Tagging + provenance graphs for tracks
Live + VOD video Jellyfin, PeerTube, Owncast Stream events, view records, channel activities
Photo libraries Immich, PhotoPrism, Ente, Darktable, LibrePhotos, Lychee, Piwigo Asset ownership, EXIF provenance, shared-link resolves
Podcasting + audio Audiobookshelf, AntennaPod, Podgrab, Castopod Listens; Podcasting 2.0 <podcast:value> tags where supported
Feeds + RSS RSSHub, FreshRSS, Wallabag, Miniflux, Commafeed Item-level provenance + author URLs
Publishing + newsletter Ghost, Halo, Listmonk, Postal, Grav, Publii, Mailtrain, Writefreely, Plume Subscriber + member events, post views, email opens
Fediverse + social Mastodon, Lemmy, Pixelfed, Bookwyrm Federated activity stream (boosts, replies, follows, and attribution URIs)

The kind of person who runs one of these self-hosted servers is the kind of person who could plausibly deploy it: technical, evaluative, in the market for the software. Operator counts are hard to come by directly, but GitHub stars on each repo are a usable proxy, enough to decide which vertical to attach to first.

Music, live video, photo, and feeds expose the cleanest event streams for per-event settlement (per-listen scrobble, per-second viewer presence, per-resolve shared link, per-citation item URL), each mapping directly to micropayment-grade settlement with integration code short enough to read in full. They aren’t the only attachment points. The fediverse layer (Mastodon, Lemmy, Pixelfed, Bookwyrm) emits a multi-author federated activity stream that’s its own substantial surface, and Mastodon in particular has just landed the most concrete in-tree fundraising primitive in the entire creator stack. That’s worth taking up first, even though it doesn’t fit cleanly into the per-event framing. The publishing layer mostly handles its own payment path: Ghost is payment-native by design, and the others ship donation-pointer integration. Podcasting is an outlier with a protocol-level payment primitive (<podcast:value>) that resolves the question of where to attach differently from the rest. Each row is a potential bootstrap channel for a payments company, with different shapes, audience sizes, and upstream postures, all with a real audience already present.

The four cleanest cases:

Vertical Anchor Repo Community Existing Data Structure Settlement Surface Incentive Mechanism
Music navidrome/navidrome 19.5k stars + Subsonic family scrobbles table (mediaFileId, userId, timestamp) Plugin (scrobbler adapter) or sidecar tailing SQLite User-centric royalty: monthly $X split by listener’s actual plays
Live video owncast/owncast 10.9k stars (live) + 14.6k stars PeerTube (VOD) userJoined / userParted webhook events Webhook-subscriber sidecar Per-second pay during proven presence
Photo immich-app/immich 88.8k stars, dominant share of self-hosted photo deployments Shared-link controller with ownerId on every asset Wrapper / access-log tail on GET /shared-link/:id Fractional license fee on each external resolve
Feeds DIYgod/RSSHub 41.3k stars + downstream LLM crawlers DataItem.link + DataItem.author (canonical source URL) Middleware at RSSHub or at the LLM crawler boundary Citation toll when an LLM grounds an answer in the item URL

The four verticals share one pattern: an external process (sidecar, wrapper, plugin, or middleware) reads a settlement-grade event stream that the upstream maintainer is not currently treating as one. There’s no fork to maintain and no roadmap to wait on.

The Liberapay Comparison

The closest existing open-source payments rail for creators is Liberapay, and the comparison is the cleanest single argument for why an onchain substrate fits the creator stack and the existing fiat-rail solutions don’t. Liberapay is open-source (CC0 public domain) and it’s the name that comes up over and over again in the FOSS creator stack: in PeerTube #1586 as the official monetization recommendation, in the Bookwyrm / Pixelfed / Lemmy donation-pointer PRs as the suggested external service, and in the Jellyfin maintainer’s pointer to individual-developer GitHub Sponsors as a parallel option. Wherever a creator-stack project gestures at recurring patronage, Liberapay, Open Collective, and Patreon are the three names that surface. The codebase tells the story of why those services had to be the names, and what changes when the rail underneath them changes.

Liberapay is open-source code with an explicitly centralized deployment. From its README: “This webapp isn’t self-hostable. Liberapay is a centralized platform that acts as a trusted third party, you can’t host your own instance of it. What you can do is fork Liberapay, but you have to come up with a new name and logo.” That position is unusual in FOSS, and the architecture is the reason.

liberapay/payin/stripe.py and liberapay/payin/paypal.py are the only two payment integrations in the codebase, and PAYMENT_METHODS in liberapay/constants.py enumerates exactly three options:

PAYMENT_METHODS = {
    'paypal': "PayPal",
    'stripe-card': _("Credit/Debit Card"),
    'stripe-sdd': _("Direct Debit"),
}

No crypto rail. The economics of running on top of those rails appear in the same file, in PAYIN_AMOUNTS, with the fee-percentage commented inline:

PAYIN_AMOUNTS = {
    'paypal': {
        'min_acceptable':  Money('2.00',  'EUR'),  # fee > 10%
        'min_recommended': Money('10.00', 'EUR'),  # fee < 8%
        'low_fee':         Money('40.00', 'EUR'),  # fee < 6%
        ...
    },
}

The comments are the data. At $2 the per-transaction fee exceeds 10% of the payment; at $10 it’s still over 8%; the fee drops below 6% only above $40. That is the fundamental constraint Liberapay was built to work around. The solution is batching. Donations accumulate weekly per donor-recipient pair (the cap is $100/week per pair, per DONATION_LIMITS_WEEKLY_EUR_USD = (Decimal('0.01'), Decimal('100.00'))), and the payment processor batches multiple donors’ contributions before paying out to a recipient. Liberapay’s payin (donor → platform) and payin_transfer (platform → recipient) tables exist so that one donor’s single weekly debit can fan out to many recipients without paying the per-transaction fee N times. The settlement delay (PAYIN_SETTLEMENT_DELAYS = {'stripe-sdd': timedelta(days=5)}) is the operational cost of running on top of the underlying bank rails.

Three constraints fell out of this architecture, and each one shapes the entire category of open-source payment rails for creators:

  1. Centralization was forced, not chosen. A self-hosted Liberapay couldn’t batch across donors because each instance would only see its own donors; the fee floor would dominate every payment, and small donations would be uneconomic. The “we centralized to make small donations work” justification is in the architecture, not the README’s politics.
  2. Per-event settlement is impossible. Settlement happens on weekly cadence (or longer with Stripe SDD’s 5-day delay). A creator can’t be paid the moment something happens. The unit of accounting is “the donor’s pledge for the week,” not “the listener’s per-play tip.”
  3. The unit of value can’t be smaller than ~$2. Per-listen, per-second, per-citation, per-photo are below Liberapay’s min_acceptable floor on PayPal and well below min_recommended on Stripe. The category of open-source payment rails for creators as it has existed is bounded by the fiat-rail fee structure, and the category’s most-cited service is bounded by it more obviously than the rest.

Onchain settlement inverts every one of these constraints, but not by abandoning batching. It moves the batch one layer down. Circle’s Arc Nanopayments, built on Circle Gateway, is the cleanest example of where that re-layering goes. The buyer signs an EIP-3009 authorization offchain for each x402-protected request; the seller verifies the signature and serves the resource immediately; Gateway aggregates many signed authorizations and settles them onchain in bulk. The economic shape is familiar (one onchain transaction settles many payments) but the consequences are different from Liberapay’s. There is no centralized fundraising platform in the trust path. Settlement minimums fall to fractions of a cent ($0.000001 USDC is the documented floor). Buyers and sellers don’t pay per-transaction gas. The “we centralized to make small payments work” workaround is replaced by “we batch settlement while leaving authorization offchain and individual.”

That changes everything about what the upper layers have to look like. Settlement becomes per-event-authorized even when net positions settle in bulk: a creator can be paid the moment something happens because the seller treats the signed authorization as final. Trust becomes protocol-mediated rather than platform-mediated: the operator of an Owncast sidecar runs a payments integration without a Liberapay-equivalent in the middle. And the unit of value floor drops from $2 to fractions of a cent, which is exactly the range the per-listen, per-second, and per-citation primitives the verticals below operate in.

Liberapay is not a competitor. It’s the category’s existence proof of what the fiat rails make possible and what they don’t. A creator-payments founder building on x402 plus a batched-settlement rail like Arc Nanopayments inherits the problems Liberapay solved (multi-currency conversion in liberapay/i18n/currencies.py, donor-to-recipient batching state machines, dispute and chargeback handling, recurring-pledge UX, identity verification, KYC) and is freed from the problems Liberapay couldn’t solve (per-event granularity, sub-cent payments, permissionless deployment, instantaneous receipt from the seller’s view). payin/stripe.py has nine years of production hardening on the parts of the problem that don’t go away when the rail changes; the batching architecture is a workaround, not a template. The platform-side batching is the workaround; the rail-side batching (Gateway-style) is the upgrade.

The same advice runs the other direction for established creator projects. Ghost and Ente both wrote their own Stripe integrations because there was no acceptable rail underneath them. If there had been an onchain substrate with nanopayment economics they could trust, those teams might never have shipped their own billing stack at all. The category-level convergence among photo libraries (covered in When Permissioned-Only Wins) isn’t permanent. It was forced by storage cost on top of fiat-rail cost. Onchain settlement removes the second half of that compound constraint; the first half stays (storage is still expensive), but the obligation to ship an entire payment stack inside the project’s repo to deal with it goes away.

Choosing an Integration Shape

The natural instinct is to ask the maintainer to add a payment field: a creator_wallet, a stripe_account_id, a paymaster_endpoint. The structural answer is that they don’t have to. The self-hosted creator stack is intentionally minimal: navidrome, immich, peertube, and mastodon all build around “your data, your server, no third-party dependencies,” and that minimalism is a feature their users specifically chose. Their maintainers (immich’s bo0tzz, listmonk’s knadh, navidrome’s deluan) work with small core teams and full backlogs, focused on the experience the median self-hoster runs. A founder wanting payments doesn’t need them to change any of that. The public APIs and data structures already expose what a payment layer needs to read.

Permissionless integration (code that adds payments through the project’s public surfaces, without modifying the upstream) has at least five workable shapes:

Pattern Where it attaches Permission cost
Plugin Inside the server’s plugin loader, when one exists (beets plugins, navidrome’s external scrobblers, peertube plugins, immich plugins) Zero. Upstream sanctioned plugins ahead of time
Sidecar Separate process subscribing to webhooks, polling APIs, or tailing logs Zero. Upstream API is public contract
Wrapper / reverse proxy In front of the server, mediating requests and injecting payment metadata Zero. Operator installs at the deployment layer
Federation peer A new ActivityPub server on the federation observing public activities (boosts, replies, follows) Zero. Federation is open by design
Client fork Modify a Subsonic / ActivityPub / RSS client to settle alongside its existing actions Zero. Client diversity is a feature, not a bug

There are heavier paths too. A founder building infrastructure that depends on a specific behavior change can ship a modified node: a maintained fork of the upstream with payment integration baked in, distributed as its own binary alongside the original. That trades the upstream’s update stream for full control of the behavior surface. The heaviest path is a protocol fork: take ActivityPub or Subsonic, change the wire format, recruit clients onto the new protocol. Almost never the right call (coordination costs explode), but the option exists for a founder whose product requires protocol-level guarantees the upstream won’t provide.

Permissioned paths are sometimes the right answer. Where the upstream’s plugin system is mature and the maintainers are philosophically aligned with monetization plumbing, an in-tree integration can be cleaner than a sidecar: the plugin loader is the upstream-sanctioned attachment point and the integration inherits the project’s distribution. PeerTube accepted a Stripe-webhook-compatible req.rawBody patch in 2024 specifically to let monetization plugins work, and that’s a stronger position than running a sidecar in front of the server. Which projects accept what, and which reject even cosmetic monetization references, is the empirical answer to “permissioned or permissionless?”

The model relies on those upstream APIs being load-bearing. Subsonic’s scrobble endpoint hasn’t broken its wire format in eight years. ActivityPub’s Announce activity has the same shape it had in 2018. RSS items have had the same <link> and <author> fields for two decades. The contract a permissionless integration binds against is older than every payment rail it would settle against, and coupling against that contract is cheap.

Per-listen royalties, per-second pay, and per-citation tolls each correspond to an incentive structure more honest than the subscription or platform-pool mechanisms currently filling those gaps. Each vertical below names that incentive structure and the existing data structure in the upstream server that already encodes the inputs a settlement layer would need.

What's Already Been Accepted

Across the fediverse and the self-hosted media stack, the pattern is clear: server-administered donation pointers get merged; per-user payment plumbing does not, except where the project has chosen to ship its own end-to-end payment stack. The three cases worth reading in depth are PeerTube, Mastodon, and Immich, each illustrating a different shape of the maintainer-payment question.

PeerTube: seven years of unresolved monetization discussion

PeerTube’s longest-running monetization discussion is Chocobozzz/PeerTube#1586 (“Monetization, a list of ethical and privacy-respecting ways Peertubers can make money”), open since January 2019, with 115 comments and last activity October 2025.

The opening pins the constraint. PeerTube’s official answer is a creator-controlled “support” button under each video that displays freeform text, images, and links, where creators put a Patreon, Tipeee, Paypal, or Liberapay link. The explicit limit, in the issue body itself: “a monetization system that favors the users of big instances will kill decentralization.” That constraint shapes everything the thread has produced since.

Seven years of community proposals follow, none of which became in-tree features. Crypto donations were raised in the first reply by Nutomic (a contributor) and have returned every year (Bitcoin, Monero, Duniter, and others). By 2025 two camps had crystallized: a Monero-only purist faction (PeerTube should stay ideologically pure, censorship-resistant payments only) and a broader-access faction (PeerTube needs both crypto and traditional rails for “the average person”). Neither side won. Patreon and Liberapay integration were requested repeatedly; Patreon has an API, Liberapay doesn’t, and neither got built into core. Paywalled-archive models (latest video free, older content gated) were discussed across multiple comments; not built. Advertising was almost universally rejected as fundamentally incompatible with the project. A community-built peertube-plugin-web-monetization attempted to add a payment primitive via the plugin loader; it has gone unmaintained, and as recently as October 2025 a user is asking in the thread whether it still works.

The de facto status in 2025, summarized by community members in the thread itself, is that PeerTube ships neither an in-tree payment primitive nor a maintained plugin. The workaround creators have settled on is password-protected videos (added in PeerTube 6), with passwords distributed through external systems like Mitra (a separate fediverse platform that supports subscriber-only posts plus Monero payments), Shadowchat (crypto-friendly chat), or XMRChat (Monero superchat). The viewer retrieves the password from one service and pastes it into another. It works but it’s clunky.

PeerTube stays neutral on payment mechanism by not implementing one in core, leaving the plugin layer as the place the community has tried (unsuccessfully) to fill the gap. The maintainer (Chocobozzz) has commented only once in seven years on the thread. A maintained payments plugin walks into a market with 115 comments and seven years of demand, a clear plugin-loader attachment point, and a previously-attempted reference implementation that has gone stale. No current incumbent. PR #6300 (the req.rawBody Stripe-webhook utility) is a small enabling patch downstream of this posture, not a project statement. The project statement is in #1586.

Mastodon: a decade of refused demand, just opened

The single most concrete signal that the open-source creator stack is opening up to payments in 2026 is what just landed at Mastodon. mastodon/mastodon#37880 (Add GET /api/v1/donation_campaigns) merged in early 2026, written by core developer ClearlyClaire. It adds a server-side endpoint that fetches a donation-campaigns API and caches the response. The companion #38223 (Use to_json call in donation campaigns) also merged.

A small PR by Mastodon’s standards. The context is what makes it big. Mastodon team member renchap (Renaud Chaput, a core dev) explains in the PR discussion that the work is the direct continuation of an official Mastodon blog post about funding, and that the team intends to “build upon this to, in the future, offer a way for any server to run their own fundraising campaigns.” That is Mastodon publicly committing to building out in-tree fundraising primitives, for a project that for nearly a decade refused to ship any.

The decade of refused demand makes this signal meaningful. The Mastodon issue tracker carries payment-related feature requests stretching back to 2017 that, until this PR, almost none of which moved: #5380 Make financial supporters visible (opened 2017, 12 comments), #8425 “Fund/support this instance” link (2018), #11324 Paid registrations mode (2019, 23 comments), #12385 Content for paying followers (2019), #17294 Make donations easier (10 comments), and #34289 Have option to setup paid accounts in admin menu (6 comments). The answer was no for years. The answer changed when funding Mastodon itself became operationally pressing.

Mastodon has just opened an in-tree slot for fundraising-campaign providers. The new endpoint expects external campaign data to be cached and surfaced; whoever ships first as a credible campaign source (with onchain settlement, per-instance configurability, and a usable admin flow for instance operators) inherits direct integration with the largest fediverse server. The blog post is explicit about wanting the primitive to generalize to any server running its own campaigns; the road from “Mastodon’s own fundraising” to “Mastodon as a platform for instance-level fundraising” is now navigable.

What the PR doesn’t open is per-user payments to creators on the platform. The official position remains that Mastodon is funding the project and instance operators, not paying individual users. For per-user value flows (paying an author for a popular post, attributing a boost to its original creator, settling per-reply gratuity), Mastodon’s permissionless path is still the only one available. And it’s a real path. ActivityPub’s attributedTo URI on every activity is a multi-author attribution graph the project has had for years and never quite used as one. A sidecar or federation peer that observes the public activity stream and settles per-reshare to the original author’s wallet uses primitives Mastodon shipped a decade ago.

Mastodon is the rare project where a founder has both options simultaneously: the permissioned slot just opened (campaign-source API), and the permissionless lane is still wide (federated activity stream). Most projects in the creator stack sit on one side or the other. The choice between them is a choice of value-chain: instance-level fundraising (Mastodon’s preferred path) versus per-user creator payments (Mastodon’s not-yet-preferred path, with no upstream resistance to building it outside of core).

The donation-campaigns API (#37880) landed; the companion donation-banner UI (#36102) is still open and unmerged. The API is server-administered (the instance operator decides whether to surface campaign data); the UI affects every user’s feed. In-tree slots that are server-admin-controlled land more easily than in-tree slots that affect end-user experience. Pitch the patch the same way Mastodon’s team did: backend primitive first, end-user UI later or never.

Immich: in-tree payments already shipped

Immich shipped its own supporter “license” program in mid-2024 and now funnels support through that channel. immich-app/immich#9207 (chore: remove donation links from the readme, docs and release notes template) is not a rejection of monetization but a consolidation onto the in-tree program. #11890 (a community-proposed GitHub funding button) was closed for the same reason: it would have competed with the in-tree program.

The community pushed back on calling the supporter program a “license” (#11288, #11325) because Section 10 of the AGPL forbids imposing a license fee for software already granted under it: “you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License.” The pushback was about the legal framing, not about whether monetization should exist. The program shipped and remains.

The Immich codebase reflects the in-tree commitment, with substantial purchasing infrastructure:

A sidecar that charges Immich users for accessing the software competes with Immich’s existing program. The opening is a different value chain: per-photographer licensing on shared photos, settling to the photographer named in EXIF or to the Immich ownerId. That’s orthogonal to “support the project” payments and coexists with the in-tree license program. Shared-link resolves still work as the attachment point, but it’s the photographer who gets paid, not the project.

Lemmy and Pixelfed: smaller patterns

The fediverse outside Mastodon has accepted donation surfaces more readily. LemmyNet/lemmy#5552 and #5559 (Donation dialog changes and [0.19] Donation dialog) were both merged, joining the earlier #1785 (Add cardano donation link, also merged). Lemmy accepts instance-administered donation surfaces, crypto-adjacent ones included. pixelfed/pixelfed#614 (Activating Open Collective) and #1315 (Add patreon/opencollective links) were both merged. Platform-mediated donations are the accepted shape on Pixelfed.

The two patterns

  1. Where the project has accepted in-tree payment plumbing, it has been donation-pointer shape. An instance admin configures an external URL (Patreon, Open Collective, donation-campaign), the server surfaces it to users, no per-event accounting. That’s a different design space than per-listen, per-second, or per-citation accounting. The pointer-shape integrations don’t replace a sidecar; they sit beside one.
  2. Where the project has shipped its own end-to-end payment stack (Immich’s license program, and the photo-library category more broadly), the sidecar isn’t a fallback. The founder’s opening is a different value chain that the existing program doesn’t address.

For PeerTube, build a maintained payments plugin in the slot the community has been asking to fill for seven years. For Mastodon, plug into the new donation-campaign API as a campaign-source provider, an in-tree slot designed to be filled. For Immich, build a sidecar that targets per-photographer licensing on shared photos, not project-supporter payments that already have an in-tree owner.

Music: Scrobble Logs as a Royalty Stream

A self-hosted music server has, by design, a complete and honest record of what its user actually listened to. That record is more accurate than what any commercial streaming platform has on the same user. There’s no algorithmic recommendation skewing the play history, no ad break inflating the count, no licensing manager truncating the play. It just is the user’s listening behavior.

Navidrome itself has ~19.5k GitHub stars and is widely deployed in the self-hosted-media community; more importantly, it implements the Subsonic protocol, which dozens of compatible servers and clients also implement. A settlement layer coded against the wire protocol (not against any one server) inherits the protocol family’s combined installed base as its built-in distribution.

Navidrome stores this in three small tables. The first is the scrobble itself, in navidrome/model/scrobble.go:

type Scrobble struct {
    MediaFileID    string
    UserID         string
    SubmissionTime time.Time
}

type ScrobbleRepository interface {
    RecordScrobble(mediaFileID string, submissionTime time.Time) error
}

A media file id, the user who played it, and when. persistence/scrobble_repository.go writes those three values into a SQLite table named scrobbles. The write is triggered by server/subsonic/media_annotation.go when any Subsonic client hits the scrobble.view endpoint at the natural end of a track:

func (api *Router) Scrobble(r *http.Request) (*responses.Subsonic, error) {
    // ...
    err := api.scrobblerSubmit(ctx, ids, times)
    // ...
}

func (api *Router) scrobblerSubmit(ctx context.Context, ids []string, times []time.Time) error {
    var submissions []scrobbler.Submission
    for i := range ids {
        submissions = append(submissions, scrobbler.Submission{
            TrackID: id, Timestamp: t,
        })
    }
    return api.scrobbler.Submit(ctx, submissions)
}

A payment sidecar has three ways to attach to this stream. The lightest is to register itself as an external scrobbler: Navidrome already plugins out to Last.fm and ListenBrainz, and the plugins/scrobbler_adapter.go interface is the seam an x402-settling adapter implements. The second is to subscribe to the Subsonic scrobble.view HTTP endpoint by proxying it. The third, for an instance operator who wants the cleanest decoupling, is to tail the SQLite scrobbles table directly. Navidrome’s database is local, durable, and the schema hasn’t changed in years.

What the sidecar does with each scrobble it sees is decide a payee and a price, sign, and submit. The payee resolution is non-trivial (MediaFileID is an internal id, not a payable address), but it resolves through MusicBrainz, which the server already queries during library scans. The MBID on the media file links to recording credits, which point at artist MBIDs, which an off-chain registry maps to wallet addresses. The first credible x402 scrobble sidecar’s main moat will be the artist-to-address registry it ships alongside the binary, not the Go code that polls the database.

User-centric royalties are the model the major labels have refused to ship for fifteen years. Today Spotify pools every subscription, divides by total platform plays, and pays out pro-rata. Your $10.99 funds whoever is globally popular, mostly not the artists you actually listened to. With a scrobble-bound sidecar, each user’s monthly amount is split only across the artists in their own play history, weighted by their own plays, settled directly. Per-play gating handles the skip case: a play under 30 seconds, the floor Spotify itself uses internally, doesn’t settle. The data has been sitting in scrobbles.sqlite the whole time, waiting to be read as a payee ledger instead of a play history.

The sidecar surface generalizes well across the Subsonic ecosystem. Subsonic is a protocol, not a server. supersonic (Subsonic client), feishin (Subsonic client), gonic (Subsonic server), polaris (Subsonic-compatible), airsonic-advanced, and ampache all implement variants of the same scrobble.view wire format. A sidecar coded against the wire protocol routes against the entire ecosystem. Compare that to the per-app integration model Stripe Connect demands and the contrast is sharp: one wire format, dozens of downstream servers, no upstream merge required.

For a broader attachment surface still, Maloja (1.6k stars) is a self-hosted scrobble server. Its maloja/apis/audioscrobbler.py, audioscrobbler_legacy.py, listenbrainz.py, and native_v1.py all accept inbound scrobbles from any client that speaks Last.fm or ListenBrainz protocols. A payments sidecar attached to Maloja sees scrobbles from anywhere a user has wired a scrobble-emitting client to point at it, not just from Subsonic-protocol clients. Smaller installed base than Navidrome, but a strictly broader attachment shape, and the right anchor for a founder who wants to capture the ListenBrainz audience without depending on the ListenBrainz cloud.

Video: Per-Second Pay from Owncast Webhooks

Live video has a natural unit of value that no commercial platform has fit cleanly: the second of presence. Twitch charges nothing to a viewer who watches for ninety minutes and tens of dollars to a viewer who subscribes; YouTube monetizes through ads that interrupt the experience the creator wanted to deliver. The honest unit (“I was here for the part of the show I cared about, for that long, and I’d like to pay for that”) has had no settlement venue in either model. A sidecar can build one.

The self-hosted video stack is dominated by three projects: Jellyfin (47.9k stars, the largest video repo in the creator stack), PeerTube (14.6k stars, federated VOD), and Owncast (10.9k stars, live streaming). Jellyfin has the most installed base by a wide margin, but Owncast has the cleanest integration surface, which is why it’s the right first deployment even though it’s the smallest of the three.

Owncast: the cleanest webhook surface

Owncast doesn’t need to be modified to support per-second pay. Its webhook system already emits the two events that bracket a settlement window. From services/webhooks/webhooks.go:

type WebhookUserJoinedEventData struct {
    BaseWebhookData
    ID        string       `json:"id"`
    Timestamp time.Time    `json:"timestamp"`
    User      *models.User `json:"user"`
}

type WebhookUserPartEventData struct {
    BaseWebhookData
    ID        string       `json:"id"`
    Timestamp time.Time    `json:"timestamp"`
    User      *models.User `json:"user"`
}

userJoined fires when a viewer establishes presence. userParted fires when they leave (or 15 seconds of silence elapses, the activeViewerPurgeTimeout in services/stream/stats.go). The timestamps on each are server-side and authoritative. The viewer’s User.ID is stable across the session. A payment sidecar registers as a webhook endpoint through Owncast’s existing webhook admin UI, computes parted - joined per session, multiplies by the streamer’s per-second rate, and settles. The viewer’s funding side (a spending-rate authorization signed at session start) sits in the sidecar’s wallet abstraction. Owncast itself never sees a wallet, an address, or a payment. It sees the same join and part events it has always emitted.

The 15-second viewer-prune loop matters as a sanity check: a viewer whose connection drops stops being counted as present within 15 seconds, and the sidecar’s meter pauses at the same moment because userParted fires at the same instant. Owncast’s existing engineering for honest viewer counts is the same engineering a settlement layer needs.

Jellyfin: the largest installed base, a richer session-event surface

Jellyfin is the personal-media-server vertical’s anchor. Its session API lives in Jellyfin.Api/Controllers/PlaystateController.cs and exposes three endpoints that bracket a viewing session:

[HttpPost("Sessions/Playing")]
public async Task<ActionResult> ReportPlaybackStart([FromBody] PlaybackStartInfo info) { ... }

[HttpPost("Sessions/Playing/Progress")]
public async Task<ActionResult> ReportPlaybackProgress([FromBody] PlaybackProgressInfo info) { ... }

[HttpPost("Sessions/Playing/Stopped")]
public async Task<ActionResult> ReportPlaybackStopped([FromBody] PlaybackStopInfo info) { ... }

Every mobile client (Findroid, Swiftfin, Streamyfin) posts to these endpoints continuously during playback. Inside Jellyfin they fan out to the session manager’s event handlers: PlaybackStart, PlaybackProgress, and PlaybackStopped (declared in ISessionManager.cs). The official Jellyfin Webhook plugin already subscribes to these handlers and publishes them to arbitrary HTTP endpoints; its Notifiers/ directory carries PlaybackStartNotifier.cs, PlaybackProgressNotifier.cs, and PlaybackStopNotifier.cs ready-to-ship. A payment sidecar doesn’t write Jellyfin code at all. It installs the Webhook plugin and subscribes to playback-progress events.

The project’s posture leaves the permissionless surface clean. Issue #15580 (GitHub Sponsor Button) was closed in November 2025, with maintainer nielsvanvelzen responding that “the Jellyfin organization accepts donations through Open Collective. We don’t have any plans currently to expand to other platforms.” Same Open Collective at the org level as PeerTube, same lack of in-tree primitive, but with much larger session-event volume to settle against.

PeerTube: the federated VOD case, a permissioned path

PeerTube emits view events through HTTP analytics rather than join/part webhooks, and a PeerTube-side integration would have to attach to its Views controller rather than a webhook stream. There’s also a permissioned path on PeerTube: the project accepted PR #6300 explicitly to support Stripe-style webhook plugins, which means a monetization plugin written for PeerTube’s plugin loader inherits the upstream’s distribution channel for free. The trade against a sidecar is the usual one: give up some decoupling, gain in-tree legitimacy.

One core, three deployments

Live Owncast is the cleanest first deployment because the integration is webhook-clean and the install is trivial. Jellyfin is the second deployment because the largest installed base sits behind the same per-second-rate primitive, with a richer event stream (playback progress reports continuously, not just on session start/stop) and an existing plugin that does the event-publishing work. PeerTube is the third deployment, on a different attachment shape (plugin loader rather than sidecar). One settlement core, three distribution paths into the live + VOD video market.

Photo: Shared-Link Resolves as License Fees

The unit of value in photography is a download. A photograph that is taken once and viewed once has no economic activity attached to it; a photograph that is taken once and downloaded by a thousand people for use in a thousand other pieces of media generates a thousand licensing events. The classical answer is Getty Images and a six-figure search-and-strike legal apparatus. The honest answer is a fractional license fee on each download, paid by the downloader to the photographer, fractional enough that the per-download fee is less than the cost of the strike letter that would otherwise be sent.

The value chain runs from photographer to downloader, not from supporter to project. Immich (88.8k stars and dominant share of self-hosted photo deployments) already ships an in-tree “license” supporter program where the instance operator pays the project, but doesn’t address per-photographer licensing. The gap is the per-photographer one. A sidecar that settles fractional license fees from each external resolve to the photographer named in EXIF fills that gap without competing with the existing program.

Immich’s data model exposes the inputs cleanly. The Asset entity has an ownerId (the Immich account that uploaded the photo) and an EXIF block that preserves the camera-written Artist and Copyright fields. The two are distinct: a magazine editor uploading a photographer’s work would have their own ownerId while the EXIF Artist would still name the photographer. The settlement payee is the EXIF Artist, with the ownerId as a fallback when EXIF is missing. That’s the load-bearing distinction; without it, the sidecar settles to whoever uploaded the photo, which is rarely the person who took it.

The access surface is the shared-link.controller.ts:

@Get(':id')
@Authenticated({ sharedLink: SharedLinkRoute.Required })
getSharedLinkById(
    @AuthDto() auth: AuthRequest,
    @Param('id') id: string,
): Promise<SharedLinkResponseDto> { ... }

@Get('me')
@Authenticated({ sharedLink: SharedLinkRoute.Required })
getMySharedLink(...): Promise<SharedLinkResponseDto> { ... }

@Post()
@Authenticated({ permission: Permission.SharedLinkCreate })
createSharedLink(...): Promise<SharedLinkResponseDto> { ... }

Every shared-link resolution flows through one of those routes, and every one of them knows the asset id, the asset’s owner, and the timestamp of the access. The sidecar attaches as a reverse proxy or access-log tail in front of GET /shared-link/:id. On each external resolve, the sidecar looks up the EXIF Artist for that asset, maps the artist’s identity to a wallet (the registry is the founder’s moat, mirroring the artist-MBID-to-wallet registry on the music side), and settles a fractional license fee from whoever provided the share token to the photographer. Where EXIF Artist is missing (common in family-photo libraries, rare in journalistic and stock-photo workflows), the fallback is the ownerId.

Immich is unusual in carrying both fields cleanly. The shared-link primitive already gates external access through a controlled URL, so the place where a license fee would attach is also the place where access is already gated. EXIF round-tripping through the upload/processing pipeline is preserved (most other photo libraries strip or lossily-rewrite EXIF), which is why Immich is the right anchor even though smaller libraries are more open to in-tree integration. The provenance graph is already two-deep before any payment code is written.

The right early adopters are journalists, photojournalist collectives, and stock-photographer cooperatives: workflows where downloads are the primary economic action, where EXIF discipline is already part of the practice, and where the photographer (not the uploading account) is unambiguously the payee. The family-photo self-hoster case is incidental: the EXIF Artist is usually the same person as the ownerId, downloads are spiky and infrequent, and the sidecar’s value is harder to demonstrate. A founder building this vertical should target the professional cohort first, then generalize once the model of paying the photographer named in EXIF Artist has proven itself.

The economic shape is unusual. A music or live-video sidecar settles continuously; a per-download sidecar settles in bursts. A photo gets shared, gets resolved a thousand times in a day, then sits dormant. The financial picture looks more like a stock-photo licensing business than a streaming subscription, and the founder should plan for spike-driven settlement and the operational shape that implies.

Feeds: Citation Tolls from RSSHub Item Provenance

The audience for written content is no longer human. The growth in consumption of news articles, blog posts, and research papers in 2025 and 2026 has been driven almost entirely by LLM agents and aggregators reading content as substrate for generated answers. The economic settlement for that consumption has been zero. The author writes; the model grounds; the answer ships; no money moves. The mechanism that would close the gap is a small fee per citation, settled to the source: fractional enough that the crawler counts it as cost-of-substrate, structured enough that the source can attribute it.

RSSHub (~41.3k stars) sits at the interesting choke point. It’s not the source of the content; it’s the layer that translates source HTML into structured items that downstream feeds (and increasingly downstream LLM crawlers) consume. The downstream audience (every RSS reader, every newsletter, every LLM grounding crawler) is the actual distribution channel, not the RSSHub instance itself. The structured-item shape is documented in lib/types.ts:

export type DataItem = {
    title: string;
    description?: string;
    pubDate?: number | string | Date;
    link?: string;                      // canonical source URL
    category?: string[];
    author?:
        | string
        | Array<{
              name: string;
              url?: string;
              avatar?: string;
          }>;
    doi?: string;
    guid?: string;
    id?: string;
    content?: { html: string; text: string };
    // ...
};

Two of those fields are settlement-grade primitives in a costume. link is the canonical source URL, the identifier an attribution layer would point at. author is either a string name or a structured record with url. If the author is themselves a creator with an author/url of their own (a substack, a personal blog), that’s enough to resolve a payee.

A sidecar wraps RSSHub’s response (either as a downstream proxy or as an HTTP middleware injected into the lib/middleware/ chain) and adds an x-payment attribution token to each item. The token names the source URL, the publication, and the per-citation fee. When an LLM crawler grounds a generated answer in the item’s URL, the crawler sends an x402 microsettlement to the address in the token. The fee is small enough that the crawler swallows it as cost-of-substrate; the source author receives a continuous trickle from the existence of their work in the LLM grounding pool.

No shared trust is required beyond the chain. The crawler doesn’t have to trust the RSSHub instance, because the attribution token is signed by the source author’s known key (or its delegated authority through ERC-8004 once that primitive lands). The RSSHub instance doesn’t have to trust the crawler, because settlement happens onchain and the proof is verifiable. The author doesn’t have to trust RSSHub, because the wallet address routes to them directly.

The right anchor for first deployment is not RSSHub itself but the LLM crawler boundary, because that’s where the consumption event happens and where authorization for a per-call fee is already part of the architecture (it’s the same place x402 already settles per-API-call fees today). Citations per author per day, microsettlement fire rate against grounding events, dispute rate against cleared settlements: a real deployment is what produces those numbers.

The Metadata Already Encodes the Split

The four verticals above describe single-payee settlements: scrobble pays one artist, Owncast pays one streamer, Immich pays one photographer, RSSHub pays one author. The real shape of creator value is rarely that flat. A song has a performer, composer, producer, arranger, session musician, and mastering engineer. A photo has a photographer, model, stylist, and location owner. A video has a filmmaker, editor, soundtrack composer, and subject. The honest payment is a split.

The split is already encoded. Beets’ library/fields.py carries artist_credit, albumartist_credit, composers, and composers_ids as first-class database columns. composers_ids is MultiValueDSV-encoded MusicBrainz identifiers, and a sidecar-maintained registry maps those IDs to wallet addresses. A six-way royalty split across performer, two composers, producer, engineer, and label is a single SQL read and six transfers. Immich’s Asset row carries EXIF’s Artist field distinct from ownerId, so a license fee can settle to both with a per-field split. Mastodon’s federation activities carry both actor (who posted) and attributedTo (who originally authored, for boosts), so a reshare fee can settle to the original author and the boosting account.

The pattern: every project in the self-hosted creator stack is sitting on a settlement-grade attribution graph that they have been treating as a display-grade attribution graph. The transition from display to settlement is a change in the consumer of the graph, not a change in the graph.

When Permissioned-Only Wins

Some projects ship full-in-tree payment models (not donation pointers but the entire payment stack inside the product). Where one of those already covers the value chain a founder is building for, a sidecar is the wrong call. They bound the claim that permissionless is always the answer. There are three distinct shapes worth distinguishing: payment-native by design, protocol-level payment primitive, and category-level convergence forced by cost structure.

Payment-native by design

  • Ghost is the canonical payment-native publishing CMS. The core/server/services/ tree includes donations/, gifts/, members/, and a complete Stripe integration (stripe-button.tsx, e2e tests for stripe-offer-checkout and stripe-subscription-mutations, a docker/stripe test harness). Payments are natively integrated; the permissioned-only model is the value proposition.
  • Castopod ships a dedicated modules/PremiumPodcasts/ module that gates feed delivery on subscription state. The premium check runs inside the RSS feed-rendering path itself; a sidecar can’t replace it without rewriting the feed pipeline, and an instance operator who wants paid podcasts uses Castopod’s in-tree subscription logic.

Protocol-level payment primitive

  • AntennaPod is the existence proof of a protocol-level permissioned model. Its PodcastIndex.java parses the Podcasting 2.0 <podcast:funding> tag: the publisher names a funding URL inside the RSS feed, and every spec-compliant client surfaces it. The richer <podcast:value> extension (Lightning sats streaming per-listen) isn’t in AntennaPod yet but is already shipping in Fountain, Breez, and Castamatic. A sidecar can’t reproduce that primitive because the wallet routing lives in the feed XML itself, not in any one client’s database. Where the protocol carries the payment, permissioned-only wins by default.

Category-level convergence: the photo libraries

All three of the largest self-hosted photo libraries (Immich at 88.8k stars, PhotoPrism at 39.4k stars, and Ente at 24.1k stars) independently shipped their own in-tree payment infrastructure. This is category-level convergence driven by cost structure, not three coincident product decisions. Hosting photos is expensive enough at scale (storage scales linearly with library size, ML processing for face detection and semantic search is GPU-heavy, mobile sync demands real bandwidth) that none of the major projects can be sustainable on volunteer maintenance, and each had to ship monetization independently.

  • Immich shipped a “license” supporter program in mid-2024, with full in-tree purchasing UI (PurchaseContent.svelte, IndividualPurchaseOptionCard.svelte, ServerPurchaseOptionCard.svelte), a license.dto.ts schema covering license key plus activation key, a license.email.tsx transactional email template, and mobile/lib/utils/licenses.dart for the mobile side. The community engaged substantively on the legal framing of calling it a “license” given the AGPL (#11288, #11325) but not on whether monetization should exist; the program shipped and remains.
  • Ente was built commercial-by-design. The OSS server includes server/ente/billing.go, server/pkg/controller/billing.go, server/pkg/api/billing.go, server/pkg/repo/billing.go, plus subscription-lifecycle email templates (subscription_upgraded.html, subscription_ended.html, subscription_cancelled.html). Ente runs a paid cloud at ente.io on the same code self-hosters can run for free; the payment paths are first-class. Of any project in the entire creator stack, Ente is the OSS payments-infrastructure reference implementation: Flutter mobile, Go backend, end-to-end encrypted by default, and a complete billing module to read directly.
  • PhotoPrism ships a membership/sponsor program with its own frontend/src/page/about/license.vue page and feature gating tied to membership status.

For a founding payments team, the photo category is closer to Ghost than to Navidrome. The right move is not a per-resolve sidecar competing with the existing in-tree programs; it’s one of:

  1. Build complementary. A per-photographer licensing sidecar (paying the photographer named in EXIF for each external shared-link resolve) is orthogonal to the existing project-support programs and coexists with them.
  2. Attach to a smaller library without in-tree payments. LibrePhotos (7.9k stars), Lychee (4.0k stars), and Piwigo (3.7k stars) haven’t shipped their own programs. Smaller audience, cleaner integration story.
  3. Attach at the federation layer. Pixelfed (6.9k stars) sits at the photo + fediverse intersection, and the integration is at activity-stream level rather than instance-level, closer to the Mastodon shape than the Immich one.

The pattern across all three shapes

Permissioned-only is the right call when payment is (a) built into the protocol’s spec (Podcasting 2.0 found this with <podcast:value>), (b) built into the product from day one (Ghost found this with Stripe Members), or (c) forced by category-level economics (photo libraries found this by necessity). For music servers, live video, and feed aggregators, none of these conditions hold: their protocols are payment-free (Subsonic, ActivityPub, RSS-without-the-2.0-namespace), their products are intentionally focused away from payment plumbing, and their cost structures don’t force them to ship monetization. The permissionless integration is the shape that fits those projects as they are.

Who Pays Whom

Each attachment shape implies a different business. Pick deliberately:

  • Sidecar (B2B, operator-side): A music-payments sidecar that any Navidrome operator can install. Customer is the instance admin. Revenue is per-transaction take or a flat hosted-tier fee. Moat is the wallet and attribution registry that ships with the binary.
  • Plugin (B2B via upstream distribution): A PeerTube payments plugin. Same B2B customer, but distributed through the upstream’s plugin marketplace. Revenue from take rate or premium-tier features.
  • Federation peer (network): A Mastodon-side ActivityPub observer that settles per-reshare to original authors. Revenue from take rate on settled value; long-term value capture is the attribution registry the network accumulates.
  • Crawler-side (developer platform): Per-citation tolls inside an LLM agent. Charge the crawler’s developer or operator per attribution. Ente’s billing.go is a usable open-source template for the billing layer.

Different attachment points imply different go-to-markets. The choice is which kind of payments company the founder wants to build.

Where to Start: A Request for Payments Founders

This is a request for the founding payments teams we’d like to see built. Eight ideas, in the order we’d ship them, each one named, scoped, and pointed at an upstream surface that’s already waiting. None of these requires permission from a maintainer. None requires distribution from a cold start. If one of them excites you, take that as extra validation to dive in. You don’t need to work on any of these specifically to build a creator-payments company; pick the one that fits your team’s surface area.

1. The Subsonic-Protocol Scrobble Sidecar

What to build: A small Go or Rust binary that registers itself as an external scrobble target across the Subsonic protocol family (Navidrome, Gonic, Supersonic, Feishin, Polaris, Airsonic, Ampache), maintains an artist-MBID-to-wallet registry as its main moat, and settles per-listen onchain with a per-user spending cap.

Why now: Coded against the wire protocol, not against any one server, a single binary reaches every deployment in the family on day one. It’s the smallest single thing in this post and the broadest installed base. The label-economics argument for user-centric royalties has been waiting fifteen years for the fee floor to drop. The scrobble sidecar is what tests it.

2. The MusicBrainz Payee Registry

What to build: The artist-MBID-to-wallet registry that ships alongside the scrobble sidecar, treating beets’ and Picard’s artist_credit, albumartist_credit, composers, and composers_ids columns as the split format.

Why now: Don’t invent your own credit schema. Two decades of librarian-engineer tagging work has already produced one, and the MusicBrainz IDs resolve unambiguously. The registry is the durable moat under every music-side integration. Everything else is already on disk.

3. The Owncast Per-Second Streaming Webhook Sidecar

What to build: A webhook subscriber that registers against Owncast’s userJoined/userParted events, settles (parted - joined) * per_second_rate to the streamer’s address, and draws the viewer side from a USDC pre-authorization signed at session start.

Why now: The webhook surface is a gift. The 15-second active-viewer prune doubles as a proof-of-flow check. And the settlement core that ships here is the same core that sits behind the PeerTube plugin (RFS #5) and the Jellyfin sidecar (RFS #4). Build it once, distribute it three ways.

4. The Jellyfin Per-Minute VOD Sidecar

What to build: A sidecar that subscribes to the official Jellyfin Webhook plugin’s PlaybackStartNotifier, PlaybackProgressNotifier, and PlaybackStopNotifier events, computes elapsed playback per session, and settles per-minute to the rights-holder address. No Jellyfin-side code is written; the plugin already publishes the session events from PlaystateController.cs (/Sessions/Playing, /Sessions/Playing/Progress, /Sessions/Playing/Stopped) to whichever HTTP endpoint the sidecar registers.

Why now: Jellyfin carries the largest installed base of any video project in the creator stack (47.9k stars) and the most extensive mobile-client ecosystem (every Findroid, Swiftfin, and Streamyfin user posts to those session endpoints during playback). The project’s posture leaves the permissionless surface clean: Open Collective at the org level, no in-tree fundraising plans, confirmed as recently as November 2025 in #15580. The settlement core from RFS #3 extends naturally: same per-second-rate primitive, richer event stream (continuous progress reports, not just session start/stop). The combined live + VOD video payments market lives behind one settlement core and three distribution paths: Owncast (live, webhook sidecar), PeerTube (federated VOD, plugin), Jellyfin (personal-media VOD, sidecar via Webhook plugin).

5. The PeerTube Payments Plugin

What to build: A maintained payments plugin for PeerTube’s plugin loader, multi-rail credible (x402 plus Monero, given the community’s documented demand), shipping via the Stripe-style webhook routes that PR #6300 added.

Why now: The 115-comment monetization mega-thread has run for seven years without producing an in-tree feature. The closest community attempt (samlich/peertube-plugin-web-monetization) has gone stale. The maintainer’s posture is to stay neutral on payment mechanism by not implementing one in core. The slot is empty, the demand is documented, the attachment point is built. Sit in it.

6. The Mastodon Donation-Campaign Provider

What to build: A campaign-source service that plugs into Mastodon’s new /api/v1/donation_campaigns endpoint, with per-instance configurability, onchain transparency for donors, and a usable admin flow for instance operators.

Why now: Mastodon’s #37880 just opened a server-side slot for external campaign data, with explicit intent from the core team to generalize from “Mastodon’s own fundraising” to “any server running its own campaigns.” First credible provider inherits direct in-tree integration with the largest fediverse server. The permissionless lane below the API (per-user payments via attributedTo settlement) is a separate, slower play the same founding team can extend into once the campaign-provider slot is held.

7. The LLM Crawler Citation-Toll Layer

What to build: Per-citation x402 fees inside an LLM agent framework, integrated at the crawler boundary rather than at RSSHub itself. When the crawler grounds a generated answer in a source URL, it sends a microsettlement to the address signed by the source author.

Why now: The crawler already pays per-API-call x402 fees for facilitators. Adding per-citation x402 fees for source attribution is a smaller architectural ask than wrapping every RSSHub deployment. The economically aligned party is the crawler operator, who can claim “we attribute and we settle” as a differentiation against crawlers that don’t. Ship this inside LLM agent frameworks rather than inside the open-source feed tools themselves.

8. The Settlement Core

What to build: A small, protocol-shaped, portable settlement core that sits under all the above. Use Ente’s billing.go as the onchain-side template (subscription lifecycle, billing controllers, API surface, repository layer, transactional emails, end-to-end encrypted by default). Use Liberapay’s payin/stripe.py as the reference for the parts of the problem that don’t go away when the rail changes: multi-currency conversion, chargeback handling, KYC, recurring-pledge UX.

Why now: Permissionless integrations don’t compete with the upstream open-source projects; they extend them. These codebases (Mastodon, Navidrome, Immich, PeerTube, RSSHub) have been under continuous development for 10–15 years and will likely be under development for 10–15 more. The settlement core a founder writes today should be the assumed plumbing under that stack five years from now. Keep it portable across whatever chain layer ships under it next. It outlasts every integration on top of it.

Conclusion: The Opportunity Behind the List

These communities are easy to distribute to. They’ve been openly considering payments for a decade. PeerTube’s monetization thread is in year seven. Mastodon’s donation-campaigns API followed nearly a decade of fundraising issues being asked for and not built. Immich and Ente shipped their own complete payment stacks under category-level cost pressure. The Podcasting 2.0 spec carries Lightning wallet routing inside the feed XML. They have already arrived at the conclusion that payments belong in the stack. The thing blocking them was the fee floor underneath, which forced batching to the platform layer and forced centralization with it. That constraint is gone. Rail-level batched settlement (Gateway-style nanopayments, x402 on top) absorbs the fee math without absorbing the custody and the trust.

A founding payments team that walks in now does not have to do the hard work of distribution. They walk into communities that have been waiting for a credible rail, with public APIs and webhooks and data structures already shaped like settlement primitives, and with PR histories that name exactly which integration shapes the maintainers will accept. The opportunity is to build massive businesses on top of an attention surface, an authorship surface, and a presence surface that other people have already built, while the people who built them get paid for the first time. Eight projects above. The settlement core that comes out the other end of those eight is what sits under the creator economy for the next decade.