Support account migration

[hach-que]

A lot of people seem to be jumping on https://mastodon.social right now, even though the end goal is to have users separated out across multiple federated instances. However, if people start putting up a lot of content and getting followers on the primary instance, this will be a disincentive to move providers.

I think this largely means that Mastodon needs to support two things:

• Account import across providers, which should be authenticated on both ends to prevent people bulk copying another person's account, and
• A "redirected account" field against user accounts, which indicates the full URL of the new user account

When users configure a redirect location against their account (whether explicitly on an account page, or implicitly set during a cross-provider account import), the instance on which the account is should implicitly and automatically redirect followers.

That is, if I have the account @hq on the primary instance (which I do), and I set up the account @hach-que on another Mastodon service, the @hq should:

• Remain on the primary instance, and not be disabled in any way
• Show posts from @hach-que after the redirection is set up
• Disallow posting from the @hq account while ever the redirection is in place
• Existing followers of @hq should start seeing posts from @hach-que instead
• New followers of @hq should be allowed to follow the account (and internally, they are following @hq, but see posts from @hach-que)
• Followers should not actually have their lists updated to follow @hach-que - in the event of a mistaken redirect, removing the redirect should act exactly as if there never was a redirect in the first place

This is just my 2c on how I think this should work, but I'm interested to hear other people's thoughts.

[nex3]

A "redirected account" field would also be very useful for renaming accounts within a single server.

[nex3]

A "redirected account" field would also be very useful for renaming accounts within a single server.

[Gargron]

Sadly there's nothing in the OStatus protocol currently that's like "go follow my new account instead of this one". Best I can offer is migrating content (but reblogs/favs would not come along) and who you were following.

[Gargron]

Sadly there's nothing in the OStatus protocol currently that's like "go follow my new account instead of this one". Best I can offer is migrating content (but reblogs/favs would not come along) and who you were following.

[hach-que]

I had a bit of a look at the OSocial spec, and it's not 100% clear on what extensions the protocol permits in the <author /> section. All the documentation and links on Portable Contacts (poco) from Wikipedia seem to be dead. Is it possible we can add a new poco tag that contains a redirect or forwarding URL?

edit: or I guess a <link> tag with a different rel attribute?

[hach-que]

I had a bit of a look at the OSocial spec, and it's not 100% clear on what extensions the protocol permits in the <author /> section. All the documentation and links on Portable Contacts (poco) from Wikipedia seem to be dead. Is it possible we can add a new poco tag that contains a redirect or forwarding URL?

edit: or I guess a <link> tag with a different rel attribute?

[nex3]

Unless I'm missing something, shouldn't this be protocol-independent? As @hach-que describes it, as far as followers of the original account are concerned, they're still following that account. So as long as the node that that account lives on is able to proxy posts from the new account, this could be managed in a way that's totally transparent to the protocol.

It gets more complicated if you want new followers to automatically follow the new account instead, but that doesn't match the user-visible behavior described above.

[nex3]

Unless I'm missing something, shouldn't this be protocol-independent? As @hach-que describes it, as far as followers of the original account are concerned, they're still following that account. So as long as the node that that account lives on is able to proxy posts from the new account, this could be managed in a way that's totally transparent to the protocol.

It gets more complicated if you want new followers to automatically follow the new account instead, but that doesn't match the user-visible behavior described above.

[nex3]

I've been thinking about this more. It's an important prerequisite for making federation practical, which I know is something @Gargron cares about a lot. We're already seeing a lot of users making accounts and on mastodon.social in particular, and their investment in the community will (hopefully) only grow in the future.

Existing users are the most likely to understand the value of federation, but they're also the most likely to have a lot to lose by abandoning an existing account. At the same time, most people will only move to other servers if the barrier to entry is very low. Allowing accounts to be migrated without losing their investment in the community will remove the biggest part of that barrier.

[nex3]

I've been thinking about this more. It's an important prerequisite for making federation practical, which I know is something @Gargron cares about a lot. We're already seeing a lot of users making accounts and on mastodon.social in particular, and their investment in the community will (hopefully) only grow in the future.

Existing users are the most likely to understand the value of federation, but they're also the most likely to have a lot to lose by abandoning an existing account. At the same time, most people will only move to other servers if the barrier to entry is very low. Allowing accounts to be migrated without losing their investment in the community will remove the biggest part of that barrier.

[hikari-no-yume]

I wonder if this is something other OStatus implementations would be interested in.

[hikari-no-yume]

I wonder if this is something other OStatus implementations would be interested in.

[marrus-sh]

As an in-the-meantime stepping-stone for this, it would be nice if there was a simple import/export of who you're currently following, so that one could easily migrate that over to a new account. It's easy enough to post a “Changing accounts! Follow me at @█████” toot to let followers know you're changing accounts, but significantly harder to ensure you're following the same people on the new one.

[marrus-sh]

As an in-the-meantime stepping-stone for this, it would be nice if there was a simple import/export of who you're currently following, so that one could easily migrate that over to a new account. It's easy enough to post a “Changing accounts! Follow me at @█████” toot to let followers know you're changing accounts, but significantly harder to ensure you're following the same people on the new one.

[hoodiek]

i know that this is an old issue but i'm thinking more so about making a link for accounts, rather than a migration, namely allowing backwards-compatibility, making follow either mean the same account. this seems like it vaguely might be easier than migration? and i think both are very strong and important things to add to making the multiple instance setup for mastodon work

[hoodiek]

