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

[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?

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

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

[hoodieak]

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

[hoodieak]

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.

[hoodieak]

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.

[0ln]

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 @[email protected] 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)

[0ln]

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.

[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]

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

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

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

[ddevault]

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.

[ddevault]

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.

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

[ddevault]

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.

[ddevault]

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" [e-mail] 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
https://github.com/tootsuite/mastodon/issues/177#issuecomment-291690605,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGCwJHPYajcxkpXohajzF5z9LASspUdks5rsuDxgaJpZM4K5Bba
.

[ddevault]

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.

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

[Shywim]

Creating an account on a new instance and verifying you're the same person
from the old account should be as easy as connecting to the old account
from the new instance like for remote follow. From this we could enable
having multiple accounts on differents instances (useful for privates
instances where we could easily show "Hey, I'm also over here!").

We have federated toots, why not have federated identities?

On Apr 5, 2017 14:34, "thomaslule" [e-mail] wrote:

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.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/177#issuecomment-291847514,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABgts9haxPHNN1usBxkQ61eKk7SLB8Svks5rs4pVgaJpZM4K5Bba
.

[ddevault]

Because it would be needlessly complicated.

[Shywim]

What's complicated in having the same process as doing a _remote follow_ and storing a list of identities you validated as being you in a given instance?

[ddevault]

Well, if that's all you want, then it's not that complicated and isn't relevant to this issue. What's complicated would be extending that solution to be relevant to this issue, by syncing them up or making sure followers match and so on.

[nocksock]

Just my 2 cents how it might be possible to solve some issues related to migration. Well it got a bit longer while writing, but bear with me.

For useable decentralization we need instance-independent usernames. So I had an idea, that's basically inspired by how the web in general works.

Let's assume we have an infrastructure that resolves unique usernames to user+instance. For example my unique-name is something like nocksock#<uniqueid>. The fictitious service then resolves it to [email protected]. Let's call it the Mastodon Name Resolver, MNR for now.

Those services would have to be decentralized of course too, and I should be able to define the services I trust in my instance. The MNR itself should trust others again and sync with those. That's basically how the web works, and it scaled quite well, didn't it?

So when I register at an instance I'd automatically get a unique name at the MNR that Mastodon Instance trusts. How those names could be generated, I'll explain later. The MNR could then sync with other MNR and so the newly created account gets announced across the mastodon network.

So name resolving could be as simple as GET my-trusted-mnr.com/nocksock#<unique-id> => [email protected] And if I moved from one instance to another, I'd just have to tell the MNR about that. This way, when I moved and the old instance shuts down, the mastodon network would still know where I am. This way we'd have an east way to address users independent of their instance without ever loosing track of them.

Also when I now switch instances my followers would not even notice, because their instance would just know, thanks to its trusted MNR, that I'm now at another instance and point to that instance instead, and get my updates from there.

What the end user needs to know: basically nothing. it just works. No spamming users, when I import my history or followings, because their instance could simply perform a check "oh I have this already, no need to to notify".

For the unique-usernames we'd have several ways to go.

In order to create unique names across the network we could give the MNR numbers/names/handles. And each MNR would then simply have to perform the check of uniqueness themselves and that number/name/handle will be part of that username for its lifetime; unless we'd introduce complete renaming which would also be possible with this infrastructure, but… let's keep it simple now.

Example:
The mastodon.social MNR has the handle odon and hence my unique username could be nocksock.odon

I'd prefer the handles cause that'd make way for creative uses and wordplays, hence making mastodon more attractive. And it's easier to remember. So people would never have to know on what instance I currently am, they can always address me using @nocksock.odon.

This would also be interesting for companies setting up their own MNR, so they could get @link.nintendo, or communities @alex.lgbqt etcpp. I'd just have to register on an instance that trusts that or one of those MNRs. Also an instance could trust several MNR and the user simply could choose their suffix.

And to verify ownership of a unique name, one could use gpg technologies, or email verification or other things.

[ddevault]

Your globally unique username is @yourname@yourinstance.

[nocksock]

But that wouldn't be instance-independent. Because, what if @yourinstance is shut down?

[ddevault]

Sucks to be you? This isn't a problem for email, for example.

[ddevault]

Hopefully your provider will notify you ahead of time and you can use the transfer mechanism to move elsewhere first.

[nocksock]

Yeah sure. That'll probably happen anyway.

Also… it IS a problem for e-mail that we've just grown accustomed to. And I was rather thinking of a long term solution that wouldn't break mentions/replies after moving to another instance whilst addressing some of the issues that had been mentioned here before and some ux-issues along the way.

[Sadzeih]

The thing is we're not dealing with email. We're dealing with a micro-blogging social network. So you'd prefer a instance-independant username/identity across the network.

Then you don't have the need for migration because people would follow an instance-independant identity instead of a instance-dependant account.

Also I get why you'd want to be compatible with OStatus/GNU Social but at some point if you want Mastodon to be it's own thing or do things better than OStatus/GNU Social you're going to have to seperate yourself.

[ddevault]

It wouldn't be a problem for email if there was a good automated way for email clients to inform each other that someone's email address has changed, which is what we're putting together here.

Remember this isn't one big network, either, it's a federation. I don't think you're going to get very far with the "we should ditch OSocial because I don't want to have to put @instance after my name" argument.

[Sadzeih]

It's not that I don't want to put @instance after my username. It's that I want to have a unique account that's independant from my instance in case my instance dies.

You have to think long term for this kind of thing. Especially for a project like this. If I invest a month on an instance and suddenly my account is gone with my toots & follows then I'd probably abandon totally. Also It'd be useful for "verifying" your identity to your followers (I bet personalities/companies would like that)

[ddevault]

I am thinking long term. I don't think it's a problem. If you're instance is run by the kind of person who just pulls the plug without any notice then you deserve what you get for trusting them with your account in the first place imo.

[davidbgk]

@Sadzeih you are describing custom domain name and self-hosting here. Did you do that for your emails?

[Sadzeih]

But do you think everyone is tech-savvy enough to self-host an instance?

We also have to think about the majority of people using Mastodon.

[agos]

@SirCmpwn "you deserve what you get" is not a great principle for good usability. The user shouldn't be punished for failing to anticipate their instance shutting down.

[ddevault]

At some point we need to draw the line at not solving everyone's problems all the time, because it's out of scope and not our responsibility. Requiring you to trust the operator of your instance is not a solvable problem.

[nocksock]

imho it should become as easy as possible to set up a custom instance. So easy that hosters will some day be able to have "one click installations". At that point it's not much different from creating a new discord server (from a user-perspective).

Thus, if "Requiring you to trust the operator of your instance is not a solvable problem" it should at least become a neglectable one.

I believe users are more likely to invest and try mastodon in the first place, when they get the feeling of being able to freely and effortlessly move their account from instance to instance without loosing their history, followers and followings (their achievements). Also wanting to move can have several reasons, of which a shutdown might even be the last one to happen.

Also: how should a user determine if an instance is trust-worthy when there are so and so many to choose from? Trusting the instance then just becomes a concern for the user that adds to the concern of trusting the network at all when there's (atm) practically no reason to do otherwise.

The least to do should be at least trying to think of ways to solve that problem and not to just not even try to solve it because it isn't a problem for a different thing. I'm not even saying my proposal is a good one, but at least we should think about how _instance-independent_ usernames could work.

[ddevault]

I completely agree that you should be able to move your account and bring your followers and such with you and I've been talking in this very thread about strategies for supporting this. That's a different matter from having a global identity (other than @user@instance), which is what I disagree with.

[cyphar]

@Sadzeih "Compatibility with OStatus/GNU Social isn't as important as reinventing how identities work" doesn't strike me as a good long-term solution. The whole benefit of federated networks is that you aren't locked into a single implementation or instance of a piece of software. The reason someone chooses Mastodon/OStatus/GNU Social over $random_protocol_Y is that they know that the community will make sure that improvements to the system will apply to all users (and you won't be left behind when cool new services are added to the federated cluster). As a user, if I saw a project like Mastodon decide "hey, we don't need to bother with remaining in agreement with a standard" I would consider moving to a less immature project (because now I'd be locked in the Mastodon silo, and it'ts unlikely that other implementations will do work to keep up with Mastodon over OStatus).

All of this being said, I really wish that people (including myself) would stop throwing in $strong_opinions on a topic which is quite nuanced and trying to steer the direction of the project as a result. The only person who's commented recently and has actually written any code for Mastodon is @SirCmpwn (and he only started contributing a day ago). My point with this sentiment is not "only programmers can contribute" it's that I generally find that random people on the internet just dropping their opinons in a GitHub issue doesn't really help anyone -- how about we all wait to see how things evolve and then comment once there's actually a proposal or implementation?

As for my opinon on global identities -- IMO the reason why OStatus (well, WebFinger) doesn't implement global identities is probably because global identities are usually not something you want. Matrix has "global identities" and it's probably the only major contention I've heard people have with the system (it's the only not-truly distributed part of their system, and it effectively starts blurring distinctions between different users and different identities). But as I said before, what the hell do I know, I've never worked on an OStatus implementation.

[nocksock]

Okay then. Let me try it from a different angle with a few questions:

Let's assume I am following @famousPerson@instanceA and they are moving their account to @famousPerson@instanceOfCompany and I am @notFamous@instanceC. Would I have to take notice of that change and address them with their full address now? What happens with old posts of @famousPerson@instanceA or rather old mentions of @famousPerson@instanceA. If I just joined instanceA because of @famousPerson will I "know" that they're not on that instance? How can I trust that @famousPerson@instanceOfCompany is legit?

[ddevault]

Have you even read the thread? The entire purpose of this thread is the discussion of that exact problem. Solutions have been proposed. Solutions are being worked on.

[0ln]

The MNR thing idea isn't bad but it's like creating an identities decentralized blockchain like cryptocurrencies do. That would be really hard to set up and probably plenty of bugs. Plus, a lot of people have already created multiple accounts with the same username on different instances. How to manage them? If someone modify the Mastodon code and try to screw up all the identities blockchain, what happens?
@Sadzeih is right. The biggest problem of Mastodon right now is this account loss possibility because of the decentralization. Instance hosts aren't always reliable. If an instance shuts down suddenly, all the accounts of the people registered on it will be lost. Those people will probably go back on Twitter (nobody wants that) and they won't come back on Mastodon. In the same way, people who chose an instance too fast and want to change might be discouraged because they'll have to start over a new account and lose all their activity. Even if they say "hey I'm moving follow me at @mynewaccount" they can be sure they'll lose a lot of followers. Thus there is balancing problems between the instances.
IMO, the unique ID system is too complex for Mastodon and the account migration system is the right thing to do. I know Mastodon is new and there's still a lot of things to do and a lot of bugs to fix but I think account migration is one of the most important feature to add and is the solution for all the issues I mentioned above.

[cyphar]

@bokopi

In the same way, people who chose an instance too fast and want to change might be discouraged because they'll have to start over a new account and lose all their activity. Even if they say "hey I'm moving follow me at @mynewaccount" they can be sure they'll lose a lot of followers. Thus there is balancing problems between the instances.

This is the problem being discussed, and as @SirCmpwn said some solutions have been discussed and are being developed. Did you read the whole thread? There were at least two different solutions discussed that solve this problem and don't require having global identities.

[davidmanheim]

There seem to be two independent issues, the first of which is easy, but has security problems, the other of which is only partially possible, but is simpler. (Most of this was pointed out by @hoodiek )

1) How can a user move, associating their new address with the old one?

• Several solutions were proposed. Most are a simple export + redirect tag,
  -There are critical security issues that should be considered - can a server hijack the followers of its users? Can an account compromise be used to do so? (I suspect most of the answer are going to be about human factors, not protocol security.)

2) How can their followers be transferred.

• Since this is a federated system, there is no way to force other users to change behavior. Mirroring indefinitely is possible, but non-ideal.
• Mastodon can relatively easily have an (opt-out automatic) change of who is followed when they see a user who has moved.
• If implemented, other OStatus services could follow suit, and the standard could be updated. This is more likely if the protocol is simple and opt-in.
• The long-term solution is to get the (mostly defunct) OStatus working group to reconstitute, and to approve whatever protocol extension is used: https://www.w3.org/community/ostatus/

[0ln]

@cyphar Yes this is a summary of the problem since it seems to be unclear of some people.

[ddevault]

Toot export: https://github.com/tootsuite/mastodon/pull/978

Splitting toot import into a separate GitHub issue https://github.com/tootsuite/mastodon/issues/981

[rpavlik]

Perhaps I'm just another of the unwashed masses, but a not entirely unrelated problem is handles associated with a role as well as a person: the specific case study I'm thinking of is the way Twitter (mis) handled the POTUS handover.

[kevinmarks]

For the followers to keep being updated, they need the pubsubhubbub flow to
continue. As part of that protocol, they re-subscribe to the endpoint every
24 hours or so. So that seems the natural way to migrate them, by changing
the topic url

On 5 Apr 2017 5:40 pm, "David Manheim" [e-mail] wrote:

There seem to be two independent issues, the first of which is easy, but
has security problems, the other of which is only partially possible, but
is simpler. (Most of this was pointed out by @hoodiek
https://github.com/hoodiek )

1. How can a user move, associating their new address with the old one?

2. Several solutions were proposed. Most are a simple export + redirect
   tag,
   -There are critical security issues that should be considered - can a
   server hijack the followers of its users? Can an account compromise be used
   to do so? (I suspect most of the answer are going to be about human
   factors, not protocol security.)

3. How can their followers be transferred.

4. Since this is a federated system, there is no way to force other
   users to change behavior. Mirroring indefinitely is possible, but non-ideal.

5. Mastodon can relatively easily have an (opt-out automatic) change of
   who is followed when they see a user who has moved.
6. If implemented, other OStatus services could follow suit, and the
   standard could be updated. This is more likely if the protocol is simple
   and opt-in.
7. The long-term solution is to get the (mostly defunct) OStatus
   working group to reconstitute, and to approve whatever protocol extension
   is used: https://www.w3.org/community/ostatus/

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/177#issuecomment-291921280,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGCwP1inzWkIaTcNlkvQMhChHVjpa-7ks5rs8PygaJpZM4K5Bba
.

[sequitur]

Three things:

1. Trying to figure out a general solution to the problem of persistent, host-independent identities for people seems very out of scope and also really, really difficult and complicated. This isn't to say it's not worth solving, but it's not necessarily good to prioritize it at the expense of solutions that work for more common use cases and are less drastic.

2. I think mirroring/redirecting has a major problem in that it doesn't solve the use case of an instance shutting down. It also has another unpleasant case where, say I decide the rules/community on instance A aren't for me and migrate to instance B; under a redirect system, instance A's admin could decide to ban my redirect account, and sever the connection to my existing followers. Redirects, depending on how they're implemented, also create additional load for servers, which seems to defeat the purpose of people migrating to balance the load.

3. I really like @SirCmpwn's suggestion of using a pair of special toots to signal a change and letting clients handle the logistics of it; that seems to make the most sense to me.
   3a. The best client behavior in my opinion isn't to hide the special account migration changes, but to show them on the follower timeline; it's good for users to be aware that someone has switched instances. So you would see an item on the timeline saying "[email protected] has migrated to [email protected]", next to a "follow" button that is pressed by default. This would mean that people would be aware of it going on and could for instance choose not to follow bob into nazi-freespeech.zone or shady-spammer.website.
   3b. I don't think there's a total solution to the problem of people hijacking stolen accounts by migrating them, but a possible solution is for clients to not unfollow the old account by default, and to allow for a "wait, no, I take it back" toot as another special migration toot.

[tomitm]

With the amount of people that have an @gmail.com email address, this problem doesn't seem like it needs to be solved as described in most comments here. This seems like more of an early adopter problem of people wanting to jump around instances easily and possibly missing the point.

Suppose you're moving to a new email address. You tell everyone to update their address book and/or setup a forwarding rule, but how often do people actually change email addresses? They might maintain multiple, or abandon a secondary one (work, etc), but I don't know anyone that regularly changes their primary email. If you have a custom domain email, you might change your email server, though.

If you're really concerned about having a global identity not tied to a single instance, #1032 about subdomains and MX records in emails might interest you. If we change how domains are resolved, this could be useful for domain aliasing.

---

Solution: buy your own domain name, point your MX-equivalent DNS record* to your preferred instance, then register the domain as an alias on that instance so that you can register [email protected].

Later, if you want to move instances for whatever reason, you can repeat the DNS/alias process on another server, and migrate your toots/following list over. Everyone still follows you and addresses you correctly without needing an explicit _hey I moved instances_ notice.

*edit: I didn't originally realise WebFinger was in use here. It might be possible to setup an alias via WebFinger (instead of DNS) to point to the correct instance instead?

[thomaslule]

Unlike email providers, instances have different moderation rules, anti-harassment policies, they will gather different communities, some will choose not to federate with other instance that they consider harmful... the instance choice is a lot less neutral than an email provider choice.

As a result, I think that people will definitly need to move to other instances a lot more often than they need to change their email provider.

[emf]

The email comparison is disingenuous, for a few reasons:

1) email is an archaic technology from a time when instances were extremely expensive and not common. You were not really expected to move. This has not entirely proved true in the modern era.

