Join the discussion on the Fediverse with #FediLibrary.
Published on 20 June 2020
Submitted on 8 August 2020
Here I will do a dump of my assumptions regarding how the "client to server1" (or C2S) interactions should work on FedBOX.
The first one is that the C2S API will be structured as a REST(ful) API in respect to addressing objects.
This means that every object on the server will have an unique URL that can be addressed at.
This type of URL is called an "Internationalized Resource Identifier2" (or IRI) in the ActivityPub spec.
It also represents the Object's ID in respect to the AP spec.
Fedbox has as a unique entry point for any non-authorized request. For convenience we'll assume that is the root path for the domain (eg:
We'll call this entry point the "Local Service's IRI", as it response consists of a Service Actor representing the current instance.
The Service, as an Actor, must have an Inbox collection, which we expose in the
It also represents the shared inbox for all actors created on the service.
Since in the ActivityPub spec there is no schema for IRI generation for Objects, Activities and Actors and it's left as an implementation detail, we decided that for FedBOX we wanted to create three non-specified collection end-points, corresponding to each of these and serving as a base for every every entity's ID.
These additional non-spec conforming collections are:
An object collection, represents any collection that contains only ActivityPub Objects. The object collections in the ActivitypPub spec are:
liked. Additionally FedBOX has the previously mentioned
/objects root end-points.
On these collections we can use the following filters:
An activity collection, represents any collection that contains only ActivityPub Activities. The activity collections in the ActivitypPub spec are:
replies. Additionally FedBOX supports the
/activities root end-point.
In order to get the full representation of the items, after loading one of these collections, their Object properties need to be dereferenced and loaded again.
Besides the filters applicable to Object collections we have also:
Filtering collections is done using query parameters corresponding to the snakeCased value of the property's name it matches against.
For end-points that return collection of activities, filtering can be done on the activity's actor/object/target properties by composing the filter name with a matching prefix for the child property:
All filters can be used multiple times in the URL.
The matching logic is:
The filtering values support basic operators to be used. They are:
For string based properties:
valueas a substring
key=!value- match everything that's doesn't contain
valueas a substring
For date based properties
key=>value- match everything that has
keyproperty after the
key=<value- match everything that has
keyproperty before the