Inbox and outbox GETs

ActivityPub Server to Server
1

As I’ve mentioned before, I’m working on an ActivityPub-compatible “letterboxd clone”, where users can track what movies they’ve watched, add them to collections, and publish reviews. For social features, it supports followers/following, likes and comments on watches/collections/reviews. The server is designed to federate with other instances of itself (for the usual “feed view”), but also will support basic publishing of Note objects for interaction with other projects. Additionally, likes/comments can come from interaction with other projects. E.g. a user could be followed by a mastodon user, and that mastodon user can reply to their reviews.

I’m a little perplexed by the expected behavior of the inbox/outbox collections in a pure server-to-server application. My application will not support C2S and will provide a canonical web based client.

The spec states that inbox.outbox MUST be OrderedCollections, which would imply they must be accessible by an HTTP GET request. The spec then moves to non-normative language about what the collections contain.

The outbox stream contains activities the user has published, subject to the ability of the requestor to retrieve the activity (that is, the contents of the outbox are filtered by the permissions of the person reading it). If a user submits a request without Authorization the server should respond with all of the Public posts. This could potentially be all relevant objects published by the user, though the number of available items is left to the discretion of those implementing and deploying the server.

and

The inbox stream contains all activities received by the actor. The server SHOULD filter content according to the requester’s permission. In general, the owner of an inbox is likely to be able to access all of their inbox contents. Depending on access control, some other content may be public, whereas other content may require authentication for non-owner users, if they can access the inbox at all.

For the inbox, “if they can access the inbox at all” seems like its alright to make the inbox collection empty, at least when not authorized as that actor.

For the outbox though, the options seems less obvious.

This could potentially be all relevant objects published by the user, though the number of available items is left to the discretion of those implementing and deploying the server.

Is there anything in the spec that allows server-to-server interaction to read the outbox from another actor? Are there implementations that do this?

1 Like
2

For S2S, I don’t know of a use case for reading an inbox. You could return an empty collection, or even easier, return an error status code (401, 403, …). Mastodon returns a 404 status code, which doesn’t seem like the best choice but it also doesn’t violate the Rec.

Mastodon supports reading the “outbox” (it synthesizes outbox collection pages on-demand). Some servers might use this to initially backfill actor information. However, a server is not required to return anything from an outbox dereference or to authorize access to it.

1 Like
3

authentication/authorization is left out of the spec, but in practice, existing fedi software will serve public activities via the outbox, and some software will expect to fetch public activities via the outbox as a form of backfilling history. i’m not sure if any implementation does this, but you could theoretically use HTTP Signatures on an outbox GET in the same way that it is used on inbox POST or object GET, and then have application logic that filters the response based on what the authenticated actor is authorized to see. you could also use any other authn/authz scheme, but the catch is that it has to be supported by both ends. (say for example there was a subset of fedi projects out there that used Authorization headers instead of Signature headers, and used out-of-band bearer tokens or capability URIs or whatever.)

1 Like