Past weekend I’ve been working on adding support for following other users in littr.me and fedbox.
As you might know already, the underlying mechanism for this is based on #ActivityPub client to server protocol and this means that I need t add support for Follow and Accept/Reject activites processing in the go-ap packages. (Supporting them was the main reason for doing this, as it consists of one of the main mechanisms federation is based on, and it’s required to play nice with external services, which are not littr.me or fedbox.)
This is not as easy as it sounds as it requires a new concept to be introduced to the processing package: operating side effects of an activity based on multiple step interactions.
Explicitly, in the case of a Follow this has the following steps:
-
User A clicks a follow link on their client, which sends a
Followactivity with User B as anObjectto their own service outbox. -
The ActivityPub service managing the outbox processes it locally and then sends it to User B’s inbox. Processing it locally, means just that it adds it to the proper collections on the service, User A’s outbox, for once and, in our case also to the global
/activitiescollection. -
The service managing User B’s inbox processes it locally (see above).
-
User B’s client presents a confirmation dialog to them in order to accept or reject the follow. This translates to an
Accept/Rejectactivity that is being sent by the client to User B’s outbox. -
This activity follows the reverse path through the system from B’s outbox to A’s inbox.
-
When A’s service receives this activity in then finishes the follow process by, either adding User B to User A’s following collection if they sent an
Accept, or not doing anything for aReject.
Obs: for the steps above, client is implied to be the littr.me frontend and service is an instance of fedbox for both users. In the generalized case, where users might not be on the same instance, the transport between one’s outbox and the other’s inbox is done using the server to server ActivityPub protocol, which we don’t have implemented yet.
So far I have added the support for displaying the follow link and sending the corresponding activity to the logged in user’s outbox, and then to the followed user’s inbox. Unfortunately I stopped before adding a way to accept or reject the request.
The reason for stopping is that I realized that we need a better way of presening a user’s inbox to them. Currently the /followed tab represents that, but we’re only displaying received messages and nothing else. I need to step away from the (old)reddit paradigm and add at least the follow requests as an item type that can be listed and acted on.
After all this wall of text in explaining what features I haven’t added to the site, I have a small thing which I managed to complete, which is that now the global item listing doesn’t include private messages any more.
PS. Following users, will follow soon enough though. I want to get this done as it represents a necessary intermediate step before starting adding S2S support.