2) email has worked around this problem for decades by being able to modify the "From" and "Reply-To" headers in ways that nearly every client application respects. email servers nearly universally support forwarding while they continue to function. These things reduce the friction of migrating from one service provider to another. (That they also add forgery issues is another topic entirely, but one I expect Mastodon will need to tackle soon as well.)

3) Perhaps most importantly, email is fundamentally a receiving technology, not a sending one. The nearest email analogue to a microblogging account is a mailing list; and when one migrates a mailing list, the mailing list administrator already has the full recipient list available.

[sequitur]

Also, excepting spammers and mailing lists, people who wanna send me email usually have a big enough stake in me getting that email that they WOULD manually update their address list. If you switch Mastodon instances, I think for people with significant (>100) numbers of followers, most followers would not manually switch, especially if they don't even see your toot announcing the switch, which is very likely if they follow large numbers of people. So switching instances by hand has a huge degree of friction to it and that friction will only get bigger as the service matures and follower/following lists get longer.

[tomitm]

@thomaslule Alright, I see your point, that's entirely true. I'm still don't think it going to happen very frequently, but frequently enough that it needs to be addressed nicely.

@emf @sequitur I don't think the email comparison is entirely perfect, but there's still some similarities in routing/addressing aspects that could be useful to learn from and adapt. Just because it's archaic tech, at least it's managed to stick around, which Mastodon may or may not at this point.

The solution I suggested relies on aliasing an address to an instance in a way that's transparent to senders. It doesn't rely on setting anything client-side, like fiddling with From and Reply-To - this happens on the server side.

Granted, the solution works better with custom domains, however it might still work with a shared domain like mastodon.social which could include an alias in WebFinger to point to your new instance - but there's also trust/security/abuse aspects that would need to be addressed there. @you@oldinstance would point to @you@newinstance, and either would be valid.

[sangdrax8]

It has been said before, but I'll say I agree. This is critical to the idea of a decentralized social platform. Even admin's can change, and users need to be able to adapt to this change by moving to other servers they do still trust. I might decided to run my own server if I don't trust the current one. As it stands now it just becomes to difficult to migrate.

[mmcfee]

I've been thinking on this, especially as regards name-staking. but aliasing fits in as well. A potential solution would be a Mastodon DNS system for names and their canonical instance. A name would be an A record. Aliases/redirects would be the equivalent of a CNAME on that A record.

myusername A [email protected]
[email protected] CNAME [email protected]

When new users sign up, check MasDNS for uniqueness.
Direct replies to old names via MasDNS lookup

The only real issue is who controls the root zone list. But replication can be distributed to/by instances (who'd own their own zone) just like DNS.

[tomitm]

Quick look at the WebFinger spec shows that the subject field supports migration:

   The "subject" value returned by a WebFinger resource MAY differ from
   the value of the "resource" parameter used in the client's request.
   This might happen, for example, when the subject's identity changes
   (e.g., a user moves his or her account to another service) or when
   the resource prefers to express URIs in canonical form.

Meaning a request to https://mastodon.social/.well-known/webfinger?resource=acct:[email protected] normally returns

<Subject>acct:[email protected]</Subject>

but it can support migrations by returning the following instead:

<Subject>acct:username@otherinstance</Subject>

[actuallyrizzn]

Not to overcomplicate things @mmcfee, but I find NameCoin to be an elegant approach to an unowned / shared ownership DNS root system. In this instance, it could be like trying to hammer in a tack with a 75 pound sledgehammer.

[tobascodagama]

It seems to me that about 75% of the migration problem can be solved with a workflow like this that currently can be achieved with no modifications to the code:

• On the leaving site, add a link from my profile to the new one and make a toot announcing the move.
• On the leaving site, export follow/block lists.
• On the joining site, import follow/block lists.

The outstanding issues that constitute the remaining 25% would then be:

• What happens to my old toots?
• What if someone misses my move announcement and assumes I've just dropped off the earth?

Issue #201 addresses half of the first point, when it finally gets implemented. So let's rewrite the list of open issues:

• Should I be allowed to import an exported toot archive to a new account?
• If so, do those appear as new toots, or do they rewrite my history on the new account?
• Should there instead be an external (opt-in) service that provides toot archiving for those who want it?
• What if someone misses my move announcement and assumes I've just dropped off the earth?

I don't have a strong opinion on the first three points. Though I'm slightly inclined to say that important old toots has more bad edge cases than the convenience would be worth.

For the fourth point, perhaps it's something that could pop up in Notification feeds or trigger an e-mail alert. To support this, Mastodon would add an "I'm moving" button to user profiles that will then push a move notice to your followers.

Linking accounts across multiple instances is something I see as an orthogonal problem to account migration. Linked identities would simplify the question of whether to trust a new account that you find, but I think you'd still have the notification problem if a user decides to "retire" an existing account on a given instance.

[mmcfee]

I was assuming Mastodon could build its own system that follows a DNS-like model rather than use actual DNS. But NameCoin certainly looks like a possibility.

To @tomitm 's reply, Aye. That certainly would help for instances that are alive, but once they're taken down, that information will need to be stored and retrieved from somewhere else.

Perhaps also a mechanism that, when an instance is planning to shut down, the users could generate and send a token to the instance of their choice which would then become, once they log in with their token, their instance of record and they could migrate directly.

Just spit-balling here. :)

[JPLeBreton]

For the fourth point, perhaps it's something that could pop up in Notification feeds or trigger an e-mail alert. To support this, Mastodon would add an "I'm moving" button to user profiles that will then push a move notice to your followers.

@tobascodagama I feel pretty strongly that following an existing follow's migrated account shouldn't require any action on the follower's part. Notifications can be missed almost as easily as "Hey, I'm moving" toots, and it being on a pre-migration profile (which will appear to have simply gone silent) hardly helps. In any generic case are there any reasons I wouldn't want to auto-follow a friend's migrated account?

It's another jagged crack to lose followers to and while I personally appreciate Mastodon's de-emphasis of follower counts, it's a huge potential pain point for twitter escapees.

[mmcfee]

@tobascodagama Yeah, the whole 'how to migrate all my old toots' part seems to be the biggest known unknown here and a lot will depend on how that's handled.

Also, Hi! :)

[cyphar]

Migrating old toots isn't the biggest problem IMO. Federation means you won't lose the old tweets (in normal usage, though if the instance goes down that's a separate issue). The biggest issue is losing followers.

Global identities aren't necessary to fix this problem, you just need to have the equivalent of 301 redirects (or even just having a <ref> that says "this other account is the same as me" -- which I think OStatus already has). Actually, on the <ref> idea we just need to make it so that when you "follow" an account on Mastodon, Mastodon will also remote follow all of the other counts. When more accounts are added to that list, Mastodon will then remote follow the newly added accounts.

Obviously such a system needs some user confirmation or settings knobs, but the underlying implementations seems quite simple to me. I'll say again, global identities are not the only solution to the follower problem.

[tobascodagama]

@JPLeBreton I feel just as strongly the other way. :P

I agree with @thomaslule's and @sequitur's assertions that differing levels of moderation and content policies mean that I may not actually _want_ to follow someone after they move instances, unlike other systems such as email where I'm more interested in the ability to communicate with a specific person than with where they're hosting themselves. I might be concerned about, for instance, a former mutual follow who starts boosting my posts, which then appear on the local timeline of lazymods.social, which (hypothetically) is an instance of mostly-decent people but that has a small enclave of harassers on it due to lax policy enforcement.

Granted, the above scenario is mostly important if the permission system got a "mutuals only" or "only people I follow" feature, but it seems inevitable that Mastodon will some day have such a thing. So an account migration system should be designed around the requirement that followers must explicitly consent to following the new account, before the abuse cases become possible.

[JPLeBreton]

@tobascodagama That's fair, I agree it's worth doing things differently if there's even a small chance a user's consent is betrayed.

My concern would probably be allayed if the "this person you follow moved instances, do you want to follow them on the new instance?" notification were not part of the normal notifications stream. Its visibility should be comparable to follow requests for a private account.

As peoples' follower counts get into the 100s and 1000s we have to assume the notifications stream is a firehose where you can't assume any given item has been seen.

[rensa]

@JPLeBreton @tobascodagama I'd have thought that if you get the implementation of account migration right, the choice of whether migrated accounts get auto-followed by existing followers would be a UI problem.

The simplest design, apart from forcing auto-follow one way or the other, is a checkbox in my user settings. Maybe I get a notification of the migration either way, but I get to choose whether following the migrated account is opt-in (notification has a follow button) or opt-out (notification has an undo button). As @JPLeBreton notes, this notification might not be a 'normal' notification, but another column/list that I can review periodically.

A more complex iteration on this might be whitelisting or blacklisting the instances I want to follow a user on. For example, 'Only auto-follow users who migrate to these instances' or 'Only auto-follow users who migrate to instances other than these'. Still more complex would be instance black- or white- lists.

[pfoo]

@tobascodagama you are assuming that when someone switch from an instance to another he is going to change the quality of his toots ... why would he ? quite strange to me. I mean, it might happens due to moderation and stuff, but this should be marginal (you can still unfollow someone if you change your mind on the importance on the things he is tooting about). I'm seeing some instance that have dedicated topics (arts, IT, ...), this is great for the local timeline, maybe even for the federated timeline, but if I'm following someone who is on a generic instance and decide to switch to an art dedicated instance, why would I want to stop following him ? The only reason for unfollowing him will be if he changes what he is tooting about drastically. And this takes some time before you can figure this out. I'm really not in the mood of reviewing an account every time someone I'm following decide to change from an instance to another. If he starts to say things I don't like, I'm going to see it in my timeline and I will simply unfollow him at this moment. Not because he switched instance, but because I realised I don't want to read him anymore.

@JPLeBreton "this person you follow moved instances, do you want to follow them on the new instance?" > this is going to refrain people from moving between instances. You are on a social network, a lot of peoples are considering the number of followers as an important thing, and with this behaviour you are going to lose followers during the migration process. Migration needs to be completely painless for both users (followings and followers).

I think it might be better to have a simplier default behaviour : automatically follow the new account, notify of the change, let people decide by themself.

[sequitur]

I think the simple, best way to do it is to automatically follow the new account but have a notification with an "undo" or "no thanks" button.

Having that notification, and the button, is a matter of the UX' contract with the user; we're automatically changing their configurations (their follow list) because we assume that that's what they want, and it's probably correct to do it the vast majority of the time, but we want users to be aware of what is going on and able to quickly say "actually, your assumption is wrong" back at the system. I think as a default, users should follow accounts that moved, but the opt-out is mostly important to make that UX respectful of the user.

Besides that, I can definitely think of cases where I would not want to follow someone on a new instance:

1. My buddy Chad used the same password for his mastodon.social account that he used on his favorite porn site, and said porn site got hacked, so his mastodon.social account was harvested. I probably don't want to follow Chad's account to sygerianscammers.space.
2. My buddy Chad's account got broken into by some puckish rogue, and now I am being spammed with notifications that Chad's account keeps moving between horse.dentist and paranormal.lawyer every few seconds. I slam that undo button to halt the cycle.
3. My buddy Chad is signalling that he is changing instances to change his behavior: Maybe he wants to openly post NSFW stuff, maybe he wants to make more forceful use of his free speech, maybe he wants to share links to pirated movies. Either way, I don't want any of Chad's toots from freespeech.zone to reach my timeline.
4. It's the far future, several major revisions to OStatus and Mastodon in the future. Some sort of privacy feature based on mutuals has been implemented, but my buddy Cyborg Chad is moving to an instance that doesn't respect this feature. I decide to not follow Chad there because I don't want him to propagate my toots to online.harassment.website.

[wilkie]

We've always needed a standard for identity migration because domains are a fragile identity system. Particularly in a world where it is more and more obvious people don't want to set up their own domain for their own identity.

To do distributed identity migration you need:

• proof that you own the original account (accounts on mastodon and other OStatus sites should already have a private key because that's how the Salmon protocol works)
• a list of current identities that subscribe to your feed (your followers in this case, who should already have your public key?)

Then you need to update those subscribers by sending a notification. Probably a profile-update style notification that is signed by your original key. There is no standard that I'm aware of, or even an emerging one, about how this is done. Frustrating because it is a long discussed thing in the federated space. Need an exemplar implementation.

This requires:

• all instances to remember public keys of off-site identities (they should)
• ability to export your identity (which you can do as a backup precaution if your identifying site (your current mastodon instance) is destroyed) or have the original site send the signed notification for you (signing a new public key with the old private key and sending from the original server is a pretty reasonable practice, when possible).
• ability to export your followers list (so you know who to tell)
• then, the ability to import your identity/followers-list (when the original site won't/can't do it for you)
• ability to send a signed notification... which will have those people resubscribe to your new "topic url" or react in their personal choice

Technical Weirdness:

• (this is hidden from people and used internally) you should probably keep your original author "id" in the OStatus sense this will tie your stuff together?
• How to bridge old and new identities with respect to UI/UX. Ideally it should look like nothing has ever changed and require little/no input from a person's existing "followers", but also optionally allow notifying folks when a person suddenly jumps to somewhere else you may not want to federate with. (particularly tricky when they move to a site/domain you have banned)

[krainboltgreene]

@wilkie Can keybase.io hit all the points you describe?

[wilkie]

@krainboltgreene you mean PGP? I guess you could somehow import an external PGP public key as part of your identity, propagate that as part of your OStatus profile / xrd ahead of time, and have other nodes respect a notification signed by either that key or your normal OStatus key. Not sure off-hand how Salmon will work with a PGP key! keybase.io gives an "easy" entrypoint to that, but the solution should be more general.

In the end, though, I think you need some solution that works with the existing keys and doesn't require an external service/protocol. Or make everything PGP and somehow push the other section of federation to comply. Makes sense for cross-site DMs.

[sequitur]

I think that's overcomplicating things; I don't see why using keys as proof of identity is at all necessary. The two accounts can just reference one another, and that by itself is verification that they're under the control of the same person.

1. User wants to migrate from @[email protected] to @[email protected]
2. User logs on to @[email protected] and flips a setting saying they're preparing to migrate from @[email protected]
3. @[email protected] puts out a special toot that says "I'm migrating from @[email protected]"; most clients would just hide this toot.
4. User logs on to roddenberry.zone and pushes the button on migrating to @abrams.website
5. roddenberry.zone sends abrams.website a request saying "@bob, on my server, wants to migrate to @robby on yours, is that true?"
6. abrams.website says "@robby on my server says he is migrating from @bob on yours"
7. @[email protected] puts out a special toot that says "I'm migrating to @[email protected]"
8. Clients see that toot, check that its counterpart exists in the toot history of @[email protected], and automatically follow the new account.

Optional extra steps:

1. Users that see the migration toot see a special notification, rather than a regular toot, and are given the choice to opt out.
2. Clients don't unfollow the "old" account for some period of time (24? 48 hours?). At that point, they verify that both origin and destination "migration toots" still exist; otherwise, they unfollow the new account. That means you can cancel a migration by deleting the special migration toot. Thus if an account is stolen, users can reset their password and prevent account migrations from happening.
3. roddenberry.zone exports bob's follow list and sends it along to abrams.website, which imports it.

[wilkie]

"I don't see why using keys as proof of identity is at all necessary."

I mentioned this: In case the original instance goes down or bans you, you'll need an external way of identifying yourself. A way for a secondary site to say "Yes, this is indeed this person you already know from that other site. I speak for them, now." Therefore, a key the other nodes already know or can discover. If you have to do this in one case, you should just always sign them. (You can also, if you don't have your key, send a similar notification signed with your new key, which people can elect to trust manually since it won't verify) This is an aside, I think, but you don't want the node to own your identity... so that's where people might push an external PGP key as an override.

It's true, though, you could add the notification in the normal, public feed. (yet, another use-case is hiding where you are from, where all of your posts are encrypted (private accounts)... again, you're always using your key) but generally messages like this should at least be signed notifications. Otherwise you have to trust the hubs (intermediate pub/sub servers) that propagate your statuses that they don't slip those in (feed contents aren't signed.) If they can, they can subvert your identity. You could have nodes verify your post by following the url to its source, and then following another url to the new node and scanning for a post there, reasonably relying on TLS, but... why not just sign a single notification??? you can have your new node give a signed code you put into the first node and then you just send one. That's the "easy" method:

1. User wants to migrate from @[email protected] to @[email protected]
2. User goes to abrams.website and has it give it a "migration key" (internally signed by @robby)
3. User goes to (original node) roddenberry.zone and presses "Migrate Account" and pastes in the key.
4. roddenberry.zone sends a signed notification to subscribers of @bob
5. Each subscriber sees the signed notification and verifies it is @bob, and discovers @[email protected], verifying that the key in the notification has been signed there by @robby
6. Each subscriber, once they verify, can elect to unsubscribe from @bob and subscribe to @robby

If roddenberry.zone disappears, you'll have to do something else. Assuming you have the roddenberry.zone "migration key" and followers-list already backed-up, in case of the worst:

1. User backed up migration data from roddenberry.zone consistening of a "migration key" and followers list.
2. User wants to migrate from defunct @[email protected] to @[email protected]
3. User goes to abrams.website and gives it the "migration key" from roddenberry.zone and the followers-list
4. abrams.website sends a signed notification to those on the list
5. Each subscriber sees the signed notification and verifies the "migration key" using a public key they already have on file
6. Each subscriber, once they verify, can elect to unsubscribe from @bob and subscribe to @robby

If the migration key doesn't verify (or you don't have one, thus send a blank one), people will get notified and have to judge whether or not to trust the new identity. I think people and nodes should generally ignore this case. You just have to start over.

PGP could be a reasonable override... so you could sign a "migration key" with PGP or using keybase.io and use that. Who knows what that looks like.

Fortunately, sending notifications when this "easy" method isn't possible is ultimately not "complicated" since all OStatus nodes already have code to handle signed notifications from random places. Any content that is sent to you by a random person your node doesn't already trust is signed and verified via "Salmon" so stands to reason migration notifications could just be one of those. ymmv.

[wilkie]

You're correct that there should be a propagation delay for migrations. The solution there is: You just don't immediately send the migration notification from the original node. Have it pending for a couple of days or a week. Most people who are trying to act in good faith will get annoyed at this.

If you're using an unexpired external key from PGP ala keybase.io etc that was already long established, you can probably trust the notification much more and migrate immediately. Depends on your security model.

[sequitur]

The thing is though, users being banned or instances going down suddenly are a small fraction of use cases and trying to accommodate them makes account migration in general a lot more complicated. Particularly because it's perfectly possible to change things so that banned users can still migrate their account (and thus send out migration toots) even if they can't do anything else. The system doesn't have to be 100% proof against users being SOL due to a server vanishing or a ban, though, to be useful.

If people are required to generate PGP keypairs to migrate accounts, that's miles and miles beyond the threshold of what a typical most users would be willing to do, but if it's just a matter of the instances generating and using keys to verify things, that's more palatable for users. Overall, I think that a lot of people seem to want Mastodon to function as a general-purpose, distributed, permanent, verifiable source of identity and that strikes me as wanting to throw a really hard problem on top of the existing hard problem of making a distributed social network that is usable.

The problem of people being able to verify that accounts A and B are the same person, when A is inaccessible because the server went down or nuked the account, would be easily solved just by having Keybase verification for Mastodon accounts, so continuity comes from the fact that A, back when it was verifiable, was the same as Z (some other kind of keybase verification, like a twitter account or a web domain), and now Z is the same as B. Obviously what Keybase does is outside the scope of this project, though.

[wilkie]

PGP is optional to allow identity external to the instance. nobody has to generate their own keys. federated accounts already communicate out-of-band via signing using keys. no new crypto code necessary.

[semarie]

Shouldn't webfinger enough to do most of the migration process ?

for example: I am userA on systemA, and want to move to userB on systemB. I set an option on systemA telling I want that advertise userA@systemA has moved to userB@systemB.

At webfinger level, https://systemA/.well-known/webfinger?resource=acct:userA@systemA would reply with HTTP 301 and a HTTP header Location to https://systemB/.well-known/webfinger?resource=acct:userB@systemB (the exact address should be taken from LRDD, see Web Host Metadata).

• Any user that search for userA@systemA will get authoritative reply (from systemA) with data for userB@systemB.
• At pubsub protocol level, as a subscriber renews periodically its subscription (if I correctly understand the spec), it will hit the webfinger redirection too, and subscription will move too.

Note that I am unsure if it would cover all aspects of subscription or following. In particular it doesn't deal with content. Old content will be still accessible on systemA (but it could be considered as another problem).

[wilkie]

Webfinger is for profile discovery. Nobody will use Webfinger when they already subscribe. So you still have to notify people that the migration has happened. You might as well tell them in that notification where you currently are.

True, you could have an XRD/JRD point to the new node from your old identity. I don't believe it will hit the lrdd when it resubscribes. It uses a "topic url" which is the Atom feed, which it doesn't need to lookup to resubscribe. There are other methods of discovery... things don't even need to use Webfinger to discover a Person... they can use rel="profile" and http headers on urls. PuSH resubscriptions also don't happen as often as you might think. Months might pass. Leases aren't even a requirement in PuSH (even I mostly ignored them in rstatus). You basically can't rely on this as a migration path.

Personally, cross-domain redirects for .well-known is weird. I don't hate them, there's nothing really wrong with them, they are just weird. You also don't necessarily know how the base xrd/jrd url template will look on another system, either.

[wilkie]

I think if you update the XRD/JRD, the profile should just point to the new instance naturally instead of a redirect. I like that. Your old identity would then resolve to the new node, which is neat. Would certainly stress any OStatus implementations that assume the webfinger host points to the same domain for the profile. heh.

[kevinmarks]

The logical thing to 301 is the user's URL so systema.com/@usera 301s to
systemb.club/@userb (and the atom feed, obviously). This does rely on the
site being migrated from to co-operate, yes, but ti is less fiddly than
requiring a new webfinger call.

Also, the WebSub/ PubSubHubbub hub can tell the subscribers the new topic
url by changing the rel-self when they renew their subscriptions.

On Sun, Apr 9, 2017 at 8:23 AM, wilkie [e-mail] wrote:

Webfinger is for profile discovery. Nobody will use Webfinger when they
already subscribe. So you still have to notify people that the migration
has happened. You might as well tell them in that notification where you
currently are.

True, you could have an XRD/JRD point to the new node from your old
identity. I don't believe it will hit the lrdd when it resubscribes. It
uses a "topic url" which is the Atom feed, which it doesn't need to lookup
to resubscribe. There are other methods of discovery... things don't even
need to use Webfinger to discover a Person... they can use rel="profile"
and http headers on urls. PuSH resubscriptions also don't happen as often
as you might think. Months might pass. Leases aren't even a requirement in
PuSH (even I mostly ignored them in rstatus). You basically can't rely on
this as a migration path.

Personally, cross-domain redirects for .well-known is weird. I don't hate
them, there's nothing really wrong with them, they are just weird. You also
don't necessarily know how the base xrd/jrd url template will look on
another system, either.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/177#issuecomment-292769372,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGCwEEzDmEd2dmvmwisQF0Je6Iki04nks5ruIddgaJpZM4K5Bba
.

[kevinmarks]

From WebSub/PubSubHubbub notes on migration: https://github.com/pubsubhubbub/PubSubHubbub/wiki/Moving-Feeds-or-changing-Hubs

[mlncn]

Bit of a tangent, sorry, but how about migrating from GNU Social to Mastadon? I get invalid e-mail when trying to sign up and 'not found' when trying to send password reset e-mail. Could that happen because of an account on GNU Social? Or an account on any other Mastadon provider?

[wilkie]

The PuSH/WebSub migration path noted above is the appropriate first-step. It's a very clean and standardized solution. (I wonder if anybody can find fault in it, other than the trust issue) It works well for what most people want migration for at the moment (let's be honest :) it's to get a cool domain name.)

Still, people concerned about how to migrate when the admin of your node is a bad actor might be a problem, but as @kevinmarks noted in an external conversation, that might be its own separate issue. That will require some true innovation.

[BjarniRunar]

Note that there is a special case where migration should become super easy: when the user owns their domain name and uses that directly instead of the Instance name. So [email protected] is their OStatus handle, and social.usersdomain.com is a CNAME pointing to whatever Mastodon instance they're using this week.

This could be encouraged/supported in various ways and #1211 would be a start.

Giving away subdomains (user.mastodomains.com) and providing tools with which to manage them would also lower the barrier to entry. Providing a long-lived DNS service which resolves queries to the right Mastodon instance is a much smaller commitment/engineering effort than actually running a full instance.

[cyplo]

Hey ! just my 2 cents here: it is a very real problem, I have an example from diaspora federated network that I think applies here as well. I host a diaspora instance and it becomes increasingly difficult for me to do so for cost and maintenance reasons. The server can't keep up with the load on the network and I can't afford more powerful server nor have time for migration to a new server. My ideal solution would be to help migrate users to other instances, which is currently impossible.

If mastodon solves this on the network level it will make life of server operators much more stress-free. Sometimes you just want to help but then you want to pull back a bit and this all should be possible - anyone pitching whatever they can, whenever they can.

[JoshuaACNewman]

I'm really happy this is getting serious thought. I'll present another use case that I'm not experiencing:

Mastodon.cloud is overrun at this point. Following the Local conversation is effectively impossible, given that there's no way to stop the scrolling. Most of it is in Japanese right now, to the tune of about 5 posts a second, as I count it. Even if it was in English, I couldn't read it.

I want to start an instance that doesn't propagate at such an alarming rate. "Everybody in the world" is not a useful number of people to follow. So I want to start my own instance, focused around my interests and social group.

But I'm not ready for that. So a kind soul with overlapping interests invited me to their instance. However, unless I can migrate my followers, every time I'll be literally starting over.

I'm an independent creator. Those followers are literally my income. I'm not alone in this. So, in order to encourage full-throated, enthusiastic adoption, I agree very strongly that we have to be able to move without UX hiccup from one instance to another. No follower should have to take any action. Why should they? They don't want to follow the instance. They want to follow me.

I'm very happy to say that every concern, from use cases to confirmation of identity, is being addressed here. So: thank you! Mastodon is a whole lot of what I want and I would love to see it thrive.

[TehShrike]

I'd like to start up my own instance to move my account to, but I'm waiting until there's some way to migrate my account there with my followers and following list.

[ghost]

The only thing really needed is to export/import toots. Followers can come back, old toots not.

[JPLeBreton]

Followers can come back, old toots not.

The discussion in this thread offers ample evidence that it is not really that simple. You may not care if you have to rebuild your follower base after migrating, but for other users it is a critical form of community and in some cases even financial support. I think there are certain responsibilities platforms have to their users once entrusted, and Mastodon's existence is due partly to existing platforms not honoring some of those responsibilities.

If migration carries any kind of high cost, users will not do it.

[sequitur]

I honestly think importing post history is actively less important than automatically forwarding/transitioning followers. Posts on a microblogging platform are ephemeral by nature, and your follower list is much closer to the heart of what gives your account value.

[JoshuaACNewman]

I'd agree that, while losing posts would be annoying, losing followers
would be debilitating.

Remember that a lot of us have no marketing outside of our social media.
This isn't a hobby or pastime. It's our job in a society that doesn't
otherwise value our work, whether it's art or community journalism or
whatever.

Social media is how we find our people. Most of our communication in socmed
is phatic — the social connection is the important part, usually above the
content of the message. For those purposes, a loss of one's community is
far worse than the loss of one's food photos, however good a cook one is.

|ζ•
On Sun, Apr 23, 2017 at 4:13 PM Bruno Dias [e-mail] wrote:

I honestly think importing post history is actively less important than
automatically forwarding/transitioning followers. Posts on a microblogging
platform are ephemeral by nature, and your follower list is much closer to
the heart of what gives your account value.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/177#issuecomment-296485284,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AalEQ4eLac4n4P29k1wzKn09QefJgSThks5ry7DSgaJpZM4K5Bba
.

[ghost]

For me and some people I know of, the content is as much important as the people you interact with. But I understand everyone has is own preference. So it wasn't my intention to say that content is more important than followers. It is just that you can't post/toot to the past, but you can re-follow people and try to get your followers back.

[JoshuaACNewman]

You can recover from losing all sorts of resources, if you have other
resources to sub in.

In the absence of systemic socioeconomic reform, we have to build our own
systems resilient to hegemony.

|ζ•
On Sun, Apr 23, 2017 at 4:38 PM jeroenpraat [e-mail]
wrote:

For me and some people I know of, the content is as much important as the
people you interact with. But I understand everyone has is own preference.
So it wasn't my intention to say that content is more important than
followers. It is just that you can't post/toot to the past, but you can
re-follow people and try to get your followers back.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/177#issuecomment-296486961,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AalEQ9XBHrvQWrg0WmUGfUakKbZV_YyZks5ry7bTgaJpZM4K5Bba
.

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

[ghost]

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