i know that this is an old issue but i'm thinking more so about making a link for accounts, rather than a migration, namely allowing backwards-compatibility, making follow either mean the same account. this seems like it vaguely might be easier than migration? and i think both are very strong and important things to add to making the multiple instance setup for mastodon work

[hoodiek]

i would also suggest a profile option at the very least to show where a person has moved. it does not have to automatically move accounts, but making it easier for users to understand that a user has migrated is easy: could make whenever the new account posted, it would remind all followers of the original account to migrate from that they are posting elsewhere and link to the new account, as well as making a single button to unfollow the original and follow the new one.

[hoodiek]

i would also suggest a profile option at the very least to show where a person has moved. it does not have to automatically move accounts, but making it easier for users to understand that a user has migrated is easy: could make whenever the new account posted, it would remind all followers of the original account to migrate from that they are posting elsewhere and link to the new account, as well as making a single button to unfollow the original and follow the new one.

[hoodiek]

if we get REALLY fancy and i would heavily suggest this: the old account could delete the first post to move accounts whenever it posts it again to update that the migrated account has updated a post, to remind users to migrate manually, while also retaining the repository of old posts as a result.

[hoodiek]

if we get REALLY fancy and i would heavily suggest this: the old account could delete the first post to move accounts whenever it posts it again to update that the migrated account has updated a post, to remind users to migrate manually, while also retaining the repository of old posts as a result.

[leeeeeny]

Exporting/importing following/blocking lists is great but in my opinion it's not enough. As OP said, people who've tooted will probably stick with their first account instead of moving. I do think that too. I'd like to create an instance and move my account to it but i don't want to get a new account (plus we can't use multiple account at the same time like in TweetDeck). I think an account migration/backup tool is the most missing feature of Mastodon. Complicated sync over instances features are not needed, just a tool to export (CSV or whatever) and delete an account and import it back on another instance would allow people to control their account. Since the instances are managed by the instances' owners, they may be unreliable (reports not processed seriously, 50 % uptime). Then you just have to move.

[leeeeeny]

Exporting/importing following/blocking lists is great but in my opinion it's not enough. As OP said, people who've tooted will probably stick with their first account instead of moving. I do think that too. I'd like to create an instance and move my account to it but i don't want to get a new account (plus we can't use multiple account at the same time like in TweetDeck). I think an account migration/backup tool is the most missing feature of Mastodon. Complicated sync over instances features are not needed, just a tool to export (CSV or whatever) and delete an account and import it back on another instance would allow people to control their account. Since the instances are managed by the instances' owners, they may be unreliable (reports not processed seriously, 50 % uptime). Then you just have to move.

[Maverynthia]

Why is it hard to migrate followers? Can't the new system just point to the people on the old system.
Such as if I follow @name on the old system, then when I migrate it then points to @name@mastodon.social or something? Or even just an auto follow and then they have to refollow you?

[Maverynthia]

Why is it hard to migrate followers? Can't the new system just point to the people on the old system.
Such as if I follow @name on the old system, then when I migrate it then points to @name@mastodon.social or something? Or even just an auto follow and then they have to refollow you?

[gdurelle]

The idea is great but the example is a bit complicated, don't you think ?

If I want to migrate my account from mastodon.xyz to another instance, i would want to keep the same username.

Supporting username change should be a "second step" after this first step. (baby steps like neagan says ;))

What I see :
1 - I go the new instance says i want to migrate from mastodon.xyz,
2 - My username is temporary reserved on the new instance
3 - I indicate my login, then it redirects me to mastodon.xyz for authentication (OAuth2)
4 - Once authorized, the migration process begins by importing my parameters in the new instance (following, followers, toots, etc)
5 - delete my account from mastodon.xyz
6 - Enable me on the new instance
7 - update my following with my new address.

my 2cts. (gonna have a lot of cents if we all add up)

[gdurelle]

The idea is great but the example is a bit complicated, don't you think ?

If I want to migrate my account from mastodon.xyz to another instance, i would want to keep the same username.

Supporting username change should be a "second step" after this first step. (baby steps like neagan says ;))

What I see :
1 - I go the new instance says i want to migrate from mastodon.xyz,
2 - My username is temporary reserved on the new instance
3 - I indicate my login, then it redirects me to mastodon.xyz for authentication (OAuth2)
4 - Once authorized, the migration process begins by importing my parameters in the new instance (following, followers, toots, etc)
5 - delete my account from mastodon.xyz
6 - Enable me on the new instance
7 - update my following with my new address.

my 2cts. (gonna have a lot of cents if we all add up)

[leeeeeny]

Yes that's a bit complicated but imo this is a very important feature to permit existing users balancing between the instances and avoid account loss in case of instance shutdown.

[leeeeeny]

Yes that's a bit complicated but imo this is a very important feature to permit existing users balancing between the instances and avoid account loss in case of instance shutdown.

[Sadzeih]

I agree with everyone here. Account migration is necessary. The most important is toots and followers for me. Followings too but they can already be exported. Username would be a good thing too.

[Sadzeih]

I agree with everyone here. Account migration is necessary. The most important is toots and followers for me. Followings too but they can already be exported. Username would be a good thing too.

[Motoma]

Account migration is a necessity if you want federation to be a first-class citizen. Users need to be insulated from the risks associated with decentralization. If an instance goes away (crashes, is hacked, shut down by an oppressive regime) those users should not be SOL. Lacking that, users will flock to the instance with the highest likelihood of surviving.

[Motoma]

Account migration is a necessity if you want federation to be a first-class citizen. Users need to be insulated from the risks associated with decentralization. If an instance goes away (crashes, is hacked, shut down by an oppressive regime) those users should not be SOL. Lacking that, users will flock to the instance with the highest likelihood of surviving.

