Central inbox server

Software
1

A recurring challenge when connecting websites to the Fediverse is implementing the inbox and providing moderation tools. Therefore, I was wondering whether it would be possible to develop a kind of inbox server. That server would receive activities from the Fediverse and offer a simple API for the website. This API could even be accessed via JavaScript on static webpages. First, I would like to create a way to share and comment on content.

Let’s say I have a website showing particularly beautiful specimens from my stamp collection. The view for humans would be accessible at https://example.org/stamps/000342. It would contain a link to the ActivityPub version via

<link rel="alternate" 
      type="application/activity+json" 
      href="https://example.org/stamps/000342.json" />

Perhaps content negotiation could also be used at this point.

The challenge is to handle incoming activities for this object. A single server component for a websites of an organization could be listed as inbox and receive these incoming activities. It could provide a web interface to review and approve incoming comments. The website could query the server component via API for stats and comments. For example https://apserver.example.org/api/stats?uri=https://example.org/stamps/000342 or https://apserver.example.org/api/comments?uri=https://example.org/stamps/000342 If you do this with JavaScript, you only need to make a few adjustments to the individual web pages.

Does such software already exist? If not, would anyone be interested in working on it with me?

2

I don’t think much software exists in the way you describe, but you are basically describing the lesser-implemented ActivityPub Client-to-Server API, often referred to as “C2S”. The originally-intended theoretical model for an ActivityPub server is in fact exactly this – you have an inbox and an outbox, and you can interface with them to send and receive activities. The client-to-server “C2S” section of the spec governs POSTing to your outbox and GETting from your inbox.

The challenge in implementing such a server is actually not in handling the activities. It is in making sure that the client can authenticate with the server, or that the server can authorize certain requests. There is no specified way to do this – authentication and authorization were left out-of-scope of the specification, because clear best practices had not yet emerged beyond a vague inclination to perhaps use OAuth (although the details of how you would register OAuth clients and negotiate scopes is still up in the air).

If you are implementing this for personal use, then you are free to choose whichever auth-scheme you want – HTTP Basic with a username and password, HTTP Bearer with a token known to the server, and so on.

One other thing I should mention is that ActivityPub Server-to-Server federation (“S2S”) is actually a specialization of a spec called Linked Data Notifications (LDN). The ActivityPub inbox is in fact an LDN inbox (https://www.w3.org/ns/ldp#inbox) that requires every payload to be an Activity serialized in Activity Streams 2.0 format. How this inbox gets discovered is slightly different between the two specs. In ActivityPub, you would do content negotiation and check for an inbox property, perhaps first checking for an attributedTo property – FEP-efda tangentially discusses this algorithm. In LDN, you would directly check for a link relation exposing the inbox on the HTTP resource or within the content of the response (depending on the Content-Type):

HEAD /resource/ HTTP/1.1

HTTP/1.1 200 OK
Link: </inbox/>; rel="https://www.w3.org/ns/ldp#inbox"

<link rel="https://www.w3.org/ns/ldp#inbox" href="/inbox/">

@base <https://domain.example>.
</resource/> <https://www.w3.org/ns/ldp#inbox> </inbox/>.

{
  "@context": {
    "@base": "https://domain.example/",
    "id": "@id",
    "inbox": {
      "@id": "https://www.w3.org/ns/ldp#inbox",
      "@type": "@id"
    }
  },
  "id": "/resource/",
  "inbox": "/inbox/"
}

Once you have an inbox, you can send a notification to it. However, many current softwares are not robust at discovering inboxes like this. They expect only “actors” to have inboxes, and they expect those “actors” to fit an additional set of constraints which vary by project – such as for example having a specific type, having a preferredUsername that can be used with WebFinger to discover information about an acct: resource which links back to the “actor” resource, and so on.

3 Likes