4 ms·

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 th

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.

capableweb 3y ago
From the AT Protocol FAQ: > 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?
tedunangst 3y ago
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.
sangnoir 3y ago
> 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.

capableweb 3y ago

From the AT Protocol FAQ: > 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?

tedunangst 3y ago

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.

sangnoir 3y ago

> 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.