[cyphar]

Well, there's two ways (in my mind) of fixing the problem:

1. You do it the GitHub way, where the old username is now forwarded to the new username. I'm not sure if OStatus has a concept of 301 redirects, but that's how you would do it. The downside is that if the server goes down before a client has got the redirect they're SoL.

2. You handle it the Matrix way, which is that you have identity servers that decouple the "real" ID (@username@instance) from the person whose ID it belongs to. The downside is that Matrix implemented this in a very centralised way, which just punts the issue. Not to mention OStatus almost certainly doesn't have support for such a concept.

[cyphar]

Well, there's two ways (in my mind) of fixing the problem:

1. You do it the GitHub way, where the old username is now forwarded to the new username. I'm not sure if OStatus has a concept of 301 redirects, but that's how you would do it. The downside is that if the server goes down before a client has got the redirect they're SoL.

2. You handle it the Matrix way, which is that you have identity servers that decouple the "real" ID (@username@instance) from the person whose ID it belongs to. The downside is that Matrix implemented this in a very centralised way, which just punts the issue. Not to mention OStatus almost certainly doesn't have support for such a concept.

[cyphar]

@TehShrike This issue is about moving between Mastodon instances, not from Twitter to Mastodon.

[cyphar]

@TehShrike This issue is about moving between Mastodon instances, not from Twitter to Mastodon.

[TehShrike]

Ah, I googled-and-skimmed too quickly >_< I'll delete that post.

[TehShrike]

Ah, I googled-and-skimmed too quickly >_< I'll delete that post.

[cdata]

My hand-wave-y two cents:

It would be nice if there was a decoupled notion of identity. For example: a keybase.io profile aggregates different accounts for a single person so that they can be easily identified across all networks.

If this were true, you could imagine a system where you follow someone on Mastodon by following an identity and all addresses (that is, instance/profile combinations) that are associated with it.

Of course, it isn't easy to maintain a trusted database of identities that is shareable across all federated nodes. But, it's possible. Perhaps we can discuss the feasibility of such an approach.

👋

[cdata]

My hand-wave-y two cents:

It would be nice if there was a decoupled notion of identity. For example: a keybase.io profile aggregates different accounts for a single person so that they can be easily identified across all networks.

If this were true, you could imagine a system where you follow someone on Mastodon by following an identity and all addresses (that is, instance/profile combinations) that are associated with it.

Of course, it isn't easy to maintain a trusted database of identities that is shareable across all federated nodes. But, it's possible. Perhaps we can discuss the feasibility of such an approach.

👋

[stiell]

Blockstack might be a good candidate for providing a decentralised, global identity. With Blockstack you could keep the same ID (and thus your followers) even if the instance you are currently using goes down permanently.

[stiell]

Blockstack might be a good candidate for providing a decentralised, global identity. With Blockstack you could keep the same ID (and thus your followers) even if the instance you are currently using goes down permanently.

[cyphar]

The problem with having separated identities is that it wouldn't be compatible with other OStatus implementations (Mastodon isn't the only implementation, GNU Social is another and there's quite a few more). Migration should be something that someone following a Mastodon user from GNU Social should be able to support.

[cyphar]

The problem with having separated identities is that it wouldn't be compatible with other OStatus implementations (Mastodon isn't the only implementation, GNU Social is another and there's quite a few more). Migration should be something that someone following a Mastodon user from GNU Social should be able to support.

[cdata]

In the fullness of time, I agree that this should be something that is broadly compatible with GNU Social. In the isolation of the moment, I propose that evolution requires experimentation. Compatibility is a matter of adding sufficient layers to make the standardized things cooperate with the experimental thing.

My brain told my hand to stop waving. I'm sure it will stop soon.

[cdata]

In the fullness of time, I agree that this should be something that is broadly compatible with GNU Social. In the isolation of the moment, I propose that evolution requires experimentation. Compatibility is a matter of adding sufficient layers to make the standardized things cooperate with the experimental thing.

My brain told my hand to stop waving. I'm sure it will stop soon.

[SirCmpwn]

I think you guys are making a mountain out of a molehill here. I think this problem is pretty easy to solve. In order of least to most controversial: we should make it possible to import and export toots, we should make an automated migration tool (log into your old account via OAuth from your new instance), and we should toot out a notice of account change.

The migration toot would be a normal toot with a human-readable message ("My account is moving to (link)"), but would include something like this:

<mastodon:migrate participant="origin">https://new-account</mastodon:migrate>

The new account would toot something like this to confirm it ("Moved from my old account (link)"):

<mastodon:migrate participant="destination">https://old-account</mastodon:migrate>

Then, clients can recognize this attribute and perform the migration when they see the toot by unfollowing and following the new account (possibly with an another XML extension that indicates the user is responding to an account migration). Clients would likely want to hide the special toots from the feed as well. Clients that don't support it have the human-readable version as a fallback. Then we just send patches to GNU Social and other projects to recognize this behavior.

[SirCmpwn]

I think you guys are making a mountain out of a molehill here. I think this problem is pretty easy to solve. In order of least to most controversial: we should make it possible to import and export toots, we should make an automated migration tool (log into your old account via OAuth from your new instance), and we should toot out a notice of account change.

The migration toot would be a normal toot with a human-readable message ("My account is moving to (link)"), but would include something like this:

<mastodon:migrate participant="origin">https://new-account</mastodon:migrate>

The new account would toot something like this to confirm it ("Moved from my old account (link)"):

<mastodon:migrate participant="destination">https://old-account</mastodon:migrate>

