Hello, when a server has a new actor to follow is the normal routine to initially check the actors outbox that you follow and sync all there contents with your database? Or do you just grab the actors outbox who your are following everytime you want to see their content?
It seems that saving a local copy to a database for the inital sync is the way to do it and then whenever the the actor you are following makes a new post, hope that their server notifies their followers.
Am I correct in thinking this is the routine? I just was not sure and this seems like an important part of federation is syncing with other peoples outboxes
Thank you for any replies
Hi! this is a good question, and one that might be a little tricky to a beginner. There are two main places where you might want to see another actor’s activities, and it’s important to keep them distinct:
when displaying the timeline of a user that follows the actor
when displaying the “public profile” of an actor
For #1, there’s no need to consider the
outbox of an actor at all. All you need to care about is the activities that make it into your local user’s
inbox, which may even include private activities that aren’t part of the actor’s public
outbox is totally superfluous to this use-case.
For #2, you may think that displaying the
outbox of the actor is the way to go here. And this is indeed the use-case
outbox is designed for. However, there’s rarely a need to cache the outbox content to display it. You can do so, if you wish, but it would be very wasteful to cache potentially tens of thousands of activities that no one is ever going to look at for every remote actor followed by someone on your server. Instead, there are a few approaches you can take to avoid caching:
- you can fetch the content on demand as users request/scroll through the actor’s profile (this would be the approach that is most natural to ActivityPub client applications)
- you can simply link to the actor’s
url property, and assume that there’s a HTML version of the profile that suitable for display (a good assumption for every currently deployed ActivityPub server that i’m aware of)
- you can just display the activities that the server already knows about through normal
inbox activity, and ignore any backfilling or fetching concerns.
Mastodon uses a combination of the second and third approach I mention: when you first click on an actor in the web interface it displays a “local view” of the remote actor—all of the activities it knows about locally because they were delivered to the
inbox of some user on that server. It also provides a prominent link to the “full profile” that takes you to the remote actor’s
url, which generally has a more complete view of the actor. This approach can seem a little weird to first time users, and it’s not my favorite approach, but it does have the benefit of being very simple to implement and working well for the vast majority of use cases.
Thank you for all the details that helps clarify.
Ill have to ponder possible solutions for my use case from this info.