ActivityPub has been around for much longer. I consider Nostr and Bluesky rip offs of what ActivityPub has been trying to build for more than a decade.
> [...] Account portability is the major reason why we chose to build a separate protocol. We consider portability to be crucial because it protects users from sudden bans, server shutdowns, and policy disagreements.
I like the Nostr approach where "the data IS the network".
It is true that their current approach of having "relays" as their main distribution system is not that censor resistant, but once you have that "network in the data" it is trivial to switch at any point to swapping encrypted files or even USB-sticks with your friends if you want.
Has ActivityPub anything similar?
Edit: and this is not just important for distribution, but for archiving. How many interesting Twitter threads and Youtube videos have been lost in the ether unless you manually archived them? And even if you archived it nobody can't tell if they are the same as the originals. With Nostr you can solve this with clients that do archiving automatically, and all the links stay "fresh" and shareable as long as somebody keeps the data.
Account data migrations are already supported on ActivityPub. If they didn't like the way they are implemented, they could have extended the specs. Building a completely new protocol just because you want to support account migrations your own way is just dumb.
My understanding is that ActivityPub, while being federated, puts huge amounts of power and responsibility in the hands of the node operators, including access to private messages. Identity is at the core of most systems, so if the architecture doesn't work (which would make sense given that ActivityPub is older), then a different protocol may be better.
That's partly true, but ActivityPub could be easily extended to accommodate that requirement.
As of now, the architecture is kind of flat - you have instances (about 10k for Mastodon), managed by admins, and admins all have the same rights and access control.
Bluesky wanted to go for a more semi-centralized "consortium of businesses" that separates the "small world" vs "big world" layer, or something a bit more hierarchical, and have strong authentication implemented on top of it. And that's fair enough - they could have easily implemented a system of keys and certificates hierarchically linked to the top node (the root node of the consortium). The underlying ActivityPub protocol would have remained the same, and they could have implemented whatever extension on top of it that supported source certificate checks, signatures, keys etc.
Twitter instances, or any other more "centralized" social network, could have shown posts with a green tick or whatever to tell that they are coming from a trusted source. Mastodon, Pixelfed, Diaspora and all the likes could have kept doing what they are doing now, their content wouldn't get the green tick if it comes from a server with its own certbot certificate that is not signed with a key generated through a certificate that can be linked back to the root certificate, but apart from that nothing would have prevented bidirectional integration between e.g. Twitter and Mastodon.
It was technically very feasible. And Jack Dorsey, as well as many from Twitter, was also sitting for a while at the same table that designed the ActivityPub specifications.
At some point they decided to leave that table because they wanted more of a say in the development of the protocol - they basically wanted to be more in charge, and shift the ownership of the underlying protocol from an open committee to a consortium of private companies.
Moreover, Dorsey also invested a lot of his money in crypto scams, and now he's that kind of guy with a toolbox full of hammers in search for something that looks like a nail. It's not a coincidence that a lot of the stuff that revolves around Bluesky looks a lot like a Blockchain.
I think these are the real reasons behind the development of an entirely new protocol. On a technical level, nothing would have prevented them from proposing some small patches to ActivityPub that wouldn't even have had to break back-compatibility. Everybody would have benefited from it - they wouldn't have spent a lot of engineering and R&D resources to reinvent the wheel, we wouldn't have had an N+1 protocol to integrate and write bridges for, and we would have finally had something like a truly native Twitter<->Fediverse bidirectional integration that would have benefited users on both sides. But they have different goals than the rest of the people working on these open protocols, and that's why our ways parted.
You lose all your followers. It's like going from blacklight@aol.com to blacklight@gmail.com. It's on you to go to you 1M followers and beg them to refollow you. The goal is to go from tmobile to verizon and your grandma can just call you.
On Mastodon people who see your old profile would get a screen like "this profile has moved here".
Ok, it's still on them to follow you on your new profile, but it's not like you have no connection between the old and new profile.
And I'm among those who want to improve this feature, so actual data exchange (followers and posts) can happen before the two instances during the migration.
