The author makes the basic mistake of most of the people implementing ActivityPub services: they want to map the logic of an existing type of web application and contort existing domain objects into encoding/decoding to an "impractically large number" of options. That happens because they want two things in one: a server and a client.<p>The ActivityPub specification needs to be read with a goal similar to an email server in mind. It should do one thing: receive JSON-LD objects in inbox, process them according to the specification, and(maybe) store them on disk.<p>The idea of "users", "friends", "posts", "feeds" etc, are concepts that belong to the clients on top of this server, not in the server itself.<p>This separation between clients and server will also allow better interop/graceful degradation of object types that the client/server don't specifically understand.
Saw some comments on the protocol being fluffy and typical implementations resource hungry. This is an interesting guy to follow:<p><a href="https://universeodon.com/@supernovae" rel="nofollow">https://universeodon.com/@supernovae</a><p>He's the admin of universeodon, a mastodon instance with 13K MAU. He recently shared that in a month's time, 3TB of text was transferred just in ActivityPub events. Images a multiple of it. I don't know what the bill is, but I was pretty shocked by the stats...for "just" 13K users.<p>And the cruel thing is that it still doesn't work properly. Likes/boosts and replies do not properly synchronize.
My question is this: if I was to try to hack up an ActivityPub server in my platform of choice, how would I know how compliant it is? Is there any compliance test suite to verify this?<p>"Try and load it up in a client app" seems suboptimal.<p>"load it up and see" attitude is part of what made parsing and renderings HTML so hairy, and compliance test suites helped.
I found the post well written and informative. Though I am clueless about OCaml it feels as this would be useful for anybody working on a new server implementation in any language ecosystem as it highlights what needs to be done and potential bottlenecks.<p>As for the activitypub spec and the currently popular implementations it doesnt take long exposure to the fediverse to realise there are some rough edges and historical accidents (e.g mastodon being actually the defacto interpretation of the standard). Imho now that there is substantial more mindshare devoted to decentralized social it would be opportune to revisit these things and if needed revise before they get backed in.