Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support account migration #177

Closed
hach-que opened this issue Nov 22, 2016 · 263 comments
Closed

Support account migration #177

hach-que opened this issue Nov 22, 2016 · 263 comments

Comments

@hach-que
Copy link

@hach-que hach-que commented Nov 22, 2016

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
Copy link

@nex3 nex3 commented Nov 22, 2016

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

@Gargron
Copy link
Member

@Gargron Gargron commented Nov 22, 2016

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
Copy link
Author

@hach-que hach-que commented Nov 22, 2016

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
Copy link

@nex3 nex3 commented Nov 22, 2016

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
Copy link

@nex3 nex3 commented Nov 23, 2016

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
Copy link
Contributor

@hikari-no-yume hikari-no-yume commented Dec 6, 2016

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

@marrus-sh
Copy link
Contributor

@marrus-sh marrus-sh commented Dec 7, 2016

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
Copy link

@hoodieak hoodieak commented Dec 15, 2016

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
Copy link

@hoodieak hoodieak commented Dec 15, 2016

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
Copy link

@hoodieak hoodieak commented Dec 15, 2016

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
Copy link

@0ln 0ln commented Apr 3, 2017

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
Copy link

@Maverynthia Maverynthia commented Apr 3, 2017

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

@gdurelle
Copy link

@gdurelle gdurelle commented Apr 4, 2017

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
Copy link

@0ln 0ln commented Apr 4, 2017

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
Copy link

@Sadzeih Sadzeih commented Apr 4, 2017

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
Copy link
Contributor

@Motoma Motoma commented Apr 4, 2017

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
Copy link

@cyphar cyphar commented Apr 4, 2017

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
Copy link

@cyphar cyphar commented Apr 4, 2017

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

@TehShrike
Copy link

@TehShrike TehShrike commented Apr 4, 2017

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

@cdata
Copy link

@cdata cdata commented Apr 4, 2017

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
Copy link

@stiell stiell commented Apr 4, 2017

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
Copy link

@cyphar cyphar commented Apr 4, 2017

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
Copy link

@cdata cdata commented Apr 4, 2017

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
Copy link
Contributor

@ddevault ddevault commented Apr 4, 2017

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.

@SilverWolf32
Copy link

@SilverWolf32 SilverWolf32 commented Mar 29, 2019

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
Copy link

@Laurelai Laurelai commented Mar 29, 2019

(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
Copy link
Contributor

@trwnh trwnh commented Mar 29, 2019

@MirceaKitsune
Copy link

@MirceaKitsune MirceaKitsune commented Mar 29, 2019

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
Copy link

@SilverWolf32 SilverWolf32 commented Mar 29, 2019

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
Copy link

@ldexterldesign ldexterldesign commented Mar 29, 2019

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:

Screenshot 2019-03-29 at 03 11 11

There must be a better way 😩

Hope this helps

Regards

s: https://authy.com/

@trwnh
Copy link
Contributor

@trwnh trwnh commented Mar 29, 2019

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
Copy link
Contributor

@trwnh trwnh commented Mar 29, 2019

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

@SilverWolf32
Copy link

@SilverWolf32 SilverWolf32 commented Mar 29, 2019

(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
Copy link
Contributor

@trwnh trwnh commented Mar 29, 2019

@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 gargron@mastodon.social 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:dankwraith@monads.online.

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
Copy link

@kevinmarks kevinmarks commented Mar 29, 2019

@Mikaela
Copy link

@Mikaela Mikaela commented Mar 29, 2019

(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
Copy link

@ldexterldesign ldexterldesign commented Oct 10, 2019

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)
#177 (comment)

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

@SilverWolf32
Copy link

@SilverWolf32 SilverWolf32 commented Oct 27, 2019

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
Copy link

@copygirl copygirl commented Oct 28, 2019

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
Copy link

@patcon patcon commented Oct 28, 2019

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
Copy link
Contributor

@trwnh trwnh commented Oct 28, 2019

Follow up avenues that currently exist:

  • Use local id for URIs and internal references (to break reliance on Webfinger) #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
Copy link

@kevinmarks kevinmarks commented Oct 29, 2019

@SilverWolf32
Copy link

@SilverWolf32 SilverWolf32 commented Nov 18, 2019

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

@skywinder
Copy link

@skywinder skywinder commented Sep 12, 2020

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
Copy link

@ryliejamesthomas ryliejamesthomas commented Sep 12, 2020

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
Copy link

@copygirl copygirl commented Sep 12, 2020

@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 skywinder@mastodon.social), 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
Copy link

@patcon patcon commented Sep 12, 2020

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 ❤️ 🙏

@tootsuite tootsuite locked as resolved and limited conversation to collaborators Sep 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

You can’t perform that action at this time.