FEP-8c3f: Web Monetization

this seems better-fit for an extension property than trying to re-use attachment

2 Likes

Hi. New to this forum. Relatively new to web dev (two years). If I sound like a total noob, forgive me.

So far there’s been interesting chat about how web monetization would be represented in the vocabulary, but I’m also interested in how monetized content would be handled on the clients and instance sites.

You can’t just rely on browser extensions because one, not all Fedi clients will be web-based, and two, there still needs to be a mechanism for clients to know the state of payments so that it knows what to display and when.

From what I understand, monetized content can take a few forms (and for these I’m assuming either a subscription or micropayments model):

  • Content that’s fully viewable by default but clients can opt in to donate to the host.
  • Content that’s behind a paywall and only discoverable if the host knows the user is consistently donating.
  • Content with some parts that are viewable but other parts or versions that require a minimum donation or subscription.

This is simpler for individual websites but since the deal is content that can be displayed on any compatible websites I wonder what clients would be expected to provide and be responsible for.

1 Like

I implemented subscription-only content as private messages with multiple recipients. This has several drawbacks but it’s backwards compatible with existing AP software. Private groups would probably work better in this use case, but none of the popular platforms support them. Content can be also public but encrypted, in that case the author only needs to distribute decryption keys.

Donations are easy: in most cases an URI in profile would suffice.

2 Likes

PixelFed announced their plans to implement “Buy links”: pixelfed: "We're working on a few #photography improvements …" - Mastodon.
I suppose authors will be able to add these links to individual photos, not just to their profiles. The generalized FEP should cover this use case as well.

cc @dansup

1 Like

If Uphold is your wallet provider, then your payment pointer and all other associated Interledger features will be disabled on March 15, 2023. If you have questions, please reach out to Uphold directly.

Open Letter

Web monetization was a concept that promised to improve the way creators are compensated for their work online. However, as more and more people got funneled into wallets like Uphold, it became clear that this system was not a good fit for the open-source ecosystem.

In fact, the recent news that Uphold is disabling payment pointers and all other Interledger features should serve as a stark reminder of the inherent flaws in this model. By entrusting their funds to a centralized third-party service, users run the risk of losing their funds altogether if that service goes under or decides to discontinue support for the system.

Furthermore, web monetization is fundamentally at odds with the values of the open-source community, which prioritizes transparency, decentralization, and user empowerment. By funneling users into wallets and other commercial operations, web monetization undermines the principles of openness and accessibility that make the internet so valuable to so many people.

Moreover, the web monetization economy was built on the backs of those who printed tokens, not those who provided the actual content or services. This created a system where the few who printed tokens benefited the most, while the vast majority of creators and users saw little return. This is a fundamentally flawed economic model that goes against the principles of decentralization and open source.

In conclusion, web monetization may have seemed like a good idea on paper, but the reality has been quite different. A better way is for the open-source community to reclaim control over its own financial systems with a more more equitable and sustainable FEP for online compensation

3 Likes

I would consider GNU Taler a good option for Web nonetization, especially when it’s actually linked to the banking system. It does not lose your money, it’s secure, it’s anonymous for the buyer, and transparent to auditing for the seller—fraudsters beware.

1 Like

Could again post another link to my way-too-long ( :sweat: ) backlog of stuff to add to delightful-funding in case there’s something there.

1 Like

Nostr has gone with zaps, for the simple reason that there is no proprietary printed tokens adjacent

https://zaplife.lol/

It has proven not only, highly popular, but useful for advanced features such as sending a micro payment to a relay to reduce spam. Developers get funded from the community. Funny memes get rewarded, as does good content. The good vibes have started to flow since it was implemented. Or as Edward Snowden put it, “This is the happy place”.

Zaps are powered by the lightning network, and there is already a peertube plugin. The amazing FLOSS extension alby makes it easy. Some here will know its creator, bumi.

