The entire specification (which is admittedly incomplete) and implementation are open source.
I am not aware of a dedicated test suite for alternative implementations. It's too early, IMHO. I personally would much prefer the team to focus their time elsewhere for the time being.
They already build off of many related specifications, which have independent implementations, and a lot of the core protocol is RPC style, with schemas that they do publish. So there's already a lot of rigidity here for alternative implementations to use in a way that is extremely likely to be compliant.
I guess another way of putting it is "I don't exactly disagree with you but doing that takes work, and we're at the stage of this stuff where that work is being done, so expecting it right now feels premature to me." The spec isn't "released" or "done," it's in development.
The whole point was to start from scratch.
I'd be curious to learn about those.
From my own understanding, the biggest useful differences for me personally is: account portability, domains as usernames and content-addressable from the ground up.
- Account portability - Useful if/when you want to move between servers
- Domains as usernames - Ties into the same value as account portability. I've owned my own domain for decades, it never changes and probably won't, until years after I die
- Content-addressable - Caching and syncing becomes so much easier, which is a huge issue Mastodon currently suffers from.
ActivityPub can identify users based on their domain too. Probably better than BlueSky does, because it uses better standardized mechanisms - the URI needs to dereference to a valid ActivityPub actor and the community has converged to using webfinger for discovery. The fact that web-finger is generally used for user discovery makes it easier to use the identical mechanism that BlueSky uses - where the identity (which in ActivityPub is a URL) is not tied directly to a domain. (Eg, if you do a webfinger query for marius.federated.id you will get a response where it tells you that one of the URLs for the ActivityPub identity associated with that is https://metalhead.club/@mariusor, you can check it out right now with curl https://marius.federated.id/.well-known/webfinger?resource=h...).
Account portability can exist in ActivityPub because the verbs for signaling to the network that an object/actor has moved to a different URL are in the vanilla vocabulary. The fact that nobody has implemented this so far does not make it impossible. (It's not like anyone so far needed to move from BlueSky to ... I don't know... BlueSky. So it being capable of moving identities is still equally theoretical in my view).
Regarding your last point (or the one made about it in the twitter thread), I don't really understand about how identifying content by its cryptographic signature is conducive to better caching and "syncing" (how in the world a hash would make it easier to sync content than a URL I don't know). HTTP clients, servers and proxies have very good caching and syncing mechanisms for anything that uses URLs to identify resources. Whatever BlueSky wants to do, must invent their own intermediary layers before anyone will be able to say "it's easier" with any certainty.
In my opinion nothing you mentioned can be called a "doing things wrong from first principals(sic)" - and I'm still hoping that linuxdude314 can make a better argument.
ActivityPub is fine for what it was designed to be: an exchange mechanism for "low impact" social activity. It's not meant to interact with cryptocurrencies, it's not meant to shelter dissidents from corrupt governments, it's not meant to help you interact with your drug dealer, nor whistle-blow on your employer. There are already options for those things. It is meant to allow your grandma to like your cat pictures in a more distributed manner than facebook offers. The people that imagine BlueSky will be doing something more than that, are - in my opinion - vastly overevaluating it.
(PS. Apparently this was not "similarly short", apologies.)
But something I can answer directly to as I have deeper expertise with it, is this:
> how in the world a hash would make it easier to sync content than a URL I don't know
URLs are pointing to a location while content-hashes point to specific pieces of content. Moving from URLs to hashes as URIs gives you the benefit of being able to fetch the content from anywhere, and cache it indefinitely.
Basically any large distributed system out there, no matter if it deals with caching or not is built on top of content-addressable blobs, as it reduces the complexity by magnitudes.
Suddenly, you can tell any of your peers "Give me content X" and you don't really care where it comes from, as long as it is verifiably X. Contrast that to URLs which point to a specific location somewhere, and someone has to server it. If the URL is unresponsive, you cannot really fetch the content anymore.
Content-addressing used in this manner is not new or invented by Bluesky, but a old concept that has been used for multiple use cases, caching is maybe the most common one, but definitely not the only one. Probably the first time I came across it was in Plan 9 (Venti) around ~2000 sometime. First time I actually used it in production was with Tahoe-LAFS, which must have been around ~2010 sometime I think.
That is, I can just paste the URL for this article into my Mastodon instance, and if it has it, it'll fetch it from the local storage, if it doesn't it'll try to fetch it from the source, but there's nothing preventing a hierarchy of caches here, nor is there anything preventing peer to peer.
But while ActivityPub says that object id's "should" be https URL's for public objects, the basic requirement of ActivityStream is just that it's a unique URI, and there's nothing stopping an evolution of ActivityPub allowing URI's pointing to, say, IPFS or similar by content hash instead of a https URL.