Actors' inbox and outbox

[srosset81]

What MUST be implemented ?

• Attach a as:outbox endpoint to the WebID (ref.)
  • POST allow the actor (WebID owner) to post activities, which are then forwarded to recipients' inboxes with a HTTP signature authentication
  • GET return an OrderedCollection with a dereferenced list of activities that the authenticated user has the right to see
• Attach a as:inbox endpoint to the WebID (ref.)
  • POST allow other servers to send activities to the actor, with a HTTP signature authentication.
  • GET return an OrderedCollection with a dereferenced list of activities that the authenticated user has the right to see
• Handle side effects
  • Persist activities sent through the outbox somewhere where they can be fetched (reachable URI)
  • Give acl:Read permission to the recipients (if the as:Public addressing is used, give anonymous read permission)

What SHOULD be implemented ?

• Handle side effects
  • Persist objects that are created with a as:Create activity (ref.)
  • Update objects that are updated with a as:Update activity (ref.)
  • Replace objects that are deleted with a as:Delete with a as:Tombstone (ref.)

Other things to consider

In the scenario of an ActivityPub agent, the inbox and outbox endpoints would necessarily need to be on the server of this agent, because the POST endpoint is very specific and the GET must return an AS OrderedCollection, which is IMO impossible to handle as a regular Solid resource (more about this in this issue).

This may not be a problem. But the inbox and outbox are important aspects of ActivityPub so they must be accessible by any user and also applications registered through SAI. It must be possible to fetch or listen to them, if we have the authorizations. So I wonder how well two Solid agents (SAI Authorization Agent + the ActivityPub agent) could work together, especially on endpoints which are outside of the user's Pod ? This would require more discussions and thinking.

Another thing to consider is that it would mean the content of the inbox and outbox (ie. the URIs of related activities) would be stored outside of the Pod, in the ActivityPub agent server. I'm not sure if that's such a good practice. If another ActivityPub agent is created, and the Pod owner wants to switch to this agent, they will lose their inbox and outbox content.

[jg10-mastodon-social]

A Solid container can already receive POSTs but what is received at the endpoint cannot practically be left unprocessed - 1) if the container is publicly appendable, then undesired/illegal content may be received, 2) Mastodon currently spams user deletes to all known servers, so delete activities will pile up in the Solid container: mastodon/mastodon#22070

[jg10-mastodon-social]

In the scenario of an ActivityPub agent, the inbox and outbox endpoints would necessarily need to be on the server of this agent, because the POST endpoint is very specific and the GET must return an AS OrderedCollection, which is IMO impossible to handle as a regular Solid resource (more about this in this issue).

Fortunately I think it turns out this is not correct. Focusing on the inbox endpoint because it's central to the S2S spec, what is required is that activities are accepted by POST, which is already possible as noted above.
Processing can be performed asynchronously by an agent (see #15 ) - I don't think the ActivityPub spec requires anything to be synchronous on the endpoint?
I've described what I consider a possible solution to handling ActivityPub accept headers in #3.

And fortunately, that means that content of the inbox can be stored inside the Pod.

The authorization set up corresponding to the architecture I describe in #15 and #3 involves:

• Public append privileges on the inbox LDP container
• Inbox processing agent has:
  • read privileges to the inbox LDP container
  • write privileges to the inbox LDP container (.meta in particular)
  • write privileges to the inbox pages, which should really be stored outside the untrusted public append inbox LDP container
• Inbox processing agent validates the authorisation provided when receiving webhook notifications of changes to the inbox LDP container, i.e. only known webids can use the agent
• Inbox processing agent validates activity signatures [Edit: this only works for linked data signatures, not HTTP signatures that are provided in headers]

I'm still experimenting with serving the outbox so will need to return to that.

[jg10-mastodon-social]

An advantage of server support for content negotiation of the custom JSON-LD profile (#5) is that it would allow RDF support for ordered collections.

Unfortunately so called as:OrderedCollections don't actually use JSON-LD features to maintain order, they just order items within the JSON document. ¹ as:OrderedCollection not only expects items to have a published date, the item order in the JSON should also be ordered by date.

Serving the custom JSON-LD profile would allow items to be sorted on GET, and in the process would allow PATCHes to collection pages without affecting the order of JSON output.

It seems like this should be possible in CSS with a new custom convertor.

Footnotes

1. https://www.w3.org/wiki/Activity_Streams/Primer/Collections ↩

[jg10-mastodon-social]

https://www.w3.org/TR/social-web-protocols/#inbox-interop from the Social Web Working Group includes the requirements:

LDN receivers wishing to be readable by ActivityPub consuming clients:

• must treat the content-type application/activity+json as equivalent to application/ld+json; profile="http://www.w3.org/ns/activitystreams".
• serve Inbox contents as an AS2 Collection, where each notification is related to the inbox with the AS2 items property.
• must return compacted JSON-LD, and no @graph, serving the Inbox collection as the root of the document.
• may make life easier by nesting additional properties of each resource in the Inbox.

Requirements for other combinations of servers/clients are also provided.

[jg10-mastodon-social]

Note that for the outbox collection, Mastodon only shows the number of posts (totalItems) and does not show posts from before an actor was followed.