Then, clients can recognize this attribute and perform the migration when they see the toot by unfollowing and following the new account (possibly with an another XML extension that indicates the user is responding to an account migration). Clients would likely want to hide the special toots from the feed as well. Clients that don't support it have the human-readable version as a fallback. Then we just send patches to GNU Social and other projects to recognize this behavior.

[SirCmpwn]

I'll probably start working on a toot export/import tool shortly, in any case.

[SirCmpwn]

I'll probably start working on a toot export/import tool shortly, in any case.

[Maverynthia]

@TehShrike There IS this tool for what you are looking for: https://mastodon-bridge.herokuapp.com/ but that's only if they signed up on both.

[Maverynthia]

@TehShrike There IS this tool for what you are looking for: https://mastodon-bridge.herokuapp.com/ but that's only if they signed up on both.

[kevinmarks]

The way to connect accounts is XFN - rel information on links. You use rel=me to say "this is also me" and if both urls do that to each other it's confirmed.
rel="friend" will do for following (there are others, but that is simple enough to use).

If you want to convey "I moved there" use rel="canonical me"

The added benefit of this is that you can do actual distributed verification tags - confirming people's twitter/github/medium/whatever accounts too.

[kevinmarks]

The way to connect accounts is XFN - rel information on links. You use rel=me to say "this is also me" and if both urls do that to each other it's confirmed.
rel="friend" will do for following (there are others, but that is simple enough to use).

If you want to convey "I moved there" use rel="canonical me"

The added benefit of this is that you can do actual distributed verification tags - confirming people's twitter/github/medium/whatever accounts too.

[SirCmpwn]

I'm not sure those fit ideally into this problem, @kevinmarks. They're for duplicated content, not a one-time notification that the content publisher has moved. Would make more sense if we were mirroring toots between multiple accounts but I think that's unrelated to the matter at hand.

[SirCmpwn]

I'm not sure those fit ideally into this problem, @kevinmarks. They're for duplicated content, not a one-time notification that the content publisher has moved. Would make more sense if we were mirroring toots between multiple accounts but I think that's unrelated to the matter at hand.

[kevinmarks]

the point about rel's is that they are amenable to setting up bidirectional verification of the move. Then you can use a 301 redirect for moved URLs.

[kevinmarks]

the point about rel's is that they are amenable to setting up bidirectional verification of the move. Then you can use a 301 redirect for moved URLs.

[SirCmpwn]

I think I see what you mean. The one-time "I've moved" toots could use rel="me" (new account) and rel="canonical me" (old account) to indicate the move? I'm still not sure that's entirely in the spirit of these attributes but I don't see why it wouldn't work.

[SirCmpwn]

I think I see what you mean. The one-time "I've moved" toots could use rel="me" (new account) and rel="canonical me" (old account) to indicate the move? I'm still not sure that's entirely in the spirit of these attributes but I don't see why it wouldn't work.

[kevinmarks]

No, they shouldn't be toots, they should be in the bio section

…

On 5 Apr 2017 1:31 am, "Drew DeVault" ***@***.***> wrote: I think I see what you mean. The one-time "I've moved" toots could use rel="me" (new account) and rel="canonical me" (old account) to indicate the move? I'm still not sure that's entirely in the spirit of these attributes but I don't see why it wouldn't work. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#177 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGCwJHPYajcxkpXohajzF5z9LASspUdks5rsuDxgaJpZM4K5Bba> .

[kevinmarks]

No, they shouldn't be toots, they should be in the bio section

…

On 5 Apr 2017 1:31 am, "Drew DeVault" ***@***.***> wrote: I think I see what you mean. The one-time "I've moved" toots could use rel="me" (new account) and rel="canonical me" (old account) to indicate the move? I'm still not sure that's entirely in the spirit of these attributes but I don't see why it wouldn't work. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#177 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGCwJHPYajcxkpXohajzF5z9LASspUdks5rsuDxgaJpZM4K5Bba> .

[SirCmpwn]

Aha, good idea. Makes sense.

[SirCmpwn]

Aha, good idea. Makes sense.

[enkiv2]

Doesn't importing a list of exported toots represent a pretty major potential vulnerability with regard to spamming? For instance, somebody could make a large synthetic export file with faked timestamps and flood the local timeline on a new account, or create new one-off follower accounts on several major nodes first and flood several federated timelines, at a scale larger than manual posting, if my understanding of how federation works is correct.

Don't get me wrong -- I think transferring full toot history is important for account migration, and I think we should have an export function for toots available to all users -- but I think full account transfer should probably be negotiated between federated servers (even if it's a separate protocol or an extension), and that toot history import should either: 1) be heavily limited in scale (say, no more than 100); 2) be omitted from inclusion in the local and federated timelines; or 3) have retroactively-applied rate limits at least as strict as the ones applied to people posting through the existing front end, so that any file with toot timestamps too close together gets rejected.

[enkiv2]

Doesn't importing a list of exported toots represent a pretty major potential vulnerability with regard to spamming? For instance, somebody could make a large synthetic export file with faked timestamps and flood the local timeline on a new account, or create new one-off follower accounts on several major nodes first and flood several federated timelines, at a scale larger than manual posting, if my understanding of how federation works is correct.

Don't get me wrong -- I think transferring full toot history is important for account migration, and I think we should have an export function for toots available to all users -- but I think full account transfer should probably be negotiated between federated servers (even if it's a separate protocol or an extension), and that toot history import should either: 1) be heavily limited in scale (say, no more than 100); 2) be omitted from inclusion in the local and federated timelines; or 3) have retroactively-applied rate limits at least as strict as the ones applied to people posting through the existing front end, so that any file with toot timestamps too close together gets rejected.