[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 [email protected] different IDs but that string, [email protected], 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 https://github.com/swicg/general/issues/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.

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

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

[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?

[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]

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 [email protected], 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 [email protected] 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 [email protected]. Bob enters his credentials for site1.tld, and clones [email protected] to [email protected] seamlessly. Alternatively: Bob exports his channel [email protected] to a file, which he uploads to site2.tld and his account there.
• Bob continues to make personal posts to [email protected], and those updates are sent back to site1.tld as well. When site1.tld goes offline, Bob can continue to post to [email protected] 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 [email protected]. 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 [email protected] and [email protected] with the zot protocol. Channels that comment on [email protected] will show up to Bob on [email protected], 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?????

[ghost]

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

[Zash]

There's some prior art in the XMPP world, an Import/Export Format and a a way to move subscriptions. Might be useful to have a look at for inspiration, especially the security considerations. Account migration isn't implemented anywhere tho, partly due to lack of interest. The export format is supported by some software however.

[trwnh]

As long as we're looking to inspiration from XMPP and that era -- I've been
thinking that Mastodon could perhaps be a bit more like email in how it
handles messages attached to accounts, i.e. "inboxes".

Migrating email accounts is as simple as uploading all your messages to
your new account (via IMAP) and redirecting your old email address to your
new one (via email forwarding rules). If an old email address is about to
go down, then you notify all your contacts to start using your new address
(this can be done automatically a la #6955).

As for other federated social standards, one step down from the whole
Hubzilla/zot "nomadic identity" I described above is just simply importing
a backup like Friendica. https://forum.friendi.ca/help/Move-Account -- the
exported file "contains your details, your contacts, groups, and personal
settings. It also contains your secret keys to authenticate yourself to
your contacts." You then "[do] NOT create a new account prior to importing
your old settings - uimport should be used instead of register." And after
importing this backup, Friendica says that your old account "will not work
reliably anymore, and should not be used".

I'm more keen to the email-like approach because of its simplicity -- we
need basic migration ASAP, and live migration or nomadic identity are more
of "nice-to-haves" to be extended in the future.

On Wed, Apr 4, 2018, 16:05 Kim Alvefur [e-mail] wrote:

There's some prior art in the XMPP world, an Import/Export Format
https://xmpp.org/extensions/xep-0227.html and a a way to move
subscriptions https://xmpp.org/extensions/xep-0283.html. Might be
useful to have a look at for inspiration, especially the security
considerations.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/177#issuecomment-378744624,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKHXX4cBGzF1uzMSM3xsJms8wAnc87jYks5tlTVegaJpZM4K5Bba
.

[MrEldritch]

Affirming that this is a serious issue; I actually just now tried to join Mastodon, got intimidated by wanting to be a good citizen and not just dump more strain on mastodon.social or other big servers _but also_ not wanting to pick any instance that was _too small_ because of the risk it would go down due to server costs or admin drama or whatever and nuke my account, and knowing that whatever instance I _did_ pick I'd be stuck with forever if I actually got invested in the platform and started having a toot history and followers I didn't want to lose (so I'd better not pick something I wouldn't want stuck on the end of my username in public, like monsterpit.net)...

...and just kinda gave up and went looking to see if my perception of the impossibility of moving was accurate. (Apparently it is.)

[nightpool]

@MrEldritch in practice, people move around all the time without much
issue. you just post a couple times on the old account and import your
followers list, which reminds people to refollow you. there's just not a
seemless technical solution yet

On Wed, Apr 18, 2018, 11:04 AM MrEldritch [e-mail] wrote:

Affirming that this is a serious issue; I actually just now tried to join
Mastodon, got intimidated by wanting to be a good citizen and not just dump
more strain on mastodon.social or other big servers but also not
wanting to pick any instance that was too small because of the risk it
would go down due to server costs or admin drama or whatever and nuke my
account, and knowing that whatever instance I did pick I'd be stuck
with forever if I actually got invested in the platform and started having
a toot history and followers I didn't want to lose (so I'd better not pick
something I wouldn't want stuck on the end of my username in public, like @
monsterpit.net)...

...and just kinda gave up and went looking to see if my perception of the
impossibility of moving was accurate. (Apparently it is.)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/177#issuecomment-382419342,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAORV4KaVT3ZhGAvg_OojDcaLdEcM2wsks5tp1YDgaJpZM4K5Bba
.

[sandhawke]

@nightpool I think how serious an issue this is depends how seriously you take the platform. If it's a chatty place and you don't really care that your work stays around or is cited or who follows you, then this is not a serious issue, no. When I moved from mastodon.social to w3c.social, lots of people didn't follow the move. There's no way to know why, but I'll tell you, it was disheartening. I think statistically, this kind of design choice drives Mastodon toward small conversations with people you know, vs scaling up to people with lots of followers. Maybe that's the style Mastodon wants. (Although my sense is no one's arguing against solving this issue, just that it actually is quite hard.)

[nightpool]

When I moved from mastodon.social to w3c.social, lots of people didn't follow the move

There are a couple reasons this could be possible, but my impression is that a lot of people have "inactive" followers—people who signed up once but never returned.

Although my sense is no one's arguing against solving this issue, just that it actually is quite hard

Absolutely. And there are a lot of use cases where I think the solution is both critical and necessary—a user who gets in a fight with their admin, or a server that goes down without any warning, like mastodon.rocks did earlier this year. But I'm just saying that people shouldn't let the lack of a solution for this issue discourage them from signing up for the network.

[Cassolotl]

I feel like MrEldritch was telling us about their experience as a new user and how the lack of migration features was quite off-putting, and probably telling them that other people get over those difficulties might not be that helpful.

For every MrEldritch that speaks up there will be many, many more who don't join Mastodon (or who leave very quickly) and who don't come to the Github issue list to tell us why, and since account migration is supported by everyone then I feel like it would be good to support people to tell us what they find difficult and why.

[astrojuanlu]

I subscribed to this issue because I won't join Mastodon until this is sorted out. I already suffered this same thing on Quitter, years ago.

[JPLeBreton]

A bit of perspective on this: to anyone who makes their living from fans of their work, a platform where you might suddenly lose your line of contact with those fans is a no-go. Even people who follow your work closely might not follow you to a new account if they step away from the platform for a while and miss your "I'm migrating" posts, and I don't think it's acceptable to put that work on users when the platform could handle it better. Mastodon should absolutely be a place where you can grow a following for your work and have more trust in your line of communication with fans than the big proprietary services offer. This may not seem as important to users who aren't supporting themselves in this way - say, if you're an engineer with a comfy day job who just wants to use this platform for chatting - but Mastodon's user culture is immensely better for supporting this kind of thing.

[t-m-w]

I, just a user, agree that this issue should be taken seriously, but there are some factors that need to be taken into consideration, based on the scenarios people are bringing up here. I haven't read this whole thread (sorry, it's huge), so I apologize if this has already been mentioned.

If an instance becomes inaccessible for whatever reason before users have a chance to back up their data or perform a migration, there is currently no recourse, and there can't be one, based on current conceptualizations of this issue.

An earlier reply mentioned "citing" toots, but toot links depend on instance URL, so again, if something happens to break an instance, there is nothing that can make those links work. Some challenging development verging on redesign would need to be done to make such things possible, as far as I can tell. Maybe it's worth it, but it's no small feat.

For now, as far as I understand, the only surefire way to avoid the issues recently described, for artists or whoever else, is to self-host an instance.

[Laurelai]

Another thing to consider is that just importing a follow list is not enough, some people either via inertia, business or not noticing wont see the follow notification and wont re-follow. A sort of "follower entropy" happens each time you migrate

[pingu8007]

I just had a look at this thread, the issue can split into:

• Data transfer - export and import
• User discovery - finding moved user

The big problem is how instances find an user ([email protected]) they never seen?

1. Ask the instance at example.social (A, AAAA)
2. Ask the instance mentioned at example.social (CNAME, SRV or TXT)
3. Ask network who response for example.social, than ask that instance (DHT, Blockchain, ...)
4. Ask network who response for tom, than ask that instance (DHT, Blockchain, ...)

(I'm not familiar with WebFinger so leave it alone)

Case 1&2 are the easiest and fastest way. However, since we are talking migration, the original instance and/or domain may be unavailable.
In case 3, @example.social should work even example.social is NXDOMAIN. But the instance still need to know where is tom (back to case 1).
In case 4, it should work even @example.social don't remember tom. However, I've no idea how many logs will be there.
Maybe we can have a look at case 3&4?

[RX14]

The big problem is how instances find an user

You can type arbitrary addresses into the search box in mastodon already, this is a solved problem for many years, and already part of the ostatus/activitypub spec. It uses webfinger.

Migration where the original instance has shut down is going to basically be impossible. Let's leave it for later if at all.

[trwnh]

@MrEldritch:

whatever instance I did pick I'd be stuck with forever if I actually got invested in the platform

More accurately, you would only be "stuck" until migration got implemented. Or, if you treat the platform more "chatty" and ephemeral like sandhawke, then you wouldn't lose anything "of value" by leaving your post history and inactive followers behind. And as 80tf3262p8 says: "the only surefire way to avoid the issues recently described, for artists or whoever else, is to self-host an instance."

@JPLeBreton:

to anyone who makes their living from fans of their work, a platform where you might suddenly lose your line of contact with those fans is a no-go. Even people who follow your work closely might not follow you to a new account if they step away from the platform for a while and miss your "I'm migrating" posts, and I don't think it's acceptable to put that work on users when the platform could handle it better.

This actually isn't unique to Mastodon at all -- this is a concern for every single platform not owned wholly by you. I've previously moved Twitter accounts at least 4 times, and my followers didn't really come with me then, either. Every time I move, I get less of my followers back, either because they're now inactive, or because they aren't interested anymore in the purpose of the new account.

On the other hand, my website URL and my email have been constant since 2013. In fact, since Mastodon is built on a federated standard like email, the closest analogue to migrating Mastodon accounts would actually be migrating email accounts. I probably touched upon that in my comment above, but the bare minimum that Mastodon should implement ASAP is basic importing and exporting of content, and perhaps some form of message forwarding -- which would put Mastodon _at least_ on-par with email. Email, of course, can be forwarded as long as the original server is still up, but the question of migrating email is fundamentally one where your contacts must update their address books.

@80tf3262p8:

If an instance becomes inaccessible for whatever reason before users have a chance to back up their data or perform a migration, there is currently no recourse, and there can't be one, based on current conceptualizations of this issue [...] toot links depend on instance URL, so again, if something happens to break an instance, there is nothing that can make those links work. Some challenging development verging on redesign would need to be done to make such things possible, as far as I can tell. Maybe it's worth it, but it's no small feat.

Yes, profiles and messages are currently bound to the DNS identification and not by any sort of unique ID or signature as in Hubzilla's zot-based implementation. This does mean that canonical URLs will break as soon as that domain name goes down and stops linking to the original content, but it can be mitigated by allowing export/import (with the caveat that you need to update all your existing links on other sites to the new domain name). I'm of the opinion that Mastodon should take long-term steps to allow for live migration of content and updating of references similarly to Hubzilla, but that's again more of a nice-to-have than a must-have right now.

@Laurelai:

importing a follow list is not enough, some people either via inertia, business or not noticing wont see the follow notification and wont re-follow. A sort of "follower entropy" happens each time you migrate

Yep, and it's the same inertia that results from changing any canonical address, like email accounts or phone numbers or even down to physical buildings. Short of trying to establish your own wholly-owned canonical references (a la the indieweb crowd), it's a matter of coming up with software implementations that mitigate or bypass these inherent limitations that come with moving anywhere.

[sandhawke]

Actually, I don't think migration where the original instance has shut down impossible. Maybe not even that hard. I think the key concept that makes it feasible is having a backup account at another instance, set up in advance. Like with computer data backups, this should be a thing that people are encourage to do if they're using the system for anything serious, and hopefully it should be pretty easy to do.

So, my primary account is @[email protected], and I'd probably make my backup be my older account, @[email protected]. There should be a way for me to point the accounts at each other, so every subscribing system has recorded that one is the backup for the other, and the servers should be set up do be replicating my data.

If the primary server goes away, even suddenly, all the followers can automatically use the backup. If the backup goes away suddenly, then I pick a new backup. The only catastrophic failure would be if both went away at about the same time. Maybe the system could even support multiple backup servers at once, for the truly paranoid.

[trwnh]

@pingu8007:

I just had a look at this thread, the issue can split into:
Data transfer - export and import
User discovery - finding moved user

Data transfer is the biggest holdout right now; user discovery is currently handled by redirection notices (better than nothing, but can be improved). To try and lay it all out again as hq did (slightly modified for easier referencing):

That is, if I have the account A on the primary instance (which I do), and I set up the account B on another Mastodon service, then A should:

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

And right now, we have the following:

• [x] 1) A remains on the original instance, albeit with a banner indicating the new account
• [ ] 2) A does not show posts from B, but only the old posts from A
• [ ] 3) Redirection doesn't disallow posting from A; people post on A to tell people to follow B
• [ ] 4) Followers of A do not see posts from B -- they must refollow B
• [ ] 5) A is greyed out and idk if following is fully disabled; I haven't really looked at it recently
• [x] 6) Followers must refollow B instead of automatically being forced to follow B.

[Gargron]

@sandhawke You described "nomadic identity" in the zot protocol / hubzilla that @trwnh pointed to a few messages earlier (Jan 1st). However, it's not all clear to me. It seems like you end up in a master-replica situation with two masters...

[sandhawke]

@Gargron It could very confusing, yes. How about this, instead -- some accounts are explicit backup accounts. I'm [email protected] and [email protected] (more or less). The backup accounts can't be posted to; they only get content via sync from their master. The only thing the user can do at the backup server is point it to a new master if the old master dies.

[trwnh]

@sandhawke You're correct that migration from a shut-down instance isn't impossible, per se... it just requires you to proactively download your exported archive. If the instance goes down suddenly like mastodon.rocks, then you likely didn't make a backup, and now all the data is gone. Under such a system, the onus would be on every single user to make regular backups if they care about migrating off the instance or in the event of catastrophic failure. This is a very awkward solution.

So, my primary account is @[email protected], and I'd probably make my backup be my older account, @[email protected]. There should be a way for me to point the accounts at each other, so every subscriber knows one is the backup for the other, and the servers should be set up do be replicating my data.

What you're describing is the live migration / mirroring, or "nomadic identity" system that Hubzilla uses: https://github.com/tootsuite/mastodon/issues/177#issuecomment-354634232

Under zot, any linked accounts are effectively mirrors of each other, passed back and forth between servers. Any server that is hosting your identity will share basically everything back and forth -- mentions, permissions, post history, etc. And yes, if one goes down, then everything is fine as long as any other clone is up.

@Gargron I'm willing to attempt to do what it takes to clarify the situation or implementation in any way. I suppose "master-replica with two masters" is pretty close, yes -- it's like sending an email message to two addresses, and therefore you end up with two copies in two inboxes. But each copy is still the same message; you just have two copies of it.

