FEP-8c3f: Web Monetization

ActivityPub Server to Server
#1

The following FEP was proposed by @diogo, and implemented in #software:gnu-social v3 by Phablulo Joel.

FEP-8c3f: Web Monetization

Summary

Web Monetization federation via [ActivityPub].

History

The ability to transfer money has been a long-standing omission from the web platform. As a result, the web suffers from a flood of advertising and corrupt business models. Web Monetization provides an open, native, efficient, and automatic way to compensate creators, pay for API calls, and support crucial web infrastructure.

[Web Monetization] is being proposed as a W3C standard at the Web Platform Incubator Community Group.

We ask all ActivityPub developers to which this is relevant to carefully read the specification text and provide your feedback!

#2

Question about the URL provided as an example at:

https://codeberg.org/fediverse/fep/blame/branch/main/feps/fep-8c3f.md#L42

The URL has a dollar sign and I’m wondering if that has some special meaning. AFAIK, $ isn’t allowed in a domain name so wondering if that serves some function that might be clarified.

#3

Merged the PR and created a tracking issue for this at #3 - [TRACKING] FEP-8c3f: Web Monetization - fep - Codeberg.org.

I’d like to thank @diogo and the GNUSocial team for creating this standard! Money, payment for services and hosting, etc is a fact of life so it’s good to see work that supports other avenues of funding besides ads and tracking.

1 Like
#4

Hi, that string is the same as the example one in WM specification and it consists on a payment pointer.

Payment Pointers start with a $ character to distinguish them from other identifiers and make it obvious that they are related to payments. To convert a Payment Pointer to a URL the $ is replaced with the standard prefix of a secure URL, https:// .

1 Like
#5

-1 to this

While the idea of web monetization and transfer of value is a good one, this would be a terrible way to go about it

If you follow the rabbit hole, this stuff was mainly authored by Ripple, who are a 100% premined token that are trying to direct users to their wallets i.e. gatehub and others. These wallets also hassle users for KYC information, and can ultimately confiscate funds if users are not prepared to give up private information such as your passport number etc.

It’s not a good look for the fediverse to have this adjacent, which is really a sophisticated form of token spam and produce placement

I think we can do payments, quite well however in the fediverse, using things like the lightning network and the accompanying extension:

This lets you put a simple meta tag in your profile and that will allow you to get donations from other users, without having to purchase centrally issued premined tokens, which seek rent on the protocol. The fediverse should not support proprietary rent seeking protocols. Individual instances can tho, of course.

Additionally using linked data it would be possible to send signed transactions to inboxes to keep a kind of tally system between users

I love the idea of payments between fediverse users, but web monetization is not the way. We can build something really good, since we have signatures already. Care must be taken to avoid rent seeking token sales, which have enormous funds to try and insert themselves into grass-roots open source projects

4 Likes
#6

I do not appreciate Coil (former Ripple) either. But I don’t think there’s anything inherently evil about the WebMonetization standard. This interview by W3C answers some questions. I was re-reading the WM spec and the Interledger protocol, and it allows you to use different payment networks. Furthermore, I can’t find anything that makes this standard centralised in nature.
I believe the issue about WebMonetization is the current lack of alternative to Coil, not the specification per si. I don’t see any reason not to support LN, but I’m not sure why we shouldn’t support WM either.

#7

@diogo glad you feel that way, esp. on lightning! I agree with your comments largely, and appreciate the friendly tone!

It’s very murky. Stefan Thomas who was interviewed there was Ripple CTO

https://www.w3.org/blog/2019/09/w3c-tpac-2019-platinum-sponsors-announced/

They were w3c platinum sponsors. Not even Google are platinum sponsors

They also paid berners-lee and bernanke undisclosed amounts to headline their conference

For those that dont know Ripple were the first fully centralized premined, coin. They’ve issued about 30 billion in tokens, and are looking to issue another 30 billion more

