Implement ActivityPub
ActivityPub implementation
Here's an overview what needs to happen:
-
Implement webfinger for user discovery.
This will allow users on the fediverse to find eg@ottman@minds.com
by handle.
Docurl https://gleasonator.com/.well-known/webfinger?resource=acct%3Aalex%40gleasonator.com
for an example.
This site is a good tool for testing: https://webfinger.net/lookup/?resource=alex%40gleasonator.com -
Implement actor profiles.
Webfinger will point to an ActivityPub actor profile on your site. You need to implement it on your system.
To see mine, trycurl -H 'Accept: application/activity+json' https://gleasonator.com/users/alex
As part of this, you'll have to generate an RSA keypair for every user so accounts can't be spoofed. -
Implement user inboxes.
By this point, Minds profiles can be seen on the Fediverse, but not interacted with. You'll need to add an inbox endpoint like/users/:name/inbox
to handle incoming activities for that user. I recommend handling theFollow
activity first. You will answer the remote server with anAccept
activity to close the loop. -
Implement HTTP signatures.
To prevent spoofing, the fediverse requires that outgoing activities be cryptographically signed with the user's RSA private key. You add theSignature
HTTP header to the request. -
Implement user outboxes.
The opposite of inboxes, an outbox serializes recent user activities for ingestion by remote servers. See mine here: https://gleasonator.com/users/alex/outbox?page=true
By this point you have the basic building blocks of a working ActivityPub system. You will then just need to handle all the different types of activities, both incoming and outgoing.
Code organization
To make things easier, you will likely want:
- Serializer classes to convert your database models into ActivityPub objects, and vice-versa.
- A dedicated part of your codebase to deal with processing activities, aka "the ActivityPub pipeline".
- Asynchronous job processing with exponential backoff for federation. Sometimes remote servers go offline temporarily. You want federation to keep retrying until the message gets delivered.
Moderation
You will also need to make sure you have robust moderation tools for dealing with federated content. Your site moderators should have the ability to:
- block domains entirely (and delete all content from a domain)
- moderate remote users as if they were local users
Tips
Use https://ngrok.com/ to test federation. It will expose your local dev environment on a public URL which is needed to test federation. It also intercepts HTTP requests making it easy to see how remote servers respond.
You might consider running a Pleroma demo server for federation testing. I can help you set one up.
It's quite an undertaking, but well worth it, and I think you'll be surprised how quickly it can develop once the ball gets rolling. I think you can have user profiles shown through the Fediverse within a matter of days.
Mockups
TBD