[thomaslule]

A user opinion about the priority when migrating: make followers auto-follow the new account.

I believe that mastodon, as other microblogging platforms, is mainly focused on real-time.

I can deal with going back to a clean toots history but starting again from 0 followers would totally discourage me to migrate to another instance. And I know that a "I moved here re-follow me!" notification won't be enough to bring back half of the people that were in my network.

What is really precious in an account is its followers base.

[thomaslule]

A user opinion about the priority when migrating: make followers auto-follow the new account.

I believe that mastodon, as other microblogging platforms, is mainly focused on real-time.

I can deal with going back to a clean toots history but starting again from 0 followers would totally discourage me to migrate to another instance. And I know that a "I moved here re-follow me!" notification won't be enough to bring back half of the people that were in my network.

What is really precious in an account is its followers base.

[cangyuyao]

I've been watching this thread two months ago... I personally don't care importing old toots or migration, but exporting toots is extremely important. Not only I tend to backup my main SNS accounts regularly, sometimes I recall something I said months ago and want to quote it and I'll never find that toot if I don't remember the time I posted it. Now I'm using the atom feed and ifttt to sync public posts but there's no solution for private ones.

[cangyuyao]

I've been watching this thread two months ago... I personally don't care importing old toots or migration, but exporting toots is extremely important. Not only I tend to backup my main SNS accounts regularly, sometimes I recall something I said months ago and want to quote it and I'll never find that toot if I don't remember the time I posted it. Now I'm using the atom feed and ifttt to sync public posts but there's no solution for private ones.

[apLundell]

Being told right up front that you should irrevocably attach your social life to a server run by some rando.... is not a welcoming way to start using a new service.

There really needs to be a way to say "But don't worry. If the server you choose goes sideways, you can switch to another, no harm done."

It's like right at the very start you're hit in the face with the biggest weakness of decentralization, and there's no tools to make it better.

[apLundell]

Being told right up front that you should irrevocably attach your social life to a server run by some rando.... is not a welcoming way to start using a new service.

There really needs to be a way to say "But don't worry. If the server you choose goes sideways, you can switch to another, no harm done."

It's like right at the very start you're hit in the face with the biggest weakness of decentralization, and there's no tools to make it better.

[davidpgil]

I think this would be solved by having a simple federated single user install and have people NOT worry about knowing anything about system administration. I feel this was a missed opportunity.

[davidpgil]

I think this would be solved by having a simple federated single user install and have people NOT worry about knowing anything about system administration. I feel this was a missed opportunity.

[neuoy]

I like the idea of cryptography to have a decentralized identity (i.e. if you have your private key, you can authenticate without any server support). This would mean followers would just follow your public key, not your name, not your server. If you sign a toot on any server with your private key, followers would see it, because they know it's you, they don't have to update anything related to your identity on that new server. However, I suppose things are not working this way right now, and so this is probably a complicated option to implement in the existing system. Also, this makes the private key very sensitive ; if it leaks, you're screwed (maybe there are clever ways to alleviate this issue, but I can't think of any at this time).

Therefore, I would suggest implementing a more simple migration based on two-way authentication (you say on your old server where you have moved to, and you say on the new server from where you have moved). At this point, followers should update automatically to follow you on your new server, otherwise the feature is not very helpful. They could always stop following you if they don't like your new server or whatever.

Are there actual plans to implement such a feature? I do think this is very important, otherwise you effectively lock yourself on the first server you use, just like you do on twitter or facebook, and I thought Mastodon was designed to avoid that by providing a distributed protocol...

[neuoy]

I like the idea of cryptography to have a decentralized identity (i.e. if you have your private key, you can authenticate without any server support). This would mean followers would just follow your public key, not your name, not your server. If you sign a toot on any server with your private key, followers would see it, because they know it's you, they don't have to update anything related to your identity on that new server. However, I suppose things are not working this way right now, and so this is probably a complicated option to implement in the existing system. Also, this makes the private key very sensitive ; if it leaks, you're screwed (maybe there are clever ways to alleviate this issue, but I can't think of any at this time).

Therefore, I would suggest implementing a more simple migration based on two-way authentication (you say on your old server where you have moved to, and you say on the new server from where you have moved). At this point, followers should update automatically to follow you on your new server, otherwise the feature is not very helpful. They could always stop following you if they don't like your new server or whatever.

Are there actual plans to implement such a feature? I do think this is very important, otherwise you effectively lock yourself on the first server you use, just like you do on twitter or facebook, and I thought Mastodon was designed to avoid that by providing a distributed protocol...

[Cassolotl]

I opened a new issue because I didn't think there was an open one - I thought it had been confirmed that Mastodon usernames couldn't be changed way back when, and now that we'd switched to ActivityPub there might be a chance this could be revisited.

I said:

Folks seem to ask semi-frequently if it's possible to change usernames, so I think this might be good.

However, I did see rumours at some point that it's not possible to alter subscription info on other instances, so if I changed my username the accounts of my followers on other instances wouldn't update to my new username. I'm wondering if that's still the case?

Edit: If this isn't possible, can there be some kind of indication at registration that changing usernames isn't possible?

Then @chronister said:

I think the main problem is that the unique identifier for an account remotely is the username. All remote instances might give alice@example.social different IDs but that string, alice@example.social, is how they identify alice as the same person.

If there's some mechanism in activitypub to effectively do a "redirect" or "symbolic link" of one handle to another this might be possible, but if not then it doesn't really seem feasible. Someone who's read the AP spec in detail might be able to give a more definitive answer here.

