Hey fediverse, Mata is Threatening our way of life. Let’s show them how the #FreeSoftware community works… Bring effective #micropayments to the #ActivityPub protocols! #GoTALER!
How would you express a donation using ValueFlows?
1 Like
With Valueflows / FEP-0837 the sequence would be:
Recipient publishes a Proposal. This object expresses the ability to receive donations.
Donor sends an Offer(Agreement) activity.
Recipient sends an Accept(Agreement) activity containing the payment details (e.g. a unique invoice ID for this donor).
Donor makes a payment.
Recipient sees the payment and links it to the donor (e.g. via unique invoice ID).
Recipient sends a confirmation to the donor (optional).
Here is an example of a Proposal object indicating that actor accepts donations in Euro:
{
“type”: “Proposal”,
“id”: “https://social.example/proposals/ddde9d6f-6f3b-4770-a966-3a18ef006930”,
“purpose”: “request”,
“attributedTo”: “https://social.example/users/alice”,
“publishes”: {
“type”: “Intent”,
“id”: “https://social.example/proposals/ddde9d6f-6f3b-4770-a966-3a18ef006930#primary”,
“action”: “transfer”,
“resourceConformsTo”: “Euro - Wikidata”,
“resourceQuantity”: {
“hasUnit”: “one”,
“hasNumericalValue”: “0.01”
}
},
“unitBased”: true,
“to”: “ActivityStreams 2.0 Terms”
}
Alternatively, one can add a donation link to the profile. It can be a FEP-0ea0 link or even a PropertyValue object. But in this case donations can not be associated with a specific ActivityPub actor.
1 Like
I’m not 100% sure if my example is a correct representation of “pay as much as you want”.
@lynnfoster Could you take a look?
1 Like
silverpill:
I’m not 100% sure if my example is a correct representation of “pay as much as you want”.
What do you think about just leaving off the resourceQuantity and unitBased (keep it simple)? Assuming the requester wants to accept donations in any amount. Then it would also fit with micropayments of less than .01 euro. But I’m also thinking somewhere it should be more explicit that it is a donation, will give that some thought.
I’m also missing saying what the donation is for, it is probably for the actor’s work or open contribution of some sort? Could just be a note or description maybe. The donation thing could fit in with that too, “Accepting donations for my work as FEP admin”. Or it could be a reciprocal Intent, but that might be overkill, depending on the situation.
With Valueflows / FEP-0837 the sequence would be:
That feels like a lot of back and forth for a donation, but I think I see why you did it.
Bring effective #micropayments to the #activitypub::category protocols!
That would be amazing! I’m missing some context between that and the donation question though. I need to study TALER and the Web Monitization FEP. Also think about how FEP Payment Links might be more tightly integrated with Marketplace, although that seems easier than integrating Fediverse with actual payment mechanisms. But I’m probably behind, will do some homework.
4 Likes
Thank you @lynnfoster, this is exactly the kind of discussion I wanted to trigger. One thing is to have a FEP or two, another thing is to actually make it work for all at protocol level, and this is why we need such a discussion to happen.
#GoTALER!
3 Likes
lynnfoster:
What do you think about just leaving off the resourceQuantity and unitBased (keep it simple)? Assuming the requester wants to accept donations in any amount. Then it would also fit with micropayments of less than .01 euro.
I think it makes sense. FEP-0837 says that resourceQuantity and unitBased are REQUIRED, I’ll make them RECOMMENDED (or maybe even OPTIONAL).
lynnfoster:
I’m also missing saying what the donation is for, it is probably for the actor’s work or open contribution of some sort?
It could be anything. Often the purpose is implied, for example people who work on FOSS sometimes add donation links to their social media profiles.
FEP-0837 specifies name and content properties on Proposal, but they are not required.
lynnfoster:
That feels like a lot of back and forth for a donation, but I think I see why you did it.
This is only necessary if donations need to be tracked. Offer → Accept flow is used to generate unique payment ID.
2 Likes
With regards to more general considerations, beyond the technical aspects, I think we should have thorough discussion on socio-cultural impacts of introducing (micro)payment to the fedi, find pros and cons and anticipate externalities.
For instance @how mentioned in another thread taking example from WeChat Pay. While as a payment system it may work perfectly, WeChat has also been named in the past in experiments where financial credit scoring and social credit systems are combined. According to this MIT report much of the dystopic stories spread in the West about “China’s Social Credit System” aren’t based on actual fact, but the article also does not make me feel very comfortable for the future. In China it is local governments and commercial entities doing experiments (for the latter think e.g. TikTok Lite).
To me at this stage it seems unavoidable we see a corporate takeover of the Fediverse. On one hand introducing micropayment at protocol level will empower these corporations to roll out their commercial services faster. OTOH not introducing micropayments will likely mean that some commercial enterprise will take the reign in defining how this shall work. And then we have an opportunity lost for the commons to stay in control there, at least for a while.
1 Like
aschrijver:
OTOH not introducing micropayments will likely mean that some commercial enterprise will take the reign in defining how this shall work. And then we have an opportunity lost for the commons to stay in control there, at least for a while.
Yes, exactly. ActivityPub/Fediverse is on its way to become as ubiquitous as Email. People will build all kinds of things there, and no one can stop them from introducing payments. Without standards we may end up in a situation where ad-hoc solutions favor big players.
I think Valueflows is a good foundation because it is neutral. It gives developers only a set of abstract concepts not tied to any particular software or economic system.
3 Likes
The good aspect of Taler in comparison to WeChat Pay, is that is guarantees anonymity of the buyer among the anonymity set of all buyers at a given store. Contrary to the credit scoring paradigm, Taler will not let you down: your employer nor your insurance company won’t be able to tell what you buy, so they won’t be able to target you for tailored advertising, nor to change your contract based on the probabilities you have cancer.
The merchant though may be scored, but isn’t this something valuable for society to have corporations held socially responsible for paying their taxes on their actual revenue? This won’t like it, so it’s our responsibility to… make them pay.
1 Like
The Monetization on ActivityPub topic is now federated! Follow @federated@ich.taler.net on the Fediverse.
1 Like
lynnfoster:
What do you think about just leaving off the
resourceQuantityandunitBased(keep it simple)? Assuming the requester wants to accept donations in any amount. Then it would also fit with micropayments of less than .01 euro.
Making changes in https://codeberg.org/fediverse/fep/pulls/318:
unitBasedwill be optionalhasNumericalValuewill be optional, but nothasUnit(because participants need to use the same unit throughout the process)
1 Like
Does it make a difference that in VF, a currency is recorded as a ResourceSpecification, not a Unit. It is somewhat counterintuitive, but we think it is the correct model, like thinking about random alt currencies, that you would never find in a standard taxonomy of Units. Or thinking about constantly changing exchange rates, most Units don't behave that way. (Interested in disagreements.) Or does that change apply to more than currency flows?
It also occurs to me that perhaps Donations is a separate use case / FEP from Marketplace? I don't have a good sense yet of the scope or size of FEP that makes sense for a broad vocab like VF. It would be possible to make the Marketplace FEP into something like a broader Offers/Requests FEP, but then it could be worth taking the time to think through some other use cases. Like donations triggered changes from our original mental assumptions.
What do you think?
lynnfoster:
Does it make a difference that in VF, a currency is recorded as a ResourceSpecification, not a Unit. It is somewhat counterintuitive, but we think it is the correct model, like thinking about random alt currencies, that you would never find in a standard taxonomy of Units. Or thinking about constantly changing exchange rates, most Units don’t behave that way. (Interested in disagreements.) Or does that change apply to more than currency flows?
FEP-0837 implementers are expected to use unit one for money. I think the unit should always be specified, because it can’t be reliably inferred from other properties.
It also occurs to me that perhaps Donations is a separate use case / FEP from Marketplace? I don’t have a good sense yet of the scope or size of FEP that makes sense for a broad vocab like VF. It would be possible to make the Marketplace FEP into something like a broader Offers/Requests FEP, but then it could be worth taking the time to think through some other use cases. Like donations triggered changes from our original mental assumptions.
What do you think?
Donations are definitely within the scope of this FEP. If I am to write a separate Donation FEP it would be almost identical to FEP-0837, because FEP-0837 describes a generic interaction pattern that can be used in many different applications. Yes, the title can be changed, but I like Federated Marketplace more than Offers/Requests.
1 Like
Understood and all good!
1 Like