Support 301 redirection for account migration

[kevinmarks]

Mastodon now has UX for account migration - hooray!
However, it doesn't actually redirect the account and followers . I can still post in the old instance, and my followers still see it, they still have to follow me in my new instance separately.

Now deep down at the HTTP level, there is an answer for this - the 301 redirect, which says 'go to this new URL instead, and remember that for next time you look (as opposed to the 302 redirect, which says 'go to this new URL for now, but check the original one again next time).

Websub (the OStatus way of sending posts to followers) explicitly recommends this - this was clarified with mastodon in mind and has a test.

ActivityPub (the other way of doing this that Mastodon implements) doesn't specify migration directly, but does normatively reference HTTP so 301 should apply there too.

This has 2 components - serving 301s correctly, which presumably would use the moved_to_account_id field to get the updated values when information is requested, and responding to 301s correctly, which should just involve updating the various URLs and domains in the account record.

Lack of this is widely noted as a problem with federation, as people stumble onto an instance initially, and then are unsure how to move fully to another one e.g.

Migrating does not retain your followers. Anybody who follows you will be left following your old dead account
lifehacker

---

Forked from the old migration issue as that has got into the weeds of compromised instances. This is for the relatively simple 'I have moved from instance a to instance b' case that we have UI for.

[Gargron]

On the protocol level, a 301 redirect is not a good idea. It means when you are resolving an old resource and trying to reference attribution, you resolve to a new account (potentially different server). When you then desire to interact with that resource in any way, you are sending to the new account which does not actually control that old resource. Similarly, if you consider 301 a signal to re-attribute all known content in the database to the new account, you are stuck in a similar situation where future interactions with that old content would go into a black hole.

On HTML level, i.e. viewing the profile as an end-user, you could do 301s, but you may still end up in a situation where the end-user desires to browse old content, and forcefully redirecting them to a different profile is not helpful.

[kevinmarks]

That is the exact use case for moving an account to a different server. Yes, you'd need to verify that is what the user wants, but migrating followers works best this way. See w3c/websub#98 There is the issue of historic post migration, which would require more cooperation between the two servers to ensure that they have moved, but for the main profile url 301 makes the most sense.

…

On Wed, 26 Dec 2018, 05:36 Eugen Rochko ***@***.*** wrote: On the protocol level, a 301 redirect is not a good idea. It means when you are resolving an old resource and trying to reference attribution, you resolve to a new account (potentially different server). When you then desire to interact with that resource in any way, you are sending to the new account which does not actually control that old resource. Similarly, if you consider 301 a signal to re-attribute all known content in the database to the new account, you are stuck in a similar situation where future interactions with that old content would go into a black hole. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#8465 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGCwJKWqpTPpZnjDL4oM0VuSzRrDx-xks5u8wrxgaJpZM4WM23T> .

[Gargron]

On the protocol level, a 301 redirect is not a good idea. It means when you are resolving an old resource and trying to reference attribution, you resolve to a new account (potentially different server). When you then desire to interact with that resource in any way, you are sending to the new account which does not actually control that old resource. Similarly, if you consider 301 a signal to re-attribute all known content in the database to the new account, you are stuck in a similar situation where future interactions with that old content would go into a black hole.

On HTML level, i.e. viewing the profile as an end-user, you could do 301s, but you may still end up in a situation where the end-user desires to browse old content, and forcefully redirecting them to a different profile is not helpful.

[kevinmarks]

That is the exact use case for moving an account to a different server. Yes, you'd need to verify that is what the user wants, but migrating followers works best this way. See w3c/websub#98 There is the issue of historic post migration, which would require more cooperation between the two servers to ensure that they have moved, but for the main profile url 301 makes the most sense.

…

On Wed, 26 Dec 2018, 05:36 Eugen Rochko ***@***.*** wrote: On the protocol level, a 301 redirect is not a good idea. It means when you are resolving an old resource and trying to reference attribution, you resolve to a new account (potentially different server). When you then desire to interact with that resource in any way, you are sending to the new account which does not actually control that old resource. Similarly, if you consider 301 a signal to re-attribute all known content in the database to the new account, you are stuck in a similar situation where future interactions with that old content would go into a black hole. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#8465 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGCwJKWqpTPpZnjDL4oM0VuSzRrDx-xks5u8wrxgaJpZM4WM23T> .