While not a perfect system, it is one that is working very well. The value 4 value economy is a small oasis of the web that I’m happy to experience.

It is a stark contrast to token economies where there founders get very rich, on the backs of value creators.

The downside of all this is that generally an extension is required to keep your key safe, on the web. Mobile is a bit different. Hopefully there will be more security options in future.

3 Likes

While their commitment to interoperability is laudable, I still think monetization FEP should not promote any particular system.

There are references to payto: URI scheme throughout GNU Taler docs, which looks interesting. This way of designating payment targets fits nicely into my previous suggestion to use Link attachments. A sub-type of Link, like PaymentLink, would be even better choice:

{
  "type": "PaymentLink",
  "name": "Support me",
  "href": "https://ko-fi.com/username"
}

A payment link can be attached to both actors and objects, and this approach is compatible with any kind of payment method. The only limitation is that such link is static. If interactivity is required, actors will need to send activities back and forth. I guess this area can be covered by FEP-d767.

@trwnh Do you still think that extension property would be more appropriate?

Why do you think PaymentLink would be a better choice?

From the payto: RFC8905 you linked above, a payto: link might be:

payto://iban/DE75512108001245126199?amount=EUR:200.0&message=hello

It looks like your option would be able to support a number of options for payments whereas the payto: link would only support direct payment to a single target (and eventually for a specific amount). But this is a different feature and not incompatible.

Are you suggesting that the following may be valid as well?

{
  "type": "PaymentLink",
  "name": "Support me",
  "href": "payto://iban/DE75512108001245126199"
}

filter(attachment[], "payment" in rel[]) or [node for node in attachment if "payment" in rel] or somesuch should work. the actual json-ld type is irrelevant. this should work for any object, not just actors

https://microformats.org/wiki/rel-payment

https://www.iana.org/assignments/link-relations/link-relations.xhtml

1 Like

FEP-e232 uses Link attachments to represent links between objects. Various kinds of link attachments can be differentiated by mediaType or rel attributes, but I think type is more straightforward.

Yes, I’d like to specify in the FEP that href is URI, not URL.

1 Like

link rel is what gives the “purpose” of the link. it describes how the href is related to the current document or subject. also, as2 recommends that any extension types also specify a core type, and to not create extensions that unduly overlap with existing types. in this case, "type": ["Link", "PaymentLink"] is strictly worse at conveying the information than "type": ["Link"], "rel": ["payment"]. you may as well re-use what’s already there. if anything, what you might want to use extra type for is specifying the type of the “payment link”. imagine Paypal, Stripe, Cashapp, etc. in order to save having to parse the href prefix on every single payment link. but i’m not sure how useful this is.

2 Likes

Thanks for a feedback. I will use Link type and payment rel in my forthcoming proposal

2 Likes

The proposal has been published as FEP-0ea0.

Discussion topic: FEP-0ea0: Payment Links

@diogo I made it as a standalone proposal, but if you feel like it should be presented as continuation of your work here, we can set appropriate tags indicating that (replaces and replacedBy).

1 Like

Shouldn’t #fep-8c3f be WITHDRAWN instead?

As I mentioned yesterday on the fediverse, Write.as implemented Web Monetization in 2020:

“… Web Monetization allows you to buy a single subscription through a provider such as Coil, and get access to all paid content across the web that supports Web Monetization. This includes blogs on Write.as, an ad-free experience on Imgur, independent sites from around the web, and plenty more. With that subscription, all you need is a special browser or extension to access paid content.”

Is @thebaer aware of this FEP discussion?

1 Like

Hi, thanks @silverpill, but I believe your proposal supersets this one (i.e., it’s not a continuation but rather something different and better).

I believe this fep-8c3f should be WITHDRAWN.

In GNU social I’ll be adopting fep-0ea0 instead.

1 Like

Awesome! I’ll add a History section to FEP-0ea0 with a link to your proposal.

1 Like

FEP-8c3f has been withdrawn.