ActivityPub Client-to-Server FAQ

ActivityPub Client to Server
1

Context: ActivityPub Client-to-Server (AP C2S) is probably the least understood part of ActivityPub and there is very few documentation and running code for it and ActivityPub is mostly underspecified.

This FAQ might be terribly opinionated, I considered pushing it on my own site or https://litepub.social instead but I figured having it more visible and getting easier interactions would be better.

  • Created: 2020-07-21
  • Last Modified: 2021-07-21

Should I use ActivityPub Client-to-Server?

ActivityPub Client-to-Server is a quite sharp double-edged sword, currently you’ll probably want to use another API like the MastodonAPI.

  • Major Pro: You can get one less layer of adaptation and directly get ActivityStreams formatted data
  • Major Pro: You can post in more formats/types with AP C2S than with APIs like the MastodonAPI
  • Possible Future Pro: AP C2S should allow to gain greater interoperability into clients, not write-once but design-once, continue adjusting (forever)
  • Current major Con: AP C2S has yet to be implemented in any server completely enough to be used for things more advanced than bots or minimalist (mobile?) client
  • Con: ActivityPub/ActivityStreams/JSON-LD in how they are done have a very high of equally-valid ways to represent one thing, it means software should copy the format of each others for interoperability but it means that variations always happen and you’ll likely need to normalize to an internal format
  • Con: ActivityPub is also very under-specified, authentication, permissions and security are almost entirely implementation-defined
  • Con: There isn’t a large amount of libraries for working with JSON-LD and very few are actually good, it’s not surprising to see one which breaks when w3.org goes down and doesn’t allows to point to a namespace catalog (something very usual in XML), which you might prefer for privacy

ActivityPub Client-to-Server implementations

(will be transformed into examples once there is too much to keep track)

  • Pleroma (Server): Moderately Complete, allows HTTP Basic Auth and OAuth, uses ActivityPub in it’s database, which is normalized and validated
  • FedBox: (Server) Might be the most complete one, has interesting extensions like filtering
  • AndStatus (Client, Android): Complete enough to push Pleroma’s AP C2S forward
  • Your own implementation? Comment below.

AP C2S Tools

4 Likes
2

There are several questions like:

  • How could notifications be handled?
  • How does one handle media uploads?
  • Has the mobile client got to fetch each single remote profile on its own? (since posts could but mostly doesn’t contain the complete profile)
  • How could searches (for profiles or content like hashtags) be implemented?
  • What are you doing when you receive a contact request both on the regular desktop and the mobile app. How does the mobile app gets to know that the request had been accepted - or rejected - via the desktop?
  • What about some fancy stuff like shared read/unread marker?
  • How can you fetch the whole context of a single posts (parents and children of the whole conversation).
1 Like
3

FedBox filtering could be a start as notifications are loosely just the actor being present into the to field (normalization helps there), presence in the cc field being for the regular timeline.
Quite the same semantics as ~formal emails there.

Extension to ActivityPub, which Pleroma implemented. I wrote a standardization draft and ended up never posting it because of the bunch of changes and lack of examples in the Fediverse Enhancement Proposal project and the more discussion-oriented thread I started went nowhere.

I’ll likely end up posting it properly into litepub, here is the draft: https://hacktivis.me/tmp/uploadMedia.html

In my opinion the local client should never fetch remote posts by itself and instead always use the proxyUrl endpoint (which pleroma doesn’t have yet btw) so authentication can work with keeping the users’ key into the server as currently done.

Maybe FedBox filtering could work for this but I’d rather have something which embraces good full-text search rather than end up with something like grep(1).

You mean a Follow activity? Implementation defined again but I guess sending a second Accept/Reject would be an invalid activity, of course ActivityPub has basically no such thing as error messages…

There is the Read activity, only software I’m aware of which uses it is Honk.

Something like FedBox filtering could be used there I guess but there is a lack of a “Give me anything matching this, regardless of the endpoint/collection”

1 Like