Conceptually (http://www.talkplus.org/blog/2017/what-is-a-nomadic-identity/):

Bob has two email accounts. He has a home account at [email protected], and he has a work account at [email protected] [...] when we send an email, we will send to both of Bob’s addresses any time we send an email to Bob. This way he’ll get the message no matter if he’s at home or if he’s at work. [...] as far as your software is concerned, it’s just ‘Bob’. You don’t care what server he uses or what job he has this week. [...] if Bob loses his job and his account gets removed from work.server [...] he’ll just use home.server; and then when he gets a new job, he can send you stuff from [email protected]. [...] if Bob posts a picture while he’s at work, his work server sends a copy to his home server so he’ll have the same picture in his photo albums in both places. If he makes a new friend, the friend will be added on both servers so he has the same friends no matter where he goes.

Technically (https://project.hubzilla.org/help/en/developer/zot_protocol#Technical_Introduction):

In order for an identity to persist across locations, one must be able to provide or recover:

• the globally unique ID for that identity
• the private key assigned to that identity
• (if the original server no longer exists) an address book of contacts for that identity.
  This information will be exportable from the original server via API, and/or downloadable to disk or thumb-drive.

Generating GUID (globally unique ID):

to create a globally unique ID, we will base it on a whirlpool hash of the identity URL of the origination node and a psuedo-random number, which should provide us with a 256 bit ID with an extremely low probability of collision, as a base64url-encoded string. [...] the ID must also be attached to a public key [...] We will refer to the encoded globally unique uid string as*zot_uid

With regards to DNS and a "primary" hub:

As there may be more than one DNS location attached/bound to a given zot_uid identity, delivery processes should deliver to all of them - as we do not know for sure which hub instance may be accessed at any given time. However we will designate one DNS location as "primary" and which will be the preferred location to view web profile information. We must also provide the ability to change the primary to a new location

How the primary hub/node works:

A look-up of information on the current primary location may provide a "forwarding pointer" which will tell us to update our records and move everything to the new location. There is also the possibility that the primary location is defunct and no longer responding. In that case, a location which has already been mapped to this zot_uid can seize control, and declare itself to be primary. In both cases the primary designation is automatically approved and moved. A request can also be made from a primary location which requests that another location be removed.

How to map additional hubs:

In order to map a zot_uid to a second (or tertiary) location, we require a secure exchange which verifies that the new location is in possession of the private key for this zot_uid. Security of the private key is thus essential to avoid hijacking of identities. [...] Key revocation and replacement must take place from the primary hub.

How account discovery occurs:

A well-known url is used to probe a hub for Zot capabilities and identity lookups, including the discovery of public keys, profile locations, profile photos, and primary hub location. The location for this service is /.well-known/zot-info - and must be available at the root of the chosen domain.

I advise looking at the example discovery packet to get a better idea of its structure, but tldr: it contains a signed token, signed guid, public key, some other profile metadata, and importantly, arrays for locations and for the site you're communicating with. Specifically, the locations array contains a hostname, address, whether it is primary, a signed url, a callback, and a site public key, for each location that is hosting the zot_uid.

---

tl;dr for all that: Hubzilla / zot works by creating guids and signing with some sort of PKI, and if your primary server authorizes any other servers, then those servers get deliveries of the same messages.

The guid is the hard part. Once you have guids (or, in Mastodon's case, once existing accounts are somehow converted to / assigned new guids), you can now address messages to guids instead of to local uid or username@domain. And like I said on #6837: the sooner this is done, the less headaches it will cause in the future. Trying to refactor something that affects a million accounts is easier than trying to refactor something that affects ten million, or a hundred million. As long as there's a dependence on DNS identity, any solution to account migration can't ever be 100% seamless. Perhaps that's a tradeoff willingly made, or perhaps not.

[deutrino]

Two observations on the current conversation:

• If a solution similar to nomadic identity is to be implemented, it would be best for it to be fully automated and for a user to be able to choose to migrate to any instance, preserving at least their follow/following lists, at any time, without doing any work ahead of time. If migration requires planning and work up front, most people aren't going to do it. New users still have trouble with the concept of instances. If they even realize that migration is a concern when signing up, many of them would hit the (inevitably complicated) section of docs about backup accounts and migration and say "wat" (usually) or "k I'll do this later" (if we're lucky). Then most of them won't set it up, and when instances vanish, they're screwed, even though all this dev work was spent on a migration feature. Don't get me wrong, it's great to support the garden path of migrating between running instances, but can we do better? (See below for implementation details.)
• If a user chooses to migrate, they really should be informed when the destination instance has conflicts with their follow/following lists due to instance blocks - this needs to be addressed from the start and not when somebody inevitably files a bug after they do all the work to migrate to a new instance and only then find out their favorite follows/followers are blocked.

Implementation details for zero-config migration:

You'd need a globally unique identifier held only by the user. Is the tuple (username, password_hash, optional_2fa_seed) sufficient to authenticate the user and pair them with e.g. an immutable uuid used behind the scenes?

Information sufficient to authenticate the user and to reconstitute their follow/following lists would need to be replicated around the network. Storing it all in a blockchain is overkill - not every node should need to retain every user's follow lists, that doesn't scale. However, the tuple used to authenticate users might need to be more widely replicated than follow lists.

To keep network and storage load sane, you could store follow lists on some number of instances n considered sufficient to provide redundancy (say n=3) but then you have the problem of which instances store what, how do you retrieve the info when needed, and how do you distribute updates when follow lists or passwords change.

Focusing on just the follow lists for the moment, one could store them in a DHT with the key being the global uuid of the user, and have some sort of election to pick the n instances to store the data at the time the user account is first created. The election process could be as simple as "build me a hash table of all active instances, deterministically select n based on the value of the user's uuid" or something more equitable (and potentially controllable) for server operators, like a population-weighted selection algorithm, so small instances don't end up hosting tons of data disproportionate to their number of users.

Once you have that infrastructure, you need a couple more things.

When one of the n instances replicating the follow lists goes away for long enough (i.e. availability on the DHT drops below n for too long), some process needs to notice this and elect a new instance to host replication data such that DHT availability is brought back up to n. Likely this should be handled by the user's home instance - that seems fair in terms of load. Eventual consistency is fine here, this process can operate at a slow and steady pace, and only get worried when it notices availability consistently < n for some value sufficient to account for outages likely to be seen on Mastodon (perhaps 3 days).

Perhaps more difficult, when the user's follow/following lists change, updates need to be replicated. Again, eventual consistency is fine here. Allowing it to take a day or so for updates to replicate is probably fine, especially if it balances load. But more importantly: how do you prevent spoofing if the user's uuid and the instances hosting their replicated data are known? And does this change the minimum necessary tuple of (username, password_hash, optional_2fa_seed) necessary to authenticate the user, or processes operating on their behalf?

The way I see it, the major costs of this scheme are development cost - lines of code to write, debug, and maintain - and server load - mostly additional disk space for storing user auth tuples and follow/following lists, and network traffic replicating updates to follow/following lists. It may make sense to consider the idea of supernodes at this point, or some other mechanism to make the scheme opt-in for small instances, perhaps as simple as until you have 100 monthly active users, hosting replication data is opt-in.

The major benefits, however, may be worth all this work. It really depends on how much the feature is likely to be used. If people would tend to use it often enough, doing it this way would make mastodon exceptionally resilient to the loss of instances, even huge ones, without users having to do any work up front at all. A big lesson one can take from natural disasters is that when a city gets devastated, people whose housing is destroyed often move somewhere else and don't return. What happens when a top 10 instance vanishes without warning? I think the answer is a lot different if the users can simply log in at any other instance and choose to migrate their presence there, even with the original instance offline.

Edit: there are security and privacy concerns with parts of my scheme, particularly with replication of user auth data - I suspect somebody more studied than me in CS and/or crypto can come up with something similar but better. With regard to replicating follow lists, this is a privacy concern, but I'd argue that having some number of instances n with a user's follow lists is an acceptable trade-off, given that there is not, and will never be, any guarantee that the data cannot be assembled by other means conceptually far simpler and more likely to work than attempting to maliciously host replicated follow lists - see #6901.

[trwnh]

@deutrino Hubzilla's method is already "automatic" and only requires you to login to your account on your primary instance, during registration of any secondary accounts. i.e., you start registering for another account and, during that setup process, you have an option to make your new account a "clone" of your primary account. You can also optionally upload an exported account archive, if your former primary server is down. I think the archive contains your post history, cryptographic keys, zot_uid, and address book.

A DHT seems like a cool idea as well, but that might be a bit more complex in deciding how each server should treat it. I can see a DHT being more useful if you were trying to establish agreed-upon usernames across the entire network, but username@domain isn't too bad right now for finding people, and dropping the domain name from handles is probably outside the scope of this issue.

[sandhawke]

@trwnh I'm not suggesting users manually back up their social data. The analogy is to automated backups, where you get a backup account somewhere and then all your data is always backed up and you don't have to worry about it.

The zot approach seems pretty good, but I fear is too big a leap, which is why I'm sketching out something that seems simpler. No crypto, for one thing. Nomadic identity would be great if it can be deployed across the fediverse.

My sketch of a possible alternative, in a little more detail:

1. I get my first account, as [email protected]
2. Some time later, I decide I want a backup, so I make an account at a mastodon-backup service (which is probably mastodon in a different mode, or maybe every mastodon instance also offers this in the future). Let's call this account [email protected]
3. I tell the servers about each other. Now m1.example will sync all my data to backup1.example, continually. It's similar to sending stuff to a subscriber, but private stuff is sent too. Maybe protocol-wise backup1.example is just a client app I've authorized to access m1.example.
4. When people follow [email protected], part of the exchange tells them the id of my backup account. If I add another backup account, or remove one, they get notified.
5. backup1.example is authorized to deliver to my subscribers, and I can transfer that authorization to a new master, if I want.
6. Ideally, backup1.example makes URLs for my stuff that are a simply syntactic transform from the original, so if m1 behaves responsibly, when it shuts down or I otherwise leave it, they can use a one-line-config redirect to make all my old URLs still work, forwarding them to the same content at backup1. I suppose URL persistence isn't yet seen as particularly valuable in Mastodon, but ... it is actually valuable.

[steckerhalter]

lots of stuff here, didn't read all of it so forgive me if I missed something. I was thinking:
if I want to switch from mastodon.social to example.social, what I do care the most is that I don't lose my followers. so I could totally live with a solution that let's me switch to another server and just leaves my old account as it is, transferring only my followers (automatic unfollow on old account and follow on new account). then later on I could choose to delete the old account or just leave there for reference.

this could be a first step to encourage people to switch servers without having to go into content migration, backup accounts, url persistence etc. these things could be tackled later on.

[wiktor-k]

Actually from technical side this shouldn't be that hard as ActivityPub objects already have a movedTo property. All it takes is to "invite" your old followers to the new account. Then each of them would check if your new account is pointed to from your old account's movedTo and auto-follow.

[nightpool]

That solution has been considered, but it only works if both servers are
still online

On Sat, Jun 2, 2018, 9:07 AM Wiktor [e-mail] wrote:

Actually from technical side this shouldn't be that hard as ActivityPub
objects already have a movedTo property. All it takes is to "invite" your
old followers to the new account. Then each of them would check if your new
account is pointed to from your old account's movedTo and auto-follow.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/177#issuecomment-394090089,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAORV0hql7gjBNZ1lpeUbv1TZ_dz7-qlks5t4pw2gaJpZM4K5Bba
.

[wiktor-k]

It has an advantage of working right now. I don't have stats to support it but I'm seeing a lot of migrations especially from mastodon.social (that people choose initially to try out this Mastodon thing) to more specialized servers.

Solving migration from non working servers would require more elaborate design, probably based on asymmetric keys. Actually users already have keys but the private part is always held by the server, never released to the user. If uses had backup copy then other servers would be able to authenticate move requests using cached versions of public keys.

[nightpool]

yeah that's the current thinking. just requires implementation and a minor
amount of bikeshedding the details

On Sat, Jun 2, 2018, 11:26 AM Wiktor [e-mail] wrote:

It has an advantage of working right now. I don't have stats to support it
but I'm seeing a lot of migrations especially from mastodon.social (that
people choose initially to try out this Mastodon thing) to more specialized
servers.

Solving migration from non working servers would require more elaborate
design, probably based on asymmetric keys. Actually users already have keys
but the private part is always held by the server, never released to user.
If uses had backup copy then other servers would be able to authenticate
move requests using cached versions of public keys.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/177#issuecomment-394099211,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAORV9mHILJHb6I8yP9VPZWf41vvYL4Dks5t4rybgaJpZM4K5Bba
.

[steckerhalter]

@nightpool yes, that's what I'm suggesting: to implement the most common and simplest case (both servers running, follower/following migration, no content migration, no backup accounts etc.) because I think this feature is important for the network as a whole. more sophisticated migration methods can be added later of course.

[penguin42]

IMHO what's needed is live mirroring not account migration.
Here's a proposal (I don't know the protocol to know how hard it is, please educate):
a) I create an account on multiple instance
b) On each instance I add a list of my equivalent identities on the other instances to my profile.
c) Each instance follows the mirrored identities
d) Each message shall contain a unique ID including the server that originated the message
e) When an instance receives a federated message from a server with an ID corresponding to a mirror-ID of one of it's users, it checks that the unique ID doesn't indicate that it originally started at it's own server, and if it doesn't retransmits the message on their users profile, including the original unique ID.
f) Servers filter multiple messages with the same ID from the federated stream leaving one.
g) When following a user the client also follows mirror identities. This updates when the person being followed adds/removes mirrors
h) Admins can allow/disallow mirroring from certain bad/good servers

Now, there's essentially no 'primary' server for any one user; if one dies you just log into one of the other instances you've previously set up as mirrors and your message propagates to other servers by normal federation, your followers carry on seeing your messages with no change; if your original server wakes up it'll also pull those messages in by federation (probably).

[steckerhalter]

@penguin42 interesting idea. but I'd say implementing this would be a ton of work (if it is even possible given the existing protocols). since this is high prio I would not try to rebuild rome just now :smiley: how about creating a separate issue "account mirroring" outlining this idea for later?

[trwnh]

@steckerhalter Not to be too self-promotional, but I would point you toward at least these three comments if you're looking for a primer:

• How Hubzilla does it: https://github.com/tootsuite/mastodon/issues/177#issuecomment-354634232
• How Friendica does it / how we can do it in an email-like way: https://github.com/tootsuite/mastodon/issues/177#issuecomment-378779767
• A brief summary of the original request and which parts have been implemented so far: https://github.com/tootsuite/mastodon/issues/177#issuecomment-382748291

[penguin42]

@steckerhalter OK, as requested, 7715 is that split out.

[autogestion]

What if use namecoin to store identity. It allows to attach to name some information, which could be url of actual user's account

[trwnh]

I feel like this issue should be much higher priority than it currently is, in the interest of offering a truly portable experience where you own your data.

At this point, rather than recycling old discussions and approaches, can we try to hammer out an actionable plan to implement portable identities?

Current blockers to account migration

1) Identification is bound to domain

A. Mastodon, throughout various places in its code and database, uses username/domain pairs to identify users.
B. The Mastodon API fetches users with GET /user/uid, where uid is a sequential integer like 55816 and only guaranteed to be unique on that domain. But this id is used only for API, and the local server converts the received profile into username/domain for its database.
C1. Therefore, there is no way to identify users in a way that isn't bound to at least the domain.
C2. Therefore, some other form of ID should be used, and Mastodon's codebase/database should be updated to use it internally, leaving username/domain only for lookup.
C3. Therefore, seamless translation should occur between all these types of identification, with username/domain being converted to UUID internally and mentions/accounts being mapped back to UUID.

As explained in https://github.com/tootsuite/mastodon/issues/177#issuecomment-382761085, zot already has a workable scheme to address this, and an identity consists of a 256-bit GUID and a private key. For live migration, this is enough. For data exports, this should also include an address book, i.e. in Mastodon's terms, the follower/following lists.

The zot identity is managed by a primary hub, and if that hub goes offline, any hub with the private key can declare itself to be the new primary hub (initiated by the user). Users can import their GUID and private key to any server by either uploading their backup, or by live mirroring from the current primary hub. Your followers' primary hubs are notified of your new hub.

2) Old content

Previously-posted statuses are floating around with mentions that explicitly link to a certain domain/username. These will probably break. However, that's not much different than what currently happens if a server goes offline: any user on that server will become inaccessible, and all mention-links to that user will also become unresolvable. Therefore, this will be a breaking change, but ultimately one that needs to be made for the resilience and robustness of the future network.

Plan

1. Start generating GUIDs for Mastodon users in preparation for v.3.0.0, the sooner the better. We might as well use the "256-bits encoded as base64url" schema that zot uses, if there aren't any other options that work better for some reason or another.
2. Start refactoring the codebase to accept either username/domain pairs or the newly-generated GUIDs. If a GUID exists, it should be authoritative over username/domain. This will probably affect (at the very least) account generation, account lookup, mentions handling, and URI dereferencing. GUID should be served as ActivityPub id field for Actor objects. The URL should be served via url instead.
3. Write a database migration task to start storing accounts internally by GUID.
4. Start using GUID for follower/following lists. Ensure that the data export tool includes the GUID and user's private/public keys, as well as their posts, media, and follower/following lists.
5. Write a handler to announce updated username/domain for a given GUID to your follower/following lists, using a secure exchange between servers and probably the Update Activity. Write a handler to receive and parse this Update.
6. Write an import tool for the offline data export archive.
7. Write a live import tool to exchange data directly with your primary server.
8. When v3.0.0 is released, expose steps 6-7 to users. Since by this point the majority of users should already have a GUID due to step 1, and the logic for handling GUIDs should have percolated through the network thanks to steps 2-5.

---

Any insights from coders on this? Does this seem workable?

[remram44]

Using a public key instead of some random hash would allow you to prove ownership of the identity, in the presence of bad third-party servers, or bad/gone previous server. Anyone can verify that you (possessor of the private key) did indeed initiate the change of domain.

[pingu8007]

I'm confused. Does it mean username/domain will be changed as long as one moved?
The migration largely rely on notification from new primary hub, how can I find the moved user without the knowledge of new primary hub? Such as an old address printed on business card, a dump with outdated hub information, or a GUID string only.
Hand out my private key make me a bit unsatisfied, any details?

[remram44]

I think in @trwnh's scheme you need the old domain to still exist and let you know where the new location is. Truly resilient discovery could be done through e.g. a DHT, mapping GUID to domain.

A private key is never handed out, it's private.

[trwnh]

@pingu8007 The primary instance would send a notofication to your followers' instances -- see point 5 pf the plan.

@remram44 Are there any concerns with using the public key directly as a GUID, rather than as a separate field? I suppose functionally, a public key is ostensibly unique, but my understanding is that it would be inefficient to refer to every user by public key, even in unencrypted situations. Also, using a separate GUID allows for the encryption schema to change later.

Of course, I'm also unsure of the exact schema Mastodon uses for encryption right now. The existence of a private key for a user implies that public keys are generated for each user, but I have no idea if this is indeed the case, or if keys are generated per-server. Per-user keys would go a long way toward potential end-to-end support, but that's a separate issue. It may end up being necessary to establish provenance of your identity, though.

[remram44]

You don't have to use the full public key. A hash or fingerprint works.

My concern with a freely chosen GUID is that collisions are possible. A bad actor could use the same GUID as you, and mess up your account for the people that hear about him before they hear about you.

Reading about your scheme again, I'm wondering if a GUID is necessary at all. Why not use the old username@domain in place of the GUID? And just announce that the old handle is now at a new location?

[wiktor-k]

You don't have to use the full public key. A hash or fingerprint works.

For the record ed25519 public keys are only 32 bytes in size only twice as big as GUIDs (16 bytes).

Reading about your scheme again, I'm wondering if a GUID is necessary at all. Why not use the old username@domain in place of the GUID? And just announce that the old handle is now at a new location?

I think one of sub-problems to solve here is to handle old server down forever scenarios. Announcing new handle at old location is already possible with movedTo (e.g. this account).

[TehShrike]

I'm fine with identity being tied to server. I just want a way to formalize "My identity has transitioned from [email protected] to [email protected]" in a way that all my followers and follow lists move from coolserver.com to toteselite.com.

If coolserver.com maintained a "forwarding address" to the new location, that would be cool too, but you can't rely on that staying up forever.

Changing the nature of identity on mastodon sounds much more difficult.

[LeeteqXV]

It might be impossible to underestimate the long term value for the whole
Fediverse (and beyond) of contributing to true, scaleable, decentralized
identity handling. Server dependent solutions should therefore be avoided.

On Sat, Jun 23, 2018, 19:49 Josh Duff, [e-mail] wrote:

I'm fine with identity being tied to server. I just want a way to
formalize "My identity has transitioned from [email protected] to
[email protected]" in a way that all my followers and follow lists
move from coolserver.com to toteselite.com.

If coolserver.com maintained a "forwarding address" to the new location,
that would be cool too, but you can't rely on that staying up forever.

Changing the nature of identity on mastodon sounds much more difficult.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/177#issuecomment-399696672,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ASzGVDFOIIFqv5hARL88X6YFk78-QxTxks5t_n-2gaJpZM4K5Bba
.

[phileastv]

Why not integrate this into the registration process. When someone registers in a new instance, this instance will check if the mail address used to create the new account is already used on other public instances.

If the same mail address is detected on another account on another instance, the new account on the instance will propose to set up the redirection settings _(to change from one instance to another, with all the parameters that @hach-que has purposed)_. The user can refuse and decide to do nothing, and start from an empty account.

This will make the process simpler for a broader audience who don't want to mess with theses redirections settings.

[remram44]

check if the mail address used to create the new account is already used on other public instances.

How do you do that? How do you prevent other instances from lying? How do you prove to the old instance that this should happen? How do you deal with the old instance being broken, or malicious?

[Shywim]

One way would be the two instances sending each a validation email. The only case in which there is a problem is if the instance you want to move _from_ is malicious, but you can't really prevent anything in this case.

[penguin42]

remram44: Dealing with the old instance being broken is why I said above (and split out as issue 7715) is that what's really needed is live mirroring between accounts, so you setup a spare before one side fails.
To do migration, I guess you could use signed toots, with some form of message that advertises the change.

[trwnh]

@remram44

My concern with a freely chosen GUID is that collisions are possible. A bad actor could use the same GUID