They are also being sued by the US gov. for issuing these unregistered securities, for multiple billions. In the court case a very important part is whether these tokens have use in projects. To that end, inserting them, or adjacent to, grass roots open-source project, is beneficial to their case for utility

The wallets are awful. They’ll send you messages such as. “You have 14 days to complete these paperwork or your funds will be frozen”

While this is open to other systems, the reality is that 80% of folks will use the default. So it’s channeling unsuspecting fediverse users who will trust s/w developers to act in their interest to a path to privacy invasive wallets, aiming to capture a further user base, and to a degree good reputation of open source

They also tried hard to get into Solid through back channels, and contacted me to do so. I didnt respond to them, and they then went to others offering grants to incorporate this into Solid, including the community pod with I ran. I was against this, as you might be able to tell

So, I’d treat that spec with extreme caution. However, why dont we take the best parts and make a fediverse version acting in the interests of users, and removing the default wallets. I feel that web monetization is under iron change control by ripple. If we had our own spec it would be IMHO much better. Perhaps the FEP could move towards that, as I fear slippery slope.

4 Likes
#8

@melvincarvalho Thanks for bringing this up, I didn’t know anything about this history. I learned about Web Monetization from a Creative Commons announcement.

My understanding of what you’re sharing is that what happened was:

  • issued billions in tokens
  • get sued: do you even have people using it?
  • creates a OS Spec (Web Monetization) and fund stuff to make people use it
  • there’s only Coil ATM, so people use Coil

If this is right, then I agree that we shouldn’t be a gear of their strategy to win the court case. It’s, nonetheless, important to gather some references that confirm this.

As much as I understand and respect this argument, I strongly believe that one should instead aim at educating users rather than protecting them from choices. Technology is neither evil, good, harmful or beneficial, its use is.

Relevant XKCD :sweat_smile: , but I don’t object as long as we can gather some references to support that this standard is part of an evil scheme and should therefore be discarded.

#9

Is it fair to say that this proposal prioritizes hosted wallets over others that might be accessed locally via URI-scheme (browser extension, local application, etc. )? Though I understand these things bleed together, I feel like we should evaluate these things on a technical basis rather than on the political,

A reminder since this is the first significant activity on FEP for a while. A FEP isn’t a commandment, but a well-documented suggestion which developers are free to implement, build upon, or ignore.

1 Like
#10

I see it as a funnel to sell XRP tokens, via the Gatehub and Upload wallets. Which are also highly invasive to privacy

Once projects start being a source of token sales, it’s fairly hard to decouple, as has been found out on Bluesky

I do understand it’s ‘just a proposal’, but there’s 100s of projects out there that are vehicles for token sales, and few that are not. Fediverse to date has been one something different, and has attracted a lot of grass roots developers on that basis

If web monetization is adjacent to Fediverse, some devs will probably look elsewhere for solutions

2 Likes
#11

Yes, and I notice a big uptick in crypto / blockchain related activity on fedi that seem to be related to the Gold Rush mad dash, and seeing fediverse as possible furtile ground rife for ‘excavation’.

(Btw, also an increasing amount of non-crypto likely shady corporate accounts following me. The other day I remarked that while Fediverse hasn’t been able to grow strong on its own terms yet - by creating a strong substrate of people and processes upholding it - it did manage to grow interesting enough for exploitation. Which is the entire thing that worried me for a long time
 that we have an unaddressed Achilles Heel. But that is OT for this thread)

1 Like
#12

I appreciate and agree with your analysis @melvincarvalho . Could you please kindly take a look at my first non-intrusive approach to micro-payments on Fediverse? I’ve just prototyped a relay from PeerTube and Mastodon to smartlike.org, using Fediverse signatures as you suggest. Thank you!

(At Smartlike we are building a free non-profit decentralized donation processor with a focus on freedom, privacy and efficiency. No cryptocurrency. details)

