@julian I sent a Follow activity and received this Accept activity:
{ "@context": "https://www.w3.org/ns/activitystreams", "actor": "https://community.nodebb.org/uid/2", "object": { "actor": "https://mitra.social/users/silverpill", "type": "Follow" }, "type": "Accept" }It doesn't specify what activity has been accepted (the id field is missing).
cc @julian
@arcanicanis The recommended type is still Proposal, but it is not a hard requirement anymore. Flohmarkt is using Note and I think that makes sense. FEP-0837 shouldn't prohibit this.
That being said, other projects might choose to use attachments. Mitra uses Link attachments that contain references to proposals. For example, my actor object (https://mitra.social/users/silverpill) has this attachment:
{ "href": "https://mitra.social/users/silverpill/proposals/monero:418015bb9ae982a1975da7d79277c270", "name": "MoneroSubscription", "rel": [ "payment", "https://w3id.org/valueflows/Proposal" ], "type": "Link" }The href attribute points to FEP--0837 proposal (or a subscription page, depending on the media type in Accept header).
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.
@mariusor I can't provide the full request, but I could say that it had RSA HTTP signature attached.
The inbox was https://federated.id/actors/8b740680-ccb4-4265-82e7-4ac2ca402750/inbox
And the response was 201 Created with empty body.
Here is my unsigned Follow activity:
{"@context":["https://www.w3.org/ns/activitystreams","https://w3id.org/security/ v1","https://w3id.org/security/data-integrity/v1",{"MitraJcsRsaSignature2022":"mitra:MitraJcsRsaSignature2022","mitra":"http://jsonld.mitra.social#","proofPurpose":"sec:pr oofPurpose","proofValue":"sec:proofValue","sensitive":"as:sensitive","verificationMethod":"sec:verificationMethod"}],"actor":"https://mitra.social/users/silverpill","id":" https://mitra.social/objects/0188b5b0-829e-aadd-be8d-a5f484fceb34","object":"https://federated.id/actors/8b740680-ccb4-4265-82e7-4ac2ca402750","to":["https://federated.id/ actors/8b740680-ccb4-4265-82e7-4ac2ca402750"],"type":"Follow"}@ryo Thanks. I've been able to find myself by actor URI https://mitra.social/users/silverpill
It's doesn't return results when I look up account by webfinger silverpill@mitra.social but I have an idea why this might not work
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.