Random collision in 256-bit will take longer than the life of the universe. Intentional collision would be prevented by cryptography. At least, that's how zot does it -- see: what an identity consists of, https://github.com/tootsuite/mastodon/issues/177#issuecomment-399172654 (uid and private key, plus address book if offline).

Why not use the old username@domain in place of the GUID? And just announce that the old handle is now at a new location?

That might work only for the purposes of migration, but for basically nothing else. It also requires validation of some sort with the server on that domain, which might be offline. It also will not be preserved when migrating to a new server/domain -- the point of the GUID is to identify the two accounts as the same without revealing a key. Verification happens in a different step.

@TehShrike

I'm fine with identity being tied to server. I just want [...] all my followers and follow lists [to] move [...] If [the old server] maintained a "forwarding address" to the new location, that would be cool too, but you can't rely on that staying up forever.

That's exactly what would ideally be avoided. If all you care about is having your address book move, then much of that is already possible. But IMO, a proper "migration" would unambiguously move your entire account, not just the details of it.

Changing the nature of identity on mastodon sounds much more difficult.

It will definitely be difficult, which is why the plan I described proposes a gradual change before it becomes official (in a v3.0.0 change). Right now, the fact that identity is tied to user/domain is a major blocking issue to any sort of migration. If that doesn't change, then Mastodon will never be able to gracefully handle anything more than the "account moved" notice we already have. Any existing instance will see your moved account as an entirely different account, which is extremely inconvenient.

@wedza

Why not integrate this into the registration process. When someone registers in a new instance, this instance will check if the mail address used to create the new account is already used on other public instances.

That doesn't really solve the issue. Signing up with the same email can already be done for multiple instances, to create separate accounts. Also, it's a really bad idea to expose the email address used by an account. But you do have a point that it probably should be exposed during registration -- in fact, Friendica and Hubzilla already do this, offering you options to import an account or to set up a new one. This has nothing to do with the email used, though; it just uses the ID/keys/posts/contacts.

@penguin42

what's really needed is live mirroring between accounts, so you setup a spare before one side fails.

That would easily be possible once the secure exchange / import logic is implemented. The only difference would be setting the new server as a secondary instance rather than as a new primary instance.

[remram44]

Random collision in 256-bit will take longer than the life of the universe. Intentional collision would be prevented by cryptography.

Intentional collisions are exactly what I'm concerned about. "Prevented by cryptography" only happens if you use a public key hash instead of a GUID. Note that GUID means something specific: those are 128-bit values with a specific (versioned) schema.

[trwnh]

@remram44 Ah, my bad, I wasn't clear on the differences between guid/uuid/etc. I've been using the terms in the most generic sense possible (a globally unique user ID). Regardless, the (256-bit) UID alone will not be enough to constitute an identity; it is only part of it. A private key and address book make up the other parts (to prove ownership + rebuild connections).

[LeeteqXV]

THIS:

@trwnh wrote;

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

On Mon, Jun 25, 2018, 04:50 trwnh, [e-mail] wrote:

@remram44 https://github.com/remram44 Ah, my bad, I wasn't clear on the
differences between guid/uuid/etc. I've been using the terms in the most
generic sense possible (a globally unique user ID). Regardless, the
(256-bit) UID alone will not be enough to constitute an identity; it is
only part of it. A private key and address book make up the other parts (to
prove ownership + rebuild connections).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/177#issuecomment-399816036,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ASzGVPHX202nq-lBaTYtrL3OexJiSeVKks5uAFAIgaJpZM4K5Bba
.

[trwnh]

Addendum to the discussion with @remram44 about using public key hashes as UIDs: I don't think that would work in the current schema where every actor's public key is actually just the server's public key. Mastodon doesn't currently generate keypairs for every single actor. My proposal to start generating UIDs is to lay the groundwork for changes, not to be used immediately. That would allow cryptographic changes later on a server-to-server basis -- live migration is the more pressing thing to be tackled IMO, since offline migration requires per-actor keypairs.

[nightpool]

Mastodon doesn't currently generate keypairs for every single actor

what? this is incorrect. How are you coming to this conclusion?

[trwnh]

@nightpool examining the JSON output of two users on the same instance. I was mainly referring to server-server interactions and not client-server, because I have no idea how to examine what's happening privately. I may have overlooked something because I'm not perfectly familiar with how Mastodon generates all this stuff.

https://mastodon.social/@trwnh.json

"publicKey":{
"id":"https://mastodon.social/users/trwnh#main-key",
"owner":"https://mastodon.social/users/trwnh",
"publicKeyPem":"-----BEGIN PUBLIC KEY-----\nMIIBIjANBgk...-----END PUBLIC KEY-----\n"
}

https://mastodon.social/@gargron.json

"publicKey":{
"id":"https://mastodon.social/users/Gargron#main-key",
"owner":"https://mastodon.social/users/Gargron",
"publicKeyPem":"-----BEGIN PUBLIC KEY-----\nMIIBIjANBgk...-----END PUBLIC KEY-----\n"
}

[sireebob]

downloaded both and the public keys are different. some of the characters at the beginning and end are the same. that's standard

[nightpool]

@trwnh you're just seeing the framing of the internal binary encoding. the keys are completely different, they just share a similar structure (as do all pem-encoded asn.1 keys)

[trwnh]

@nightpool Ahhhh, okay yeah, I didn't check far enough, I just skimmed over the first and last few characters to see if they were the same. Whoops!

So, if keypairs are already generated for every actor/profile within Mastodon, that should be one less step to do. Assuming posts and private key are already included in the exported data (are they?) the last thing to do would be to pick/generate/assign/etc some sort of UID for each user, and then it should be "only" a matter of refactoring some logic and building the export/import tools.

I'm still not too sure of the advantages/disadvantages of picking a specific UID schema, per above -- the way I see it, defining a separate UID that isn't simply a hash of publicKey should allow for situations where the old key is repudiated or if the encryption hypothetically changed (e.g. in the future if/when more bits are needed for security) -- and the UID would still need to be connected to a keypair, so no changes there.

[blaine]