In short, micro-donations are accumulated per content item and shared between creators and hosting instances (example). To get paid out, users connect their Fediverse to Smartlike accounts by mentioning their Smartlike account in the Fediverse profile description (more details). Instance administrators add the signature as a DNS entry and choose what share they would like to receive.

When users connect their accounts, they can opt to have their Fediverse signatures trusted on Smartlike in order to make one-click micro-donations when they click thumb-up/upvote/reblog/etc in Fediverse. An instance of the relay transparently forwards signed transactions from connected users to Smartlike where they are turned into micro-donations.

What we seek to achieve:

  • More people to join Fediverse. Popular content creators will get an additional incentive to publish in Fediverse, attracting their audience to join.
  • Fediverse sustainability and scalability. Instance administrators will have an option to take a cut to cover their hosting costs without asking for donations via a centralized service.
  • Improve user experience. Anonymous donation accumulators are stored on a public ledger and can be used by content apps to enhance feeds, charts, search and recommendations without robbing users of their freedom and privacy or building walls between platforms. Tags produced by decentralized crowdsourced moderation are also shared to let users choose what filters to set and what moderators to trust.

I believe that establishing this kind of circulatory system could be vital for Fediverse development since the conventional monetization models don’t fit well.

#13

Welcome @vadim-frolov, Do you have any feedback on the Web Monetization proposal? Your post seems not to add anything on this particular topic.

As for the relay code and your mysterious project, it would be better to make a separate post to discuss.

#14

Hi David,
I apologize for interpreting off-topic rules too broadly. I had just registered on the forum to make a separate post and first searched for the topic to get into the local context, discovered the discussion. Sorry.
Re Web Monetization proposal, I agree with @melvincarvalho and would only attach my answer to the question from a discussion with PeerTubers in November 21.
Thank you for the invite to make a separate post on my proposal. I will try to reformulate.

#15

Some people on fediverse just put a cryptocurrency address in their profile to signal that they are accepting donations. Sometimes key-value fields are used, with key being a currency code prepended by “$”, e.g. $BTC or $XMR (notation popular on Twitter). This approach is simple, works for all FOSS currencies and doesn’t require additional standards like Web Monetization, which promote corporate permissioned ledgers and hosted wallets.
Key-value fields are already supported by many ActivityPub server implementations (as PropertyValue attachments to actor object) and some even recognize $ABC fields as cryptocurrency addresses.

1 Like
#16

This is good, in that the user can choose to add their address, and wallets they already own

Allowing users to extend their profile, in general, is a big plus for the fediverse

It’s something that is designed into linked data, but under utilized

1 Like
#17

Thanks for the links

I suggest a new topic, or FEP for smartlike

It seems to be using paypal, to start with, which I guess is OK. It’s better than herding users towards premined tokens, as it seems peertube is now doing

Why not integrate the lightning network. I somehow think we need to start the distributed social web all over, with clean ethical incentives.

2 Likes
#18

Hi @diogo! Do you want to finalize or should it be withdrawn per the date on the tracking issue?

#19

How to implement this FEP? If I add webmonetizationWallet property to actor object, how this should be reflected in UI?

WebMonetization spec relies on browser support but it doesn’t seem like this is going to happen. In the interview they mentioned browser extension which hasn’t been updated since 2018. Are there any alternatives?

Also the specification itself seems to be abandoned. W3C is now working on a different standard, some parts of it already have “Proposed Recommendation” status: Payment Request API. The new standard is focused on credit card payments though, and is being pushed by Google, Facebook and Microsoft (see editors).

#20

I actually like the idea of “monetization” property, but I think it can be made more generic. There’s no reason to commit to a particular standard like WebMonetization.
We can make it an object with type property but treat everything else as implementation detail, for example:

{
    "name": "Alice",
    "monetization": {
        "type": "WebMonetization",
        ...
    },
    ...
}

But also:

{
    "name": "Alice",
    "monetization": {
        "type": "LightningAddress",
        ...
    },
    ...
}

The properties related to a particular monetization type can be defined in separate FEPs.

1 Like