ActivityPub needs something like the Busy Developer's Guide to SOAP we did in 2001.
https://web.archive.org/web/20050204072726/http://www.soapware.org/bdg
you nailed it. perfect.
i only know one developer who has a full AP toolkit, i've been urging him to get busy on the other side of the API, to help other devs adopt it.
otherwise everyone is just going to use the mastodon api.
it's like water flowing downhill.
the software has to follow the shortest path downhill.
AP being an open format and protocol has a big advantage, but if you can't make the software it's all theoretical.
@pwinn @dave yeah, we had the same disagreement with openid. If you are a “busy developer” then you’re likely to make fundamental mistakes and put your users at risk. I don’t think anyone whose lives through the last few years can claim they are unimpacted by the shortsighted decisions of social media developers.
@josephholsten @dave I guess I'd make a distinction between things that are irreducibly complex and things that are arbitrarily complex.
I don't think anybody can credibly claim that ActivityPub is irreducibly complex. It's really hard to make arbitrarily complex things simple, but that's key to widespread adoption.
Which is why Mastodon is what most people know of the fediverse. It's simpler.
@pwinn @dave I am amazed at how many requirements the AP specification has, and how there are no published simple “common rules of the road” to define a minimal set of supported activities, object types and collections, best practices for adressing (for privacy and visibility), etc. You have to read and understand the source code for Masto and other servers.
I count ~100 rules or recommendations in the spec: https://github.com/pzingg/fedi/blob/main/IMPLEMENTATION.md