(I've skimmed previous posts, but there are a lot of them, apologies for any repetition)

fwiw, this is a big part of what we created webfinger for.

imho, the crypto approach is really complicated and anti-user. Do the same thing as HTTP, use [the equivalent of] a 301 redirect. If it's not in the standard, create a new one. ;-)

To be clear:

1. I choose to move from [email protected] to [email protected]
2. I tell the mastodon instance at mastodon.social to stop allowing posts there and to provide (in my mastondon.social profile) a redirect to [email protected].
3. Any other instances where people follow me at [email protected] should update their subscription to point to [email protected]
4. If I choose to migrate follower / followed lists, or even toots, that can be a separate API but (to the point of many here) migration is less important than portability, at least to start. Portability is a fundamental protocol requirement, portability is something that can be added later without core protocol support.

Note in the above, no new crypto is needed, all the security boundaries continue to work. There is an obvious hijacking exploit possible in the event that someone gains control of an account, so it would probably make sense to have a SHOULD clause for following user redirects that instructs federated servers to check back with the original server for some period of time (e.g., 30 days) to allow the original user to regain control and cancel the redirect. Again, this is an enhancement that could (should) be added later.

[neuoy]

This makes sense, really. I'd just like to point out (you are probably aware of it) that the drawback of this method is that it doesn't work if an instance permanently goes down. Still better than nothing.

To have a more complete feature (and I'm not suggesting this would be required for a first step), I believe cryptography is required, so that a user is able to prove that he owns the account on the defunct instance. Other instances would know the account public key, only the user knows his private key. And as long as the instance is up, he should be able to update the key pair (in case it gets lost or compromised), which means the public key can't be the account unique ID.

[trwnh]

AFAIK, key generation is done on the server already, so there aren't any specific client-side issues to solve -- migration would involve copying a key from one server to another. If the instance is live, the user can authorize with another server. If the instance is offline, the user can upload a backup.

The point of changing the keys is a good one, and also why I think there should be a separate 256-bit user ID generated (the sooner the better). By the time Mastodon 3.0 hits, the majority of the ecosystem should have a user ID, and code should have been refactored to refer to this ID instead of to a user/domain pair. https://github.com/tootsuite/mastodon/issues/177#issuecomment-399172654

[kevinmarks]

This naive faith in users' ability to do private key management is
touching.

On Wed, 15 Aug 2018, 08:41 trwnh, [e-mail] wrote:

AFAIK, key generation is done on the server already, so there aren't any
specific client-side issues to solve -- migration would involve copying a
key from one server to another. If the instance is live, the user can
authorize with another server. If the instance is offline, the user can
upload a backup.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/177#issuecomment-413119489,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGCwDG5mDsb9TUoPXVBCK0gdpiCjjcXks5uQ9CmgaJpZM4K5Bba
.

[trwnh]

@kevinmarks Why would the users have to do any key management? Like I just said, all key management is done transparently on the server already, and the server is already managing everything for the user. User-facing crypto would be an entirely separate issue.

[neuoy]

@kevinmarks @trwnh To make my thoughts clearer on that point, I also believe users should not have to handle their private key themselves, but having the possibility to do it would protect them against their instance unexpectedly shutting down. The private key would be proof of account ownership, they can delegate its handling to whoever they want (in exchange with password authentication for example). This would allow for additional assistance layers, such as instructing another instance to keep a backup for them.

I don't know any detail of the current protocol, this was just my two cents to answer @blaine about crypto not needed (in my opinion, it is needed, but only to solve the scenario where an instance goes down, which could be a second step in account migration functionality).

[nicostuhlfauth]

Hi all,
I think especially in a decentralized network like Mastodon it's necessary to have the option to migrate to a new instance without loosing the own toots, favs and followers. It just needs to work, no matter if the old instance is still running or not.

If it's not possible, it automatically pushes more users to a few instances, which they believe to be stable and running for a long time.

So as there are many, many people interested in Mastodon and Twitter alternatives for now and they're just signing up without understanding the concept of instances, let's solve this issue asap.

[lx4r]

I agree with @nicostuhlfauth that this should be solved immediately and would've proposed something similar to @blaine's solution, which sounds good to me. Problem: I don't know any Ruby, so now we just need an awesome person to implement this 🙂

[kevinmarks]

Rather than elaborate new id structures, what is stopping an instance doing a 301 redirect when a user that has migrated to another is requested?
Then the requesting instance can update the mapping from the local /user/[n] to the remote url to fetch and everything can carry on.
This was resolved in Websub with tests before shipping - is there some design difficulty with ActivityPub that precludes this?

[remram44]

@kevinmarks the problems are migrating followers, and recovering from the instance going down permanently. Signaling that a user has moved is already implemented.

[nicostuhlfauth]

By the way @remram44, do you know how the implemented moving works? Someone asked me a few days ago, but I found no documentation what actually happens when you enter your new user in the settings of the old server...

[dhowe]

status?

[offbyone]

@nicostuhlfauth see #5746 for that.

[MirceaKitsune]

I would very much like this feature as well. I'd like to register on multiple instances so I can properly explore each one, but due to the lack of an account syncing mechanism I'd have to like / boost / reply to / post / etc different things from each one which is rather bothersome. If any one instance went down or decided to ban an user, all of that user's activity and data would be lost. I truly hope the developers can find a way to implement cross-instance account synchronization so that users can mirror their activity across every account they have.

[pierstitus]

Wouldn't it make sense to be able to use a custom domain in your account ID? So you would sign up at mastodon.social and set up your own domain blabla.org (or md.blabla.org) pointing to mastodon.social, so you can use the ID @[email protected] without having to set up a server yourself.

When you want to migrate you change my DNS, and you can use the same ID on the new server. (You'd still have to migrate the data of course).

There's probably different technical ways of accomplishing the same, like serving the webfinger part from your own server. That way it's probably quite easy to use a free subdomain too if you don't have your own domain.

This way the ID provider can be separate from the main server, which is a very good idea (also read https://hackernoon.com/mastodon-is-dead-in-the-water-888c10e8abb1).

[JoshuaACNewman]

This issue has suddenly reached exactly the point we were discussing at the
top of the thread: with Tumblr and Facebook kicking out erotic, or even
medically-related sexual material, everyone from sex educators to comic
artists is suddenly finding themselves with no platform that doesn’t call
them ax traffickers.

This is serious. The point of the Fediverse is that you can’t stomp on a
single instance to kill a particular social circle.

But because profiles are still nonportable, it’s not true.

If profiles were fully portable, the US Government would have to play
whack-a-mole. Right now, any instance that hosts sexually-related material
is under threat, and that means its population is.

This is a canary in our coal mine situation. Mastodon either implements
this feature, or it just doesn’t work. Anyone who relies on their social
network for social or material support will be under threat.

|ζ•
On Thu, Dec 6, 2018 at 6:33 PM Piers Titus van der Torren <
[email protected]> wrote:

Wouldn't it make sense to be able to use a custom domain in your account
ID? So you would sign up at mastodon.social and set up your own domain
blabla.org (or md.blabla.org) pointing to mastodon.social, so you can use
the ID @[email protected] without having to set up a server yourself.

When you want to migrate you change my DNS, and you can use the same ID on
the new server. (You'd still have to migrate the data of course).

There's probably different technical ways of accomplishing the same, like
serving the webfinger part from your own server. That way it's probably
quite easy to use a free subdomain too if you don't have your own domain.

This way the ID provider can be separate from the main server, which is a
very good idea (also read
https://hackernoon.com/mastodon-is-dead-in-the-water-888c10e8abb1).

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/177#issuecomment-445069047,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AalEQ9336lWoEA_R3zRSJwvR6_BH2nAKks5u2alCgaJpZM4K5Bba
.

[MirceaKitsune]

@JoshuaACNewman I'm 100% behind your comment, well said. The past year has seen unprecedented rise in ancient morality and medieval attitudes toward NSFW content. Mastodon has the ability and expectation to defend those communities against such attacks on modern values.

The federated design of the system already does a great deal in this regard. But in my opinion it's not enough: If authoritarianism continues increasing the way it has been, ordinary users worldwide may become targeted by authorities, as is currently happening with large tech firms. They may thus be forced to shut down their instances or moderate them more strictly.

We must make it easier for users to migrate between instances, losing as little of their content and activity as possible in the process. Further more it should be easier to run instances across multiple servers rather than just one machine, though I think that's a subject for another issue.

[joepie91]

I fully agree with the last few comments made, in particular the notion that Mastodon is not really decentralized yet, due to the nonportability of accounts.

This issue is actually a blocker for me, and the sole reason I haven't given Mastodon a shot yet. Right now, a proprietary service like Twitter gives me better availability guarantees than any Mastodon host could, and there's no portability mechanism to compensate for that.

Edit: An additional note... in order to work even if the original instance goes down, account redirects must be cached, at the very least for the case where the original instance is no longer accessible. If the reference/redirect goes down whenever the original instance does, then it won't do anything to insure users against disappearing instances.

[offbyone]

One of the reasons that email is decentralized, if one has one's own domain, is that the DNS system is able to provide a pointer to the actual hosting system for the mail. The address is just a label whose eventual destination is determined by the MX records associated with the domain, and even then there is plenty of space for forwarding services to handle redirects.

The analogy isn't perfect, because the continuous stream of federated status updates will make that more complex, but, I can't help but think that maybe there's a case to be made for investigating a DNS record type that could be used to identify the "home instance" of a fediverse address?

This would, mind, probably need to be coordinated with other participants in the fediverse.

[MirceaKitsune]

As a reminder: I believe the focus should be not on one-time account migration, but also realtime account synchronization. If you own accounts on multiple instances, you should have the ability to mirror every activity on one account to all others, so whenever you do anything on an instance that action is mirrored onto all others. This can get a bit more complicated but I believe it would make users lives a whole lot easier if it can be achieved.

[offbyone]

@MirceaKitsune I'm disinclined on that focus, although I don't personally have any direct input into the direction of the project. My rationale here is that mirroring means that a user's content is removed from their control and distributed over the fediverse, including into places whose policies can change without warning. Moreover, it'll introduce a fragmented view of people's streams, since one instance may remove some toots that others keep. The complexity there, both from an implementation point of view and from a consumption point of view feels really difficult to manage. Then, let's take the additional step of crafting a UX for controlling which instances one's toots go to. It'd be an implementation and design challenge that far outstrips the much simpler "This id actually lives on this other instance" challenge.

[myersjustinc]

Agreed—the "where does this account live" question is much more fundamental and consequential.

I'd love to see us get to a point where Mastodon (and other ActivityPub services) can be hosted on a different domain than what outside users and services see—like how email does it (as @offbyone mentioned, using DNS MX records), or how OpenID delegation does it (using <meta> tags), or with the webfinger-based approach @pierstitus suggested. At that point, account migration theoretically can be a more transparent process for users who are using their own domains: Followers and other users interacting with your account don't even have to know at all that you've changed the instance where that account is hosted.

Of course, there'd be other issues if you're essentially renaming your account (i.e., changing domains), but there have been a lot of other good ideas in this thread about how to simplify _that_ workflow.

[judahnator]

I think we may be over thinking the problem.

Why not simply add the ability to import a downloaded archive? The federation feed spam problem can be resolved by simply making all public imported toots unlisted.

This way if your current host is having stability issues and you want to jump ship (kinda where I am at right now), or whatever reason, you can:

1. Use the existing data export feature to get an archive
2. Import that archive to a new host
3. Use the existing "Account Migration" feature to point your old profile at your new one.

[JoshuaACNewman]

Because that server can be shut down at any time and you lose your
audience and your connection to the rest of your community and have to
start over.

Please read the thread. Your use case is not what we’re talking about.
On Mon, Dec 10, 2018 at 11:56 AM Judah Wright [e-mail]
wrote:

I think we may be over thinking the problem.

Why not simply add the ability to import a downloaded archive? The
federation feed spam problem can be resolved by simply making all public
imported toots unlisted.

This way if your current host is having stability issues and you want to
jump ship (kinda where I am at right now), or whatever reason, you can:

1. Use the existing data export feature to get an archive
2. Import that archive to a new host
3. Use the existing "Account Migration" feature to point your old
   profile at your new one.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/177#issuecomment-445888863,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AalEQ-KkCamfUGb8_ki0WyKjDlo65ypVks5u3pJUgaJpZM4K5Bba
.

[judahnator]

It is precisely because that server can be shut down at any time that I believe my comment is relevant. I would like to be able to make periodic backups of my data that can be imported to any other server, so I do not lose my data.

I might lose my connections, followers, etc, but I wont lose the rest of my data. If my data is portable, then I am the owner of and the sole person responsible for my data, not my instance that could shut down at any moment.

Data portability is really the core of the issue here.

[offbyone]

@judahnator No, it's not. Please read the thread. What you're describing is important, but it's not what we're discussing here.

[myersjustinc]

To me, it's about _account_ portability, which includes both portability of data (@judahnator's concern) and portability of interactions (retaining followers, links (?) and other actions).

Data portability is the more straightforward of the two, but interaction portability is why this thread has gone on as long as it has: We have the opportunity to provide a better user experience than older federated platforms (e.g., email), so it's worth discussing what that might look like.

[MirceaKitsune]

Perhaps we could have an account grouping system as an alternative? This way an user can put all their accounts from every instance into one collection, and the system can display posts from those accounts together whenever you look at each specific one.

The issue I remember bringing up in another discussion a while ago, is that when you have multiple accounts it's hard to decide which to use for every given task. If I have account X on one instance and account Y on another instance, I'm constrained to either use X to follow some people and Y to follow others, or to randomly interact with some things from X and others from Y depending on which I open first. Those options are disorganized or create an additional burden for the user.

[joepie91]

I feel like account grouping is a different problem to solve. For Mastodon to meet (or exceed) the availability guarantees of Twitter, it needs to offer an unambiguous and simple "move your account to instance X" feature that Just Works without hassle, even if that seemingly partially duplicates behaviour of some other feature.

How it works under the hood is a separate matter of course, and quite possibly something can be designed to accommodate both usecases, but the ultimate goal from a UX perspective should be "one-click account migration without caveats".

[chucker]

What you're describing is important, but it's not what we're discussing here.

Given that we have neither one nor the other at this point (after years of discussion), maybe pure data portability deserves its own GH issue even if only as a pragmatic partial solution.

[trwnh]

It feels like discussion of this issue has drifted away from the how and back to rehashing the why (which IMO has been covered to death in the past 200 comments on this issue). See also: https://github.com/tootsuite/mastodon/issues/177#issuecomment-394147199

Since I last wrote out this 8-step plan ( https://github.com/tootsuite/mastodon/issues/177#issuecomment-399172654 ), the only new thoughts on short-term improvements would be to use the internal user numbers for routing URLs instead of usernames (e.g. an id of /users/14715 instead of /users/trwnh; the /@trwnh can remain as a url). This would allow, at minimum, username changes, while still remaining compliant with the requirement of ActivityPub id fields being dereferencable URIs. It would also make looking up users consistent with the Mastodon API, as well as with status ID generation using randomly-generated numbers (e.g. /users/trwnh/statuses/99664077509711321 becoming /users/14715/statuses/99664077509711321). Profile redirects could then be refactored such that mastodon.social/users/14715 could redirect to trwnh.com/users/1.

Aside from all this, the same two blockers remain since June 2018 or earlier: 1) identification is still bound to domain+username, and 2) old status URLs will break.

It might not be worth doing this work only to eventually replace it by globally unique UIDs (thereby solving blocker 1), but perhaps that isn't strictly necessary if the publicKey is used for authoritative identification? Ultimately, whatever ends up being used as an ActivityPub id can be dereferenced to whatever the software desires. If the public key is used for network-wide identification (paired with some signature to signal authenticity), then perhaps key rotation can be treated as a separate problem. As for the old URL issue, perhaps database links can be updated using an Announce activity to signal that a migration has occurred. Which is to say, a migration can be verified by signing a message that your account has movedTo another URI with the same public key, and the movedTo account can announce that it was formerlyKnownAs the old URI.

[MirceaKitsune]

As far as the identification issue goes, it still feels like that easiest solution is some sort of identity cloud; When you own two or more accounts across Mastodon instances, have the ability to point them to one another in each one's settings. If I have two accounts on two instances, I go to account 1 and send a linking request to account 2 or vice-versa, then from the other account's settings I respond to that request confirming that both are mine. This system can then be used for a variety of purposes:

1. First of all to better prove that you are indeed the same person. You can confirm your identity on one instance by giving it the okay from your account on other instances (on which you might already be known). It's less likely that a troll will register all over the network just to impersonate you.
2. It can be used for safe account migration, as well as syncing if that idea is ever considered. Each account could have an "import from this other account" option to copy its activity.
3. This can also be used to show combined information when viewing any one profile. For example, if browsing the activity of account X on instance 1, you could also see the activity of account Y on instance 2 in the same list.

Sorry if I further went beyond the scope of discussing just migration: This idea seems like a relevant step and may be important to bring up early.

[kevinmarks]

We have this now with the rel=me support.

On Thu, 13 Dec 2018, 12:19 Mircea Kitsune <[email protected] wrote:

As far as the identification issue goes, it still feels like that easiest
solution is some sort of identity cloud; When you own two or more accounts
across Mastodon instances, have the ability to point them to one another in
each one's settings. If I have two accounts on two instances, I go to
account 1 and send a linking request to account 2 or vice-versa, then from
the other account's settings I respond to that request confirming that both
are mine. This system can then be used for a variety of purposes:

1. First of all to better prove that you are indeed the same person.
   You can confirm your identity on one instance by giving it the okay from
   your account on other instances (on which you might already be known). It's
   less likely that a troll will register all over the network just to
   impersonate you.
2. It can be used for safe account migration, as well as syncing if
   that idea is ever considered. Each account could have an "import from this
   other account" option to copy its activity.
3. This can also be used to show combined information when viewing any
   one profile. For example, if browsing the activity of account X on instance
   1, you could also see the activity of account Y on instance 2 in the same
   list.

Sorry if I further went beyond the scope of discussing just migration:
This idea seems like a relevant step and may be important to bring up early.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/177#issuecomment-446949121,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGCwMclJ0tEm9maq-A87PpxCuib1v5uks5u4kXVgaJpZM4K5Bba
.

[MirceaKitsune]

As the lack of migration support continues to make itself felt, I wanted to share an idea: In the short term, would it be possible to add the ability to import at least just boosts and favorites?

My reasoning is: From what I understand, the reason why this is taking some time to decide on is because people fear impersonation. Boosts and faves carry a low risk in that regard; They barely identify you as an user, someone can't pretend to be you just by copying those items... not much more than by stealing the list of accounts you follow which is already importable. Unlike posts and uploads which are explicit forms of communication with your message on it.

Further more they don't seem to carry any complex metadata; The only attribute favorites and boosts seem to have (other than the post you faved / boosted) is the date. This would not matter as the importer would just generate automatic ones from the list thus they'd all have new dates (otherwise times could be easily forged). Later this can be done for posts too, but like I said just boosts and favorites could come first to pave the way and see how this goes.

[trwnh]

@MirceaKitsune it's less about impersonation of content and more about the load involved in switching, both cognitive and technical. signaling that an identity is the same is the easy part -- servers can authenticate with each other quite easily and do so all the time.

it's porting the content and followers that's the hard part. content is tied to URLs, which are necessarily going to change as part of the move. and followers have to be updated of the move, which puts strain on all the remote servers to update their links and databases as well. there isn't an appreciable difference between porting boosts and favs vs. porting original posts; in fact, porting original posts would be even easier, and wouldn't even necessitate a full migration! whereas porting boosts/favs is going to be tricky because you have to redeliver potentially thousands or millions of Announce/Like activities. it would bombard accounts all at once in a way that wouldn't be an issue when linking identities and simply rewriting old entries rather than purging and replacing them.

[MirceaKitsune]

As far as technical load is concerned, this would depend on the efficiency of the implementation; If you automate the process of re-faving / re-boosting the same things, meaning the server reads your list then runs a loop and sends signals to boost / fave everything for you, that's probably going to be slow. One workaround is to directly edit your profile database and concatenate the list you're importing, so the process adds the data in one move behind the curtains. Another route would be to do each boost / fave at a 10 second interval, which is slower than the activity level of some users thus less costly.

As far as causing an activity spike goes, I wouldn't regard that to be a major problem. It is the user's choice to import: If you're okay with 100.000 faves and boosts suddenly spamming your own account, that's your concern. The only issue I see here, apart from server resource usage which I addressed above, is notification spam for other users in case someone follows you already... for instance they may see 1000 new entries covering their Home timeline because of you. But especially since only new accounts are likely to use this, I doubt it's a major concern... and if anyone's bothered they can simply unfollow you for a few hours until the notifications are obsolete.

[pierstitus]

@trwnh Thats why it would be so wonderful to be able to use your own (sub)domain, and be able to link it to any server. Then you can change server while keeping your identity, and all the links would stay the same. Server migration then is just a DNS change (and some data transferring).

Only you end up with an identifier with two personal parts, which can be a bit silly, you'll get names like @[email protected] or @[email protected]

[comatory]

I just started using Mastodon and honestly the lack of migration options is a bit worrying. Decentralization should go all the way and this includes your post history. Could we at least get an option to export/import toots & favorites? That would be a good solution until the decision is made on how to do this properly.

[bjo81]

Exporting the ActiveSub-data works, but you cannot import it on the new instance.

[comatory]

Yes that's why I mentioned import also. I know I can get the data out but unfortunately can't import them on the new instance. I presume it's because there's the technical challenge with URLs of the content.

[Gargron]

I'd like to update everyone in the thread on current developments.

In 2.1 I added profile redirect notes. So you can configure your account to say "Now moved to [email protected]". It also prevents the old account from getting followers. But it's far from a complete solution, because your existing followers still have to be manually notified to re-follow the new account.

The procedure described in the OP (about implicitly showing posts from a new account to followers of the old account) is kind of simple, but I think, also unsatisfactory: If the old account disappears because the server goes down, you've lost those followers forever. And those followers are hidden from the new account, so your follower list/number is not accurate, which might be even creepy if you want to post something private and forget your old account is "mirroring" the posts to a wider audience.

So, I believe that actually making old followers re-follow the new account is the more desired outcome (although it is also full of risks, such as stressing the network with increased traffic, selling followers, etc).

2.7 will contain a handler for a Move activity. The account given as target will be checked for the old account in its alsoKnownAs property (to ensure you can't just send followers to random people without consent), and if it's there, the followers on the server will be re-assigned to the new account.

It's necessary to split the implementation of receiving/sending of this activity between releases. First, most of the servers need to upgrade to 2.7 (once it's out) before it makes sense allowing people to send the Move activity, otherwise it would just get ignored.

So I plan on implementing the sending part in 2.8 or 2.9 (depending on timing). And the action will likely be behind a long cooldown to prevent people from stressing the network through constant hopping between accounts.

I know that many here don't consider it a real migration unless the past content also moves along. I don't know if that is feasible, though. Posting a status is computationally expensive. Importing tens of thousands of posts is a huge task, and it's really hard to design it in such a way that both low-end servers and high-end servers can handle it without impacting the experience of active users.

[comatory]

@Gargron thumbs up for follower list migration.

I think I get the gist of the technical difficulties of migrating user's content. However if Mastodon wants to be a real replacement for Twitter and gives back ownership of data back to the users, it should also be possible to move your data elsewhere, somehow. But I know it's not an easy thing to do and from this thread I can see there are different approaches / understandings of this problem.

[MirceaKitsune]

@Gargron That sounds like a great first step toward migration support! In my opinion, having the ability to move your activity as well will be essential (media, toots, boosts, favorites). I posted a few suggestions above on how I assume it could be done without stressing the instance too much.

One was to make the import mechanism simply concatenate the database of the old account to the one of the new account, with some edits in case new post ID's or dates need to be generated. The hope is that this isn't more resource intensive than simply copying any large chunk of text. I imagine that even for your average active active user, their activity database (text-based post information without media) shouldn't exceed 10MB several years from now, something even a server with relatively lower resources would have an easy time time dumping into a database.

If that's not desired, another alternative is using a slow import process, where the target server receives and notes down the list of posts to import but only imports one every say 10 seconds (delay customizable per instance). The user may have to wait for a few hours or even days for the process to complete, but in the end it will finish and the server shouldn't be stressed noticeably.

[kevinmarks]

For migration, if the new server had anyone subscribed to the original,
they will already have recent posts (and media) cached. If you can
disambiguate by hash rather than url, then you can save a lot of copying.

On Fri, 18 Jan 2019, 14:10 Mircea Kitsune <[email protected] wrote:

@Gargron https://github.com/Gargron That sounds like a great first step
toward migration support! In my opinion, having the ability to move your
activity as well will be essential (media, toots, boosts, favorites). I
posted a few suggestions above on how I assume it could be done without
stressing the instance too much.

One was to make the import mechanism simply concatenate the database of
the old account to the one of the new account, with some edits in case new
post ID's or dates need to be generated. The hope is that this isn't more
resource intensive than simply copying any large chunk of text. I imagine
that even for your average active active user, their activity database
(text-based post information without media) shouldn't exceed 10MB several
years from now, something even a server with relatively lower resources
would have an easy time time dumping into a database.

If that's not desired, another alternative is using a slow import process,
where the target server receives and notes down the list of posts to import
but only imports one every say 10 seconds (delay customizable per
instance). The user may have to wait for a few hours or even days for the
process to complete, but in the end it will finish and the server shouldn't
be stressed noticeably.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/177#issuecomment-455558064,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGCwA_CCwretL5qLogM9fAtn0fNcbsrks5vEdXPgaJpZM4K5Bba
.

[MirceaKitsune]

Earlier today I discussed a bit how some of us are feeling the pressure of Mastodon lacking account migration. Others seem to agree that the current situation is starting to feel like a lottery: You pick an instance when you decide to join the network, often as a newbie who's not very familiar with the differences between important instances, then once you've established yourself you are pretty much stuck there. While I don't have major complaints against mastodon.social, I now find myself in a spot where I'd prefer using another instance primarily... however I cannot as I don't want to lose my now lengthy history of faves and boosts and replies, thus I'm glued to this instance until further notice.

I did some thinking and am curious if the following idea sounds like a viable compromise for the near future: Implement the ability to import faves / boosts / posts, but place it behind a setting and leave it disabled by default, the option documented to warn against potential performance or impersonation issues. I think this way everyone can have their fair slice of the cake: Instances that want to play it extra safe don't need to do anything and won't see any changes, whereas users who want to migrate will have a few options they can hop to among those instances that feel it's fine for them to enable it. Additionally this would be a safe stepping stone for testing how migration will work out across the network, in order to decide how it can be improved and when it might be safe to enable by default.

[tobek]

I may be a bit on extreme on this, but I hesitated using Mastodon at all because I couldn't decide on an instance and didn't want to put a lot of effort into one and then be stuck. After not getting around to researching enough to decide on an instance, I ended up not using Mastodon at all.

Account migration would allow messaging like "don't worry, you can always move to another instance later" which would mean less friction for new users joining: you could safely pick a default instance and later switch once you have a better idea.

[kevinmarks]

This guide is like a list of to do items for this issue
https://cafe.sunbeam.city/~/GwenfarsGarden/moving-instances-on-mastodon

On Wed, 30 Jan 2019, 22:19 Toby Fox <[email protected] wrote:

I may be a bit on extreme on this, but I hesitated using Mastodon at all
because I couldn't decide on an instance and didn't want to put a lot of
effort into one and then be stuck. After not getting around to researching
enough to decide on an instance, I ended up not using Mastodon at all.

Account migration would allow messaging like "don't worry, you can always
move to another instance later" which would mean less friction for new
users joining: you could safely pick a default instance and later switch
once you have a better idea.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/177#issuecomment-459132642,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGCwDjwKTbsqMOVLBsG5mJMAghzx0frks5vIhpYgaJpZM4K5Bba
.

[sandhawke]

Indeed. I didn't laugh out loud at "Note: at the time of writing this post, you cannot transfer your followers from one account to another" but only because I'm sitting in a library.

FWIW, I continue to think the right approach is a hot-backup strategy. You have a primary account, and you designate one or more hot-backup other accounts. They sync the data, and your followers see the hot-backups, too. If your primary is down or goes away, for whatever reason, they just start using the hot-backup account(s). This handles a wide set of use cases without even needing crypto.

[MirceaKitsune]

Another idea I wanted to share regarding a compromise option: We could add account migration as an on-request feature. This means that when an user wishes to migrate, they may contact the admin of the target instance through a form, attaching the exported archive of the old account while specifying both the source account (from which the archive originates) and the target account (to which they want it copied). They can also write a reason explaining who they are and why they're migrating. The mods then review the request taking a look at both accounts, approving or rejecting it based on whether everything seems to be in order. There would of course be a limitation so you can't spam admins with those requests, by default you could be allowed to only make one per month.

This should be a safe solution by far for an early implementation. An admin who wishes to be extra safe can ask you to confirm through your email address or social media that you are who you say you are, greatly reducing the risk of impersonation. They also verify that the person coming in is not a troll and their old account doesn't contain things the new instance wouldn't allow.

[SilverWolf32]

Why make it a manual request-it-from-an-admin thing?

I put off changing my Elite Dangerous username for months because I didn't want to bother support. I'm worried that this proposal would discourage people from moving/changing names because they don't want to waste anyone's time.

[JoshuaACNewman]

Everything that stands between a user and easy migration — particularly
asking for permission of an admin who then has to do work — damages the
mission of Mastodon.

I’ve been seeing the instance I’m on flounder because it had some technical
issues at one point and no one wanted to risk that one guy’s server going
down.

This dramatically affects adoption and makes any community that uses it
vulnerable to a single point of attack.

I don’t see why this isn’t a higher developmental priority.
On Sat, Feb 9, 2019 at 5:41 PM SilverWolf [e-mail] wrote:

Why make it a manual request-it-from-an-admin thing?

I put off changing my Elite Dangerous username for a long time because I
didn't want to bother support. I'm worried that this proposal would
discourage people from moving/changing names because they don't want to
waste anyone's time.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/177#issuecomment-462086000,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AalEQ4B4-cNbFN4eukNhcrSMh6KfZzsuks5vL06GgaJpZM4K5Bba
.

[MirceaKitsune]

@SilverWolf32 I got the impression there's still some uncertainty on how migration should be approached, thus I'm coming up with various ideas hoping it might make the process easier to approach. I wouldn't prefer such a manual solution either... if fear of impersonation or performance issues are what's holding back the feature, I figured this could be another option.

[hex-m]

Not sure if I missed something but I think using an external authentication/identity provider could help with this problem.

• If an administrator deletes you from her server you can prove to other instances (and your friends) that you are the same person.
• It's easier/cheaper to host an identity-server (less uptime necessary, low traffic) - good for the decentralization of the network.

But I fear that decoupling the user-ID from the instance that holds the content would mean changing the underlying protocol.

[MirceaKitsune]

Since we're still lacking options and this is a pressing matter, I wanted to ask an extra question in the meantime: If you're an instance owner yourself, is there currently any way to pipe an account backup archive into the database of your instance? I'm curious if even by using third-party scripts, it's possible to convert the data and re-create your account on your own server if needed. This would be helpful to know in the event of an emergency until migration is officially here.

[MirceaKitsune]

https://dtp-mstdn.jp/@noellabo/101828098636011880

Today brought us the sad news that one of the biggest Mastodon instances, friends.nico, will be shutting down due to financial difficulties. I understand this is the first time an important server goes down with potential to have a powerful impact on the fediverse. I sincerely believe this is a good reminder of why migration will rapidly become essential... as over time some instances inevitably disappear, and with them so will the activity of users who won't be able to take their history to any other server.

People fleeing a dying instance can download the full data of their account. But without a way to import it, that data will forever be lost somewhere on their hard drive. Users will likely start anew on another instance... everything they've done up to that point will never be read or interacted with again.

[Laurelai]

If people are worried about impersonation you could limit account migration to people who have two factor authentication on.

[SilverWolf32]

That sounds like it could be a good idea, but I'd be worried about people who either don't want to enable two-factor for whatever reason, or simply can't. It looks like you can't use plain email two-factor, and need some kind of phone app instead. But what if you don't want to get an app, or just don't have a phone? That could be a bit of a problem.

(Are there open-source desktop 2FA clients that work the same way as those phone apps?)

[Laurelai]

(Are there open-source desktop 2FA clients that work the same way as those phone apps?)

According to google yes. So it shouldnt be too much of an issue.

[trwnh]

you could also have people verify a move by sending them an email with a
link to authorize the move, if you were concerned about account hijacking
simply by obtaining a password to a mastodon account.

On Thu, Mar 28, 2019, 20:01 Laurelai [e-mail] wrote:

(Are there open-source desktop 2FA clients that work the same way as those
phone apps?)

According to google yes. So it shouldnt be too much of an issue.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/177#issuecomment-477825529,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKHXX5JeX5ci7YJut_m6jLrfGbl7V0Xcks5vbWYEgaJpZM4K5Bba
.

[MirceaKitsune]

Simplest way I can think of is having both accounts confirm each other as linked: You send a link request from one, the other must approve it... once both do you know they belong to the same person. This would be especially useful for realtime syncing, which would be even better than just manually being able to migrate an account on demand, but that's an idea for another ticket.

[SilverWolf32]

There's an idea! And I think we already have account identity-link confirmation.

Of course, all of these methods only work if the old server's still up at the time the person tries to import. I don't know how you'd handle the server just dying unexpectedly.

[ldexterldesign]

FYI

Hi all,

Thanks for software

Hope you're well

I choose not to own a (smart)phone (it's heaven)

I'm noticing more and more services are making it a requirement to:

a) own a (smart)phone so you can install "their app" or receive SMS
b) own a phone number so you can receive calls/voicemail

... under the guise of security (e.g. multi-factor authentication)

It's mostly (UK) banks and financial institutions but I just feel safer giving as little information away as possible and I know how to use a password manager. Not that I use Amazon any more but today I logged in, for the first time in a year, to update my password and they've essentially blocked account access because I can't pass their MFA test without a phone. It's ridiculous.

Even the most popular MFA software[s] I know requires you to own a smart phone:

There must be a better way 😩

Hope this helps

Regards

s: https://authy.com/

[trwnh]

having both accounts confirm each other as linked

imo what's actually more relevant is denoting that two profiles are linked -- there's no reason to tie it to account logic except for the fact that accounts and profiles are currently coupled 1:1. i know there's some reluctance to undertake the great amount of work necessary to make a proper migration actually work without creating too much load on all the servers involved, so the 2.7 Move logic deals purely with alsoKnownAs similarly to how link verification depends on rel="me" and with re-assigning followers to the new profile. there is altogether separate work that needs to be done to actually decouple accounts from profiles and thus allow multiple accounts to manage the same profile, or one account to manage multiple profiles.

[trwnh]

@ldexterldesign TOTP clients exist for desktops and not just mobile. I use Enpass to access TOTP from all of my devices, for example

[SilverWolf32]

(sorry for hijacking the thread...)

@ldexterldesign Oh, ugh. I didn't know Authy needed your phone number. If it helps, there's an open-source app called FreeOTP that I believe essentially does the same thing, with no third-party server component.

Still requires a phone, though. I've found what looks like an open-source desktop 2FA client app for Linux, but it doesn't seem to be in any big-name distribution's package repositories, and I can't find any online articles about it, so I don't know whether it's trustworthy or not. (: (https://github.com/paolostivanin/OTPClient)

@trwnh, do you happen to know of any good open-source ones?

[trwnh]

@SilverWolf32 I don't think TOTP should be necessary -- the use of email as a second factor aside from password is sufficient for preventing password-only hijacks. Either way, that's mostly an implementation detail about how to initiate an authorized Move.

---

Continuing from the last discussion: I've advocated pretty heavily for splitting identity, address, account, and profile precisely because it can help avoid some of the confusion around this stuff. You wouldn't even need to re-import thousands of statuses if the statuses had a unique ID in the database like Pleroma assigns. Here's a practical example: https://pleroma.site/notice/9hFWbYbAVSuXdieHOC

You can see this status is actually not from pleroma.site, but from the Mastodon instance radical.town instead! The key part is the 9hFWbYbAVSuXdieHOC which is the status ID. This status ID was generated internally to pleroma.site, and assigned to the internally-generated user https://pleroma.site/users/59843 as well. pleroma.site internally stores the remote URLs as well, linking to https://radical.town/users/starwall and to https://radical.town/users/starwall/statuses/101831614562020631.

Here's the important bit: Mastodon actually generates its own internal IDs as well, but crucially it does not expose these except via its own Mastodon API. For example, the profile with the url of https://mastodon.social/@Gargron has a uri of https://mastodon.social/users/gargron but is also https://mastodon.social/api/v1/accounts/1 via the API. So at some internal level, mastodon.social is keeping track of [email protected] as accounts/1. Each Mastodon instance also keeps track of remote accounts via the API, by necessity or else you couldn't fetch an existing account via the API. Example: https://mastodon.social/api/v1/accounts/773802 resolves to acct:[email protected].

The problem is that all of the internal account logic uses user@domain instead of the internal account ID. This means that if either the username or the domain name changes, all existing objects (statuses, profiles, etc) are now orphaned. But if all the account/status logic were rewritten to use the internal IDs then it would no longer matter exactly where the stuff is located. Both account and content migration would be as simple as a database update -- no need to re-fetch anything at all!

Let's construct a hypothetical scenario for how easy this might be in practice if none of the logic was as tightly coupled as it currently is:

• If mastodon.social's accounts/14715 is the same as toots.trwnh.com's accounts/1, then it is not strictly necessary to keep track of this information. All that is necessary is to update https://mastodon.social/api/v1/accounts/14715, specifically the url field from https://mastodon.social/@trwnh to https://toots.trwnh.com/@trwnh (or wherever my new home might be).
• A former status is already known to mastodon.social as https://mastodon.social/api/v1/statuses/100560344258327930 -- this status already has its account field set to the account with the ID of 14715. By updating account 14715 to the new location, the migration should automatically migrate the content as well (which is already known).
• If the status was imported, then the url of the status can be updated as well, to reflect that the content has been imported onto the new instance in case it needs refetching.
• Every server is free to do its own migrations using the already-existing account and status id system, in a similar way.

So the end result is that if I migrate with my 17,000 statuses, all servers aware of my account/statuses only have to update the url fields of the already-existing objects served via the Mastodon API. I'm not too sure about how costly such an operation would be, but I can bet it would be MUCH less expensive than re-fetching all the content as new objects, since it's working with data that already exists in the local database.

[kevinmarks]

If they're linked and follow each other then the servers should have all
the posts since the follow cached already

On Fri, 29 Mar 2019, 02:33 trwnh, [e-mail] wrote:

having both accounts confirm each other as linked

imo what's actually more relevant is denoting that two profiles are
linked -- there's no reason to tie it to account logic except for the fact
that accounts and profiles are currently coupled 1:1. i know there's some
reluctance to undertake the great amount of work necessary to make a proper
migration actually work without creating too much load on all the servers
involved, so the 2.7 Move logic deals purely with alsoKnownAs similarly
to how link verification depends on rel="me" and with re-assigning
followers to the new profile. there is altogether separate work that needs
to be done to actually decouple accounts from profiles and thus allow
multiple accounts to manage the same profile, or one account to manage
multiple profiles.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/177#issuecomment-477842823,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGCwLpKOIawM_3ImkmsrXQSLiO6N7rtks5vbXt2gaJpZM4K5Bba
.

[Mikaela]

(Are there open-source desktop 2FA clients that work the same way as those phone apps?)

I am using Bitwarden where it's premium feature.

I've found what looks like an open-source desktop 2FA client app for Linux, but it doesn't seem to be in any big-name distribution's package repositories, and I can't find any online articles about it, so I don't know whether it's trustworthy or not. (: (https://github.com/paolostivanin/OTPClient)

I don't know if you consider Flatpak/Flathub a big-name, but it's there as com.github.paolostivanin.OTPClient.

[ldexterldesign]

I'm noticing more and more services are making it a requirement to:

a) own a (smart)phone so you can install "their app" or receive SMS
b) own a phone number so you can receive calls/voicemail

... under the guise of security (e.g. multi-factor authentication)
https://github.com/tootsuite/mastodon/issues/177#issuecomment-477842399

https://arstechnica.com/information-technology/2019/10/twitter-used-phone-numbers-provided-for-2fa-to-match-users-to-advertisers

[SilverWolf32]

Why is this closed now? There's some great discussion here about moving posts, which would be _fantastic_, but as far as I know that's not implemented.

Should we open a new issue for that, then re-post any comments about it over there?

[copygirl]

Should we open a new issue for that, then re-post any comments about it over there?

Indeed, that would be ideal. It may result in some of the very constructive suggestions and feedback to (have to) be repeated, but it's not like that hasn't already happened in this thread. And it's easy to link back to this thread if someone wanted to look at the full discussion.

Keeping issues and feature requests small and/or split them up is generally great for developers.

[patcon]

Yeah! Please do feel free to help the maintainers do that work @SilverWolf32! Tending to and gardening the issue queue is a huuuuuge help!

[trwnh]

Follow up avenues that currently exist:

• Use local id for URIs and internal references (to break reliance on Webfinger) https://github.com/tootsuite/mastodon/issues/10745
• More robust handling of cases where username is reused or keys change (#12148)
• Support 301/302 redirect for migration (#8465)
• Clone/mirror content across accounts, with one account being primary (maybe #7715 or #9206 but not exactly)

[kevinmarks]

301 isn't temporary - that's the point of that issue. If you get a 301 it
means "use this, and remember it for the future" 302 is temporary - it
means "use this for now, but recheck here next time"

The point of using 301 is that it migrates readers as they fetch,
rather than having an out of band mechanism to force resubscribing.

On Mon, Oct 28, 2019 at 7:56 PM trwnh [e-mail] wrote:

Follow up avenues that currently exist:

• Use local id for URIs and internal references (to break reliance on
  Webfinger) #10745 https://github.com/tootsuite/mastodon/issues/10745
• More robust handling of cases where username is reused or keys
  change (#12148 https://github.com/tootsuite/mastodon/issues/12148)
• Support 301 temporary redirect for migration (#8465
  https://github.com/tootsuite/mastodon/issues/8465)
• Clone/mirror content across accounts, with one account being primary
  (maybe #7715 https://github.com/tootsuite/mastodon/issues/7715 or
  #9206 https://github.com/tootsuite/mastodon/issues/9206 but not
  exactly)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/177?email_source=notifications&email_token=AAAYFQBU4NXSRJMQL6PN7ELQQ47YRA5CNFSM4CXEC3NKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECOF5ZQ#issuecomment-547118822,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAYFQFEPZMXJYMEIJ7A263QQ47YRANCNFSM4CXEC3NA
.

[SilverWolf32]

Okay, I just opened a new issue about post migration! It's over at #12423.

[skywinder]

I try to search "how login with existing account to another mastodon federation" and got to this page.

Hi. Is it possible to sign in another federation by existing mastodon account? Passwords doest match. So what to do if registration for federation is closed?

[ryliejamesthomas]

No, that's not possible. It's likely they are different servers run by different people.

If registration is closed you will have to find another server to register on.

[copygirl]

@skywinder You should never use your sign-up details (such as username / email and password) on any site other than the one you registered on. A malicious site owner could steal your details. (Very unlikely to be the case, but it's important to know.)

Since Mastodon is federated – meaning different Mastodon instances / sites can communicate with one another – you should not need to register or log in to another instance. Simply follow who you want to follow, and their posts will appear in your timeline as if you followed someone on the same instance.

For example, clicking "Follow" on a user on masto.example, entering your username and domain of the instance you registered (such as [email protected]), and "Proceed to follow" will redirect you to your home instance for you to log in to confirm the follow. (Take note of the address bar saying https://mastodon.social/... rather than https://masto.example/....)

[patcon]

Request: can we collectively opt not to engage in semi-related support conversations in a 4yo ticket with ~100 followers? I feel for you @skywinder, and I love helping people too, but it truly should be happening elsewhere ❤️ 🙏