Federated "alternative" to Patreon

“Fedi Pledge”

(needs a better name tbh but anyway. also NOT a replacement for Patreon.)

Patreon is a service where you can… pledge to creators and get access to a
feed of posts in return? Basically you’re paying $5 or $10 or whatever per
month to get access to a social media feed.

Since it’s a social media feed… why not federate?

The “ideal” Federated Patreon alternative

In an ideal world, you could have pledges and creators in different instances
and still have it work. In the simplest case with 2 instances, you would be able
to have:

 +---------+        +---------+
 | Pledger |        | Creator |
 +---------+        +---------+
  $ |   ^        posts |   ^
    v   | posts        v   | $
 +----------+  $  +----------+
 | Instance | --> | Instance |
 +----------+ <-- +----------+

But in the real world, this part where two instances exchange money is tricky…
In fact, for our purposes we can basically consider it straight-up impossible.

So we can’t transfer money between instances. What can we do?

Real World, case 1: Pledger Transfer

What if we could just… transfer the pledger?


 +------------------+    +---------+
 | Pledger          |    | Creator |
 +------------------+    +---------+
  ^              $ |      posts | ^
  | posts          v            v | $
 +----------+     +---------------+
 | Instance |     | Instance      |
 +----------+ <-- +---------------+

Assuming the pledger has accounts on both instances… what stops this from

(In some contexts, this is what’s known as “multihoming”. It’s mostly a
convenience feature, as it allows grouping multiple instances under one feed.)

Real World, case 2: Gifted Pledges

This isn’t something we’ve seen with pledge services before, but Twitch has a
feature called “gift subs”. Is there any reason why we couldn’t have something

We could also have it work across instances while at it:

 +-----+  +---------+    +---------+
 | Fan |  | Pledger |    | Creator |
 +-----+  +---------+    +---------+
  ^              $ |      posts | ^
  | posts          v            v | $
 +----------+     +---------------+
 | Instance |     | Instance      |
 +----------+ <-- +---------------+

This is pretty much just a general case of the previous case. (Or maybe
multihoming is a special case of gifted pledges? We’d rather have real,
first-class support for multihoming than trying to build it on top of gifted
pledges tho.)

So, at least to us, these two cases seem like the hard requirements for an MVP.
They should be considered a starting point tho, not a final product. Also,
while at it, if we use ActivityPub for federation, we can integrate with
Mastodon, so a creator could make public posts that federate back to Mastodon.

Ultimately the goal is to be able to meet local needs, something Patreon, or
any other international service, will never fully be able to. If this were open
source (and it really needs to be open source, probably AGPLv3), then you could
setup an instance for your own country, and focus your service on your
country’s needs. But we can start with building a test network, without
involving real money or anything.


Cool general idea, and seen often talked about on fedi timelines. Though I haven’t read in detail I encourage also posting it to fediverse-ideas repository in a new issue.

Also you may approach Aaron Wolf (@wolftune@social.coop) involved with Snowdrift Crowdmatching… maybe there’s interest for adding federation support. They haven’t launched but are laying a really solid foundation to ensure values and benefits for FOSS and the Commons.

You don’t need to transfer money between instances, only notifications. Payments should be processed by the recipient’s instance, but it can be done without creating an account for the sender, federation takes care of that.

I implemented federated subscriptions two years ago, you can read about implementation in my FEDERATION.md file: mitra/FEDERATION.md at main - silverpill/mitra - Codeberg.org

FEP-0837 improves UX, but it is not strictly necessary for mechanism to work.

1 Like

we don’t understand how this is supposed to work? ah it’s blockchain.

No, it doesn’t need a blockchain. The form of payment doesn’t matter, the content producer may even manually add people to their subscribers collection without any payments (this is analogous to followers collection and followers-only posts)

if it’s not about blockchain, why does every material (guides, docs, etc) about it talk exclusively about blockchain…?

it looks as if it was designed for blockchain, but how would you assess whether it’s suitable for non-blockchain uses?

Donations and pledges to free software projects is one of the goals of the NGI TALER consortium over the next few years. If you want to integrate micro-payments in EUR, you could apply for funding to the TALER Open Calls. See also 10 days to first TALER Open Call deadline.

also, we feel like a big difference between mitra and our goals here is the entire UX. mitra is pretty much a regular social network, not much different from mastodon.

we really want to set the tone of the project as a project for creators. what’s required for this is making a strong distinction between being a fan and being a creator. on twitch the difference is really obvious: creators stream, fans interact in chat. on patreon, everyone posts, but the way they post is different: creators make top-level posts, and fans make replies. (tho you can have some variations on this, you could have e.g. a “community space” where a creator’s fans can post and interact independently of the creator’s own posts.)

(free idea: if mitra wants to distinguish itself from “mastodon clone with optional support for subscriptions and donations”, it could instead focus on being a platform for creators first, maybe even default creator posts to requiring a subscription. if we were you, we would want to make sure it’s possible to interoperate with non-crypto payment systems first tho.)

1 Like

Yes, but I was talking about the federation protocol. FEDERATION.md and FEP-0837 describe how subscriptions and payments are represented in ActivityPub (FEP-0837 doesn’t talk about blockchain at all).

In general, ActivityPub server only needs to know whether payment happened or not. It can get this information from a payment processor (e.g. PayPal), or it can get it from a node connected to p2p network. Mitra uses the latter, and integrations with non-free services are against the ethos of this project, but ActivityPub extensions it uses don’t depend on any specific payment backend.

I had this idea when I started working on subscriptions, but over time it became clear that people are more interested in a “mastodon clone with optional support for subscriptions and donations”, so I abandoned it. However, an alternative frontend can be created that will make stronger distinction between creators and fans.

As for interoperability with other payment systems, Mitra will soon allow creators to manually add subscribers. Such subscription could be a gift, or a result of offsite payment.

Those are fair points, but we would like to address one thing.

What about local (non-paypal/etc) payment systems? And what about GNU Taler?

I’m certain that these ActivityPub extensions are compatible with any payment system.

But if you’re asking about GNU Taler specifically in regard to Mitra, I think the answer is no, because it seems to rely on the banking system which is not open. They can be used together, but I wouldn’t integrate GNU Taler.

GNU Taler does not depend on the banking system per se. If you want to use local or regional currencies, or imaginary currencies, or crypto-currencies, then you don’t need a bank. If you want to support fiat currencies (e.g., EUR, CHF, HUF), then this will require interfacing with the banking system, like for any other payment system.


Good to know. So in local currency case it can be entirely self-hosted?

The documentation says:

Taler can also be used as a regional currency; for such scenarios, the Taler system also includes its own stand-alone bank.

Is this bank system open source?

Yes, the fakebank code is here: bank-lib « src - exchange.git - Exchange implementation.


GNU Taler doesn’t support recurring payments which something like Patreon would need. It seems more focused on a digital currency alternative to something like Paypal, which surely has its own uses for something akin to ebay or facebook marketplace.

boleto bancário doesn’t really support recurring payments either but it’s okay because you can send a reminder/bill

There’s ongoing work on recurring payments with GNU Taler, with the contracts API v1.