> Instead we get a haphazard rewrite of everything ActivityPub has already solved
As someone who doesn't seem to be a deep into the specifications (ActivityPub nor AT Protocol) as you are, how does ActivityPub handle people moving across servers without loosing old content and interactions? Like if I use server A but want to move to server B, how does that work in practice? How does server C who used to communicate with server A get notified that they now have to communicate with server B instead?
> The service feels too much like "Elon bought Twitter, now we need to make Twitter again"
Strange feeling considering bluesky was first announced in 2019 as a Twitter project, eventually spun out as a separate entity in 2021, and Elon didn't start the acquisition of Twitter until 2022 sometime.
Right now, changing accounts is implemented by the old server sending a Move activity which tells all your followers where your new account is. This doesn't handle moving any content.
But, there's nothing fundamental about ActivityPub that prevents this: https://shadowfacts.net/2023/activitypub-portable-identity/. You can absolutely have posts identified by your identity (read: domain) rather than where they're hosted. Complete and seamless moves are possible, Mastodon just doesn't implement them.
Interesting, thanks for sharing that. This has been one of the things I felt that ATP got "right", so neat to see that ActivityPub can do it, even if Mastodon doesn't.
Interesting. So ActivityPub could support that use case, but currently doesn't. Combined with the fact that getting changes through to the specification itself (maintained by W3C), I could understand not wanting to spend the energy and effort on trying to go that route, and instead come up with something different.
Thanks for sharing your article, lots of good points in there.
The old server broadcasts a 'this person has moved'-message. Your followers will then automatically switch over to the new account.
This implies that:
- If the old server is offline or unwilling, you cannot move
- Your old toots and interactions will still be tied to the old address, so you leave those behind.
There is some talk going on to find ways to mitigate this and it might be possible to fix the second issue.
The first issue is a bit trickier though. If you were to remove trust from the server, it becomes way harder to fight spam.
> Our solution for portability requires both signed data repositories and DIDs, neither of which are easy to retrofit into ActivityPub. The migration tools for ActivityPub are comparatively limited; they require the original server to provide a redirect and cannot migrate the user's previous data.
So it seems that AT Protocol has a solution to that specific problem, while ActivityPub does not. So there is some differences between the protocols after all, and it might seem like they have at least one reason for creating a new protocol rather than trying to adjust ActivityPub to fit as a solution?
We'll have to wait and see how many clients default to storing a complete data repository for AT in order to complete a migration from an offline server.
> If the old server is offline or unwilling, you cannot move - Your old toots and interactions will still be tied to the old address, so you leave those behind.
This is just like any other system that combine content delivery and identity on the same channel (e.g. web sites). Even if those 2 were separate, if your centralized identity provider is down, there is no way to update clients that depend on it, or to safely attest a new identity.
Allowing unverified servers to claim an identity or kick off a migration is a recipe for widespread hacking.
As someone who doesn't seem to be a deep into the specifications (ActivityPub nor AT Protocol) as you are, how does ActivityPub handle people moving across servers without loosing old content and interactions? Like if I use server A but want to move to server B, how does that work in practice? How does server C who used to communicate with server A get notified that they now have to communicate with server B instead?
> The service feels too much like "Elon bought Twitter, now we need to make Twitter again"
Strange feeling considering bluesky was first announced in 2019 as a Twitter project, eventually spun out as a separate entity in 2021, and Elon didn't start the acquisition of Twitter until 2022 sometime.