Lately I've been working on federated payments, and finally I have something to show:
https://mitra.social/users/silverpill/proposals/monero:418015bb9ae982a1975da7d79277c270
This URL points to a JSON document (called "Proposal"), which describes a content subscription. This is a starting point. Given the information contained in this document other actors could send activities to initiate a payment. Let's take a closer look:
curl -H 'application/ld+json; profile="https://www.w3.org/ns/activitystreams"' https://mitra.social/users/silverpill/proposals/monero:418015bb9ae982a1975da7d79277c270 { "type": "Proposal", "id": "https://mitra.social/users/silverpill/proposals/monero:418015bb9ae982a1975da7d79277c270", "name": "Pay for subscription", "publishes": { "type": "Intent", "id": "https://mitra.social/users/silverpill/proposals/monero:418015bb9ae982a1975da7d79277c270#service", "action": "deliverService", "resourceClassifiedAs": "https://www.wikidata.org/wiki/Q1260632", "resourceQuantity": { "hasUnit": "second", "hasNumericalValue": "1" }, "provider": "https://mitra.social/users/silverpill" }, "reciprocal": { "type": "Intent", "id": "https://mitra.social/users/silverpill/proposals/monero:418015bb9ae982a1975da7d79277c270#payment", "action": "transfer", "resourceConformsTo": "caip:19:monero:418015bb9ae982a1975da7d79277c270/slip44:128", "resourceQuantity": { "hasUnit": "one", "hasNumericalValue": "7716" }, "receiver": "https://mitra.social/users/silverpill" } }It's not an ordinary ActivityPub object. In fact, most properties come from a different standard, ValueFlows:
>A vocabulary for the distributed economic networks of the next economy
Initially I was hesitant to use it because it looks complicated, but then I realized that even a basic interaction would nevertheless require a bunch of new properties, so I could just use something that already exists. ValueFlows is actually very powerful and one can model practically any economic process with it, from a simple donation to a complex business operation.
The document has two parts, the service and the payment. The service here is 1 second of content subscription (because subscription duration has 1-second precision in Mitra). The payment is 7716 piconero (per 1 second). Notice the resourceConformsTo property that contains caip: URI:
caip:19:monero:418015bb9ae982a1975da7d79277c270/slip44:128This is CAIP-19 asset type identifier. CAIP-19 standard can be used to identify any digital asset, be it popular currency or some obscure token. Chain ID (monero:418015bb9ae982a1975da7d79277c270) is taken from Monero namespace specs.
Proposals will be linked to actors using FEP-0ea0 payment links.
I'm still trying to figure out how payment process should look like. Probably something like this:
- Buyer sends Offer(Commitment). "Commitment" is another term from ValueFlows.
- Seller sends Create(Agreement). This is where payment address and final amounts are specified.
- When payment is completed, Seller adds Buyer to subscribers collection and sends Add()
These steps are quite common and federated marketplaces can use the same approach. This would make them interoperable, even if they serve very different audiences.