Plan for ActivityPub integration

[orblivion]

ActivityPub is a protocol (or a not-quite protocol, per some opinions) that facilitates a federated social network. Mastodon uses it, Pixelfed uses it, Peertube uses it. Each service has multiple instances that work with each other. The services also inter-operate: You can follow and comment on Pixelfed images and Peertube videos from Mastodon. It's pretty flexible (perhaps too flexible, per some opinions).

Our goal is to create an ActivityPub service that integrates with LBRY that would replace current LBRY ecosystem functionality for comments, likes, views, and likely other things over time. For data that lives natively on the blockchain (claims, reposts, channel descriptions, etc), the service will create ActivityPub objects that are downstream of that data; the blockchain always remains the source of truth. For other data (comments, views), all objects will be signed by keys that live on the blockchain, but the source of truth of that data be held by the service.

We will call this service Cantina.

Cantina will differ from most ActivityPub services in a few important ways:

1) The media will have a claimId pointing back to the blockchain, and (probably) no URL to get the media over the web. Peertube is the closest equivalent. It actually supports webtorrent. However, it still has a normal web link the media, which allows it to be supported by any ActivityPub service that consumes standard Video objects. So long a we omit the URL from our media, it will hinder interoperability with other services. 2) The User objects will have a claimId pointing to a channel on the blockchain. This will allow for signatures on comments to be verified. However, unlike omitting the URL, the claimId is an additional field, so it will not break interoperability with other ActivityPub services, in either direction. Comments without claimIds (created by other services, or even by Cantina for whatever reason) will simply not be marked as verified on a Cantina client. Other ActivityPub services will simply ignore the claimIds. (For completeness I'll briefly note that using something called Linked Data Signatures, there's actually a chance for a little bit more interoperability with verification, but it may not happen.) 3) Channel definitions on chain will also specify which Cantina server holds its social data. Supposing there exists Cantina servers Alpha and Beta, and a certain channel holds its social data on Alpha. Beta will primarily identify this channel by its claimId (whereas ActivityPub usually seems to tend toward identifying Actors by a URL). Beta can easily find out from the hub where to find that the channel's social data (namely, on Alpha). This may prove generally useful, but the most obvious application is a user moving its social data to a new Cantina. It's never ambiguous where a given user's Cantina data exists in the Fediverse. Mastodon by contrast has a means of transferring accounts by setting a "forwarding address" the old server, but it doesn't have a canonical data source like a blockchain to identify users and where their social data exists.

Our primary job then is to implement an architecture and ActivityPub grammar that fulfills the above. Our secondary job is to maximize interoperability with existing ActivityPub services as much a possible, so that LBRY can be added to the list of these things that all work together. Again, the secondary goal will be a challenge given item 1, but comments my themselves should work.

What comes next will either be a spec or a fanning out into more issues. There's a lot to consider in the details of the above.

[orblivion]

cc @lyoshenka

[orblivion]

I have a lot written, but I wanted to give something like a summary for now. Maybe I can fan out the parts into separate issues. But maybe I'll just need a big doc if it's too intertwined.