So, does anyone know for sure whether or not ActivityPub would allow for changing one's username?

See also #5647 - asking for a warning at registration that usernames can't be changed later on.

[Cassolotl]

I opened a new issue because I didn't think there was an open one - I thought it had been confirmed that Mastodon usernames couldn't be changed way back when, and now that we'd switched to ActivityPub there might be a chance this could be revisited.

I said:

Folks seem to ask semi-frequently if it's possible to change usernames, so I think this might be good.

However, I did see rumours at some point that it's not possible to alter subscription info on other instances, so if I changed my username the accounts of my followers on other instances wouldn't update to my new username. I'm wondering if that's still the case?

Edit: If this isn't possible, can there be some kind of indication at registration that changing usernames isn't possible?

Then @chronister said:

I think the main problem is that the unique identifier for an account remotely is the username. All remote instances might give alice@example.social different IDs but that string, alice@example.social, is how they identify alice as the same person.

If there's some mechanism in activitypub to effectively do a "redirect" or "symbolic link" of one handle to another this might be possible, but if not then it doesn't really seem feasible. Someone who's read the AP spec in detail might be able to give a more definitive answer here.

So, does anyone know for sure whether or not ActivityPub would allow for changing one's username?

See also #5647 - asking for a warning at registration that usernames can't be changed later on.

[nightpool]

@Cassolotl If it wasn't possible this wouldn't be an open ticket. It's just that this is a very tricky problem with lots of different issues to consider. See swicg/general#1 for more of the high-level protocol discussion in this area.

[nightpool]

@Cassolotl If it wasn't possible this wouldn't be an open ticket. It's just that this is a very tricky problem with lots of different issues to consider. See swicg/general#1 for more of the high-level protocol discussion in this area.

[Cassolotl]

@nightpool That makes sense! Thank you for the link, I'll go take a look.

[Cassolotl]

@nightpool That makes sense! Thank you for the link, I'll go take a look.

[kacealexander]

Speaking from a non-dev standpoint:

I'm a public persona, an author. I have an extremely vested interest in making sure that my identity is searchable, findable, and followable. So finding Mastodon was great! But after signing up at the default choice (there's a learning curve here, now that I signed up I know a lot more than I did), I realized there's no way to take myself and my followers to a new space.

Those of us fleeing from the harassment and abuse on Twitter are desperate for someplace safe, but at the same time, to be forced out of or have to switch instances after gathering followers will actively hurt our audiences and ourselves in what we do.

I would so, so so appreciate the ability to port over my identity from one server to another, including followers. This is what will keep us alive at Mastodon when (and there will no doubt be a when) we are forced to leave a defunct instance or an admin of our instance falls off the map and leaves it rife with abusers and trolls.

I appreciate Mastodon very much and want nothing but amazing success for it!

[kacealexander]

Speaking from a non-dev standpoint:

I'm a public persona, an author. I have an extremely vested interest in making sure that my identity is searchable, findable, and followable. So finding Mastodon was great! But after signing up at the default choice (there's a learning curve here, now that I signed up I know a lot more than I did), I realized there's no way to take myself and my followers to a new space.

Those of us fleeing from the harassment and abuse on Twitter are desperate for someplace safe, but at the same time, to be forced out of or have to switch instances after gathering followers will actively hurt our audiences and ourselves in what we do.

I would so, so so appreciate the ability to port over my identity from one server to another, including followers. This is what will keep us alive at Mastodon when (and there will no doubt be a when) we are forced to leave a defunct instance or an admin of our instance falls off the map and leaves it rife with abusers and trolls.

I appreciate Mastodon very much and want nothing but amazing success for it!

[nightpool]

Me and @Gargron and a couple other developers had a chat on Saturday, and we decided that this is currently the highest priority enhancement for us as a project. We hope to have at least partial fixes for this emerge soon, things that address some of these concerns, while we work to build full migrations into the system. It's a long task, with lots of moving parts, and we want to be sure we're going to get it right.

[nightpool]

Me and @Gargron and a couple other developers had a chat on Saturday, and we decided that this is currently the highest priority enhancement for us as a project. We hope to have at least partial fixes for this emerge soon, things that address some of these concerns, while we work to build full migrations into the system. It's a long task, with lots of moving parts, and we want to be sure we're going to get it right.

[RX14]

@nightpool I assume this is going to require coordination with the protocol guys to make this implementation-agnostic, or at least to make it possible to have implementation-agnostic migrations in the future.

[RX14]

@nightpool I assume this is going to require coordination with the protocol guys to make this implementation-agnostic, or at least to make it possible to have implementation-agnostic migrations in the future.

[cwebber]

Great to read that this is becoming a priority for Mastodon! I (and the SocialCG generally?) would really appreciate being kept in the loop on the route you're taking.

[cwebber]

Great to read that this is becoming a priority for Mastodon! I (and the SocialCG generally?) would really appreciate being kept in the loop on the route you're taking.

[kacealexander]

As a side but related note: is it at all (functionally rather than theoretically) possible to merge accounts created across instances? Some of us, uh, may have created a few in early days before we realized how it worked. Followers get confused fast, and the number of searchable usernames that pop up (deleted account or otherwise) is extra confusing. A merge would be awesome. Tho complicated, I'm sure.

[kacealexander]

As a side but related note: is it at all (functionally rather than theoretically) possible to merge accounts created across instances? Some of us, uh, may have created a few in early days before we realized how it worked. Followers get confused fast, and the number of searchable usernames that pop up (deleted account or otherwise) is extra confusing. A merge would be awesome. Tho complicated, I'm sure.

