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.