[coreyreichle]

I'm not exactly sure of the ins and outs of how Freenet's microblogging handles it, but it's a completely serverless architecture. I believe it's because the root FSK for the owner is used to sign the CHK (Content hash key), or something like that (It's been a while since I've played with freenet).

So, perhaps some lessons learned here for verifying identity of the author could be employed here?

[coreyreichle]

I'm not exactly sure of the ins and outs of how Freenet's microblogging handles it, but it's a completely serverless architecture. I believe it's because the root FSK for the owner is used to sign the CHK (Content hash key), or something like that (It's been a while since I've played with freenet).

So, perhaps some lessons learned here for verifying identity of the author could be employed here?

[bunnybooboo]

This feature has been implemented in 2.1.0 so this issue can now close. Wahoo!
cc/ @Gargron

[bunnybooboo]

This feature has been implemented in 2.1.0 so this issue can now close. Wahoo!
cc/ @Gargron

[trwnh]

@bunnybooboo Not fully. Read the comments on #5746.

"Please mind that this PR does not include the automatic followers unfollow/re-follow of new account, nor does it include a way to actually set this "move" information, yet. Therefore, it's only one step towards solving #177"

[trwnh]

@bunnybooboo Not fully. Read the comments on #5746.

"Please mind that this PR does not include the automatic followers unfollow/re-follow of new account, nor does it include a way to actually set this "move" information, yet. Therefore, it's only one step towards solving #177"

[trwnh]

Something that might be interesting or relevant: been reading more into alternative federated networks and trying to understand the history/development of Friendica/Hubzilla.

Hubzilla was split off from Friendica because of a desire to create a decentralized permissions system. Friendica, for the most part, is a social network that includes profile features like albums/calendars/etc, similar to Facebook. Hubzilla, on the other hand, is a permissions/ID system that happens to allow social networking.

This means that account migration is easily achievable using Hubzilla's concept of "nomadic identity": Your ID is referred to as a "channel" and takes the form handle@site.tld, similar to what OStatus / ActivityPub uses for its accounts. But the key difference is that your content is not tied to the DNS; accounts and channels are separate entities.

In effect: you can import a "channel" (identity) from site1.tld to site2.tld seamlessly, either by uploading an export of your data, or by entering your account credentials on another site. This has the benefit of allowing live migration, as well as ALSO syncing content back to the other connected accounts.

A brief situation is explained here: https://medium.com/@tamanning/nomadic-identity-brought-to-you-by-hubzilla-67eadce13c3b

In summary:

• Bob signs up at site1.tld, a "hub" run by one of his friends.
• Bob creates a personal channel bob@site1.tld and starts posting life updates.
• Bob's friend announces that site1.tld will be shutting down temporarily in a week, and will be unavailable for a few months. Bob wants to migrate to his personal server instead.
• Bob creates his own hub at site2.tld, and during account signup, he chooses to import the channel bob@site1.tld. Bob enters his credentials for site1.tld, and clones bob@site1.tld to bob@site2.tld seamlessly. Alternatively: Bob exports his channel bob@site1.tld to a file, which he uploads to site2.tld and his account there.
• Bob continues to make personal posts to bob@site2.tld, and those updates are sent back to site1.tld as well. When site1.tld goes offline, Bob can continue to post to bob@site2.tld uninterrupted. When site1.tld comes back online, it syncs all of the content from the downtime period.
• Bob might decide he doesn't want to use his site1.tld account anymore, so he can turn off syncing on site1.tld and delete his account there. Bob now lives at site2.tld, and publishes at bob@site2.tld. All of the channels that have previously connected with bob are, in actuality, transparently linked to the channel "bob", regardless of the domain name. All of the permissions remain intact.

Now, to be sure, this is perhaps not as simple or as elegant as simply migrating an account between two servers, but it also doesn't face the issue of breaking connections/followers, since all connections are stored in a JSON format and are linked to the channels themselves, not the accounts that own the channels. Additionally, it's completely transparent to every other channel that follows you, since they can comment or reply to your posts the same as before, and in fact, they can do this irrespective of domain name. In the example above, Bob posts to site2.tld, and the content is cloned across bob@site1.tld and bob@site2.tld with the zot protocol. Channels that comment on bob@site1.tld will show up to Bob on bob@site2.tld, and the same channel data is accessible through both DNS entries.

In terms of advantages and disadvantages: I think this is very useful in being resistant to service outages or DNS censorship. It also allows for complete identity portability, so you can move from one hub to another seamlessly. On the other hand, it might also encourage people to create accounts across many different hubs simply to clone the same channel, which isn't really necessary unless you want people to be able to access your content from multiple URLs.

What this could mean for Mastodon: accounts could be decoupled from their profiles, and profiles could be migratable across instances. Accounts could also manage multiple profiles. An analogy would be Tweetdeck allowing management of multiple Twitter profiles from the same account. I think there's some real potential here to take Hubzilla's work on this topic and make it more simple and accessible, less confusing. I'm not sure how it would best be implemented, but I hope explaining the metaphors here can lead to something useful coming out of it. For example, decoupling profiles from accounts could also help make progress towards #5515 or #380

[trwnh]

Something that might be interesting or relevant: been reading more into alternative federated networks and trying to understand the history/development of Friendica/Hubzilla.

Hubzilla was split off from Friendica because of a desire to create a decentralized permissions system. Friendica, for the most part, is a social network that includes profile features like albums/calendars/etc, similar to Facebook. Hubzilla, on the other hand, is a permissions/ID system that happens to allow social networking.

This means that account migration is easily achievable using Hubzilla's concept of "nomadic identity": Your ID is referred to as a "channel" and takes the form handle@site.tld, similar to what OStatus / ActivityPub uses for its accounts. But the key difference is that your content is not tied to the DNS; accounts and channels are separate entities.

In effect: you can import a "channel" (identity) from site1.tld to site2.tld seamlessly, either by uploading an export of your data, or by entering your account credentials on another site. This has the benefit of allowing live migration, as well as ALSO syncing content back to the other connected accounts.

A brief situation is explained here: https://medium.com/@tamanning/nomadic-identity-brought-to-you-by-hubzilla-67eadce13c3b

In summary:

• Bob signs up at site1.tld, a "hub" run by one of his friends.
• Bob creates a personal channel bob@site1.tld and starts posting life updates.
• Bob's friend announces that site1.tld will be shutting down temporarily in a week, and will be unavailable for a few months. Bob wants to migrate to his personal server instead.
• Bob creates his own hub at site2.tld, and during account signup, he chooses to import the channel bob@site1.tld. Bob enters his credentials for site1.tld, and clones bob@site1.tld to bob@site2.tld seamlessly. Alternatively: Bob exports his channel bob@site1.tld to a file, which he uploads to site2.tld and his account there.
• Bob continues to make personal posts to bob@site2.tld, and those updates are sent back to site1.tld as well. When site1.tld goes offline, Bob can continue to post to bob@site2.tld uninterrupted. When site1.tld comes back online, it syncs all of the content from the downtime period.
• Bob might decide he doesn't want to use his site1.tld account anymore, so he can turn off syncing on site1.tld and delete his account there. Bob now lives at site2.tld, and publishes at bob@site2.tld. All of the channels that have previously connected with bob are, in actuality, transparently linked to the channel "bob", regardless of the domain name. All of the permissions remain intact.

Now, to be sure, this is perhaps not as simple or as elegant as simply migrating an account between two servers, but it also doesn't face the issue of breaking connections/followers, since all connections are stored in a JSON format and are linked to the channels themselves, not the accounts that own the channels. Additionally, it's completely transparent to every other channel that follows you, since they can comment or reply to your posts the same as before, and in fact, they can do this irrespective of domain name. In the example above, Bob posts to site2.tld, and the content is cloned across bob@site1.tld and bob@site2.tld with the zot protocol. Channels that comment on bob@site1.tld will show up to Bob on bob@site2.tld, and the same channel data is accessible through both DNS entries.

In terms of advantages and disadvantages: I think this is very useful in being resistant to service outages or DNS censorship. It also allows for complete identity portability, so you can move from one hub to another seamlessly. On the other hand, it might also encourage people to create accounts across many different hubs simply to clone the same channel, which isn't really necessary unless you want people to be able to access your content from multiple URLs.

What this could mean for Mastodon: accounts could be decoupled from their profiles, and profiles could be migratable across instances. Accounts could also manage multiple profiles. An analogy would be Tweetdeck allowing management of multiple Twitter profiles from the same account. I think there's some real potential here to take Hubzilla's work on this topic and make it more simple and accessible, less confusing. I'm not sure how it would best be implemented, but I hope explaining the metaphors here can lead to something useful coming out of it. For example, decoupling profiles from accounts could also help make progress towards #5515 or #380

[moralwar221b]

I have one website. I used mastodon oauth service for my website and configure my website and it works properly. Now I want to migrate users of my website to mastodon server. Can anybody please tell me how can I do it or is there any alternative for it?????

[moralwar221b]

I have one website. I used mastodon oauth service for my website and configure my website and it works properly. Now I want to migrate users of my website to mastodon server. Can anybody please tell me how can I do it or is there any alternative for it?????

[ojbr]

I don't have time to look through the last 81 pages of messages (sorry), however I thought this would be worth a mention here.

What with the data loss on mastodon.rocks (RIP), and my own instance hitting an awkward Sidekiq memory leak in the v2.3.0 upgrade (discussed in the instance admin mailing list); I've basically been knocked off the Fediverse. Of course I can re-register/re-create instances - however, I do have an archive of my user data that I was able to obtain.

How much work would it take to migrate this data onto a new instance?
Is there an "import history" tool that exists? If not, would there be an interest in such a thing? I believe it might be a good idea, especially if one instance decides to go 'poof' overnight, that you'd still be able to recover your own personal data.

[ojbr]

I don't have time to look through the last 81 pages of messages (sorry), however I thought this would be worth a mention here.

What with the data loss on mastodon.rocks (RIP), and my own instance hitting an awkward Sidekiq memory leak in the v2.3.0 upgrade (discussed in the instance admin mailing list); I've basically been knocked off the Fediverse. Of course I can re-register/re-create instances - however, I do have an archive of my user data that I was able to obtain.

How much work would it take to migrate this data onto a new instance?
Is there an "import history" tool that exists? If not, would there be an interest in such a thing? I believe it might be a good idea, especially if one instance decides to go 'poof' overnight, that you'd still be able to recover your own personal data.

[Cassolotl]

Is there an "import history" tool that exists?

Not currently as part of vanilla Mastodon, but I do think there would be interest!

Edit: I thought there might be a specific issue for this, so I went looking, and found this: Import toots from CSV #981

[Cassolotl]

Is there an "import history" tool that exists?

Not currently as part of vanilla Mastodon, but I do think there would be interest!

Edit: I thought there might be a specific issue for this, so I went looking, and found this: Import toots from CSV #981