Support account migration #177
Comments
|
A "redirected account" field would also be very useful for renaming accounts within a single server. |
|
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. |
|
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 edit: or I guess a |
|
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. |
|
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. |
|
I wonder if this is something other OStatus implementations would be interested in. |
|
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. |
|
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 |
|
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. |
|
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. |
|
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. |
|
Why is it hard to migrate followers? Can't the new system just point to the people on the old system. |
|
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 : my 2cts. (gonna have a lot of cents if we all add up) |
|
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. |
|
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. |
|
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. |
|
Well, there's two ways (in my mind) of fixing the problem:
|
|
@TehShrike This issue is about moving between Mastodon instances, not from Twitter to Mastodon. |
|
Ah, I googled-and-skimmed too quickly >_< I'll delete that post. |
|
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. 👋 |
|
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. |
|
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. |
|
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. |
|
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. |
|
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?) |
According to google yes. So it shouldnt be too much of an issue. |
|
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 ***@***.***> 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
<#177 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKHXX5JeX5ci7YJut_m6jLrfGbl7V0Xcks5vbWYEgaJpZM4K5Bba>
.
|
|
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. |
|
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. |
|
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 ... 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 |
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 |
|
@ldexterldesign TOTP clients exist for desktops and not just mobile. I use Enpass to access TOTP from all of my devices, for example |
|
(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? |
|
@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 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 The problem is that all of the internal account logic uses 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:
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 |
|
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, ***@***.***> 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
<#177 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGCwLpKOIawM_3ImkmsrXQSLiO6N7rtks5vbXt2gaJpZM4K5Bba>
.
|
I am using Bitwarden where it's premium feature.
I don't know if you consider Flatpak/Flathub a big-name, but it's there as com.github.paolostivanin.OTPClient. |
|
|
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? |
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. |
|
Yeah! Please do feel free to help the maintainers do that work @SilverWolf32! Tending to and gardening the issue queue is a huuuuuge help! |
|
Follow up avenues that currently exist:
|
|
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 ***@***.***> wrote:
Follow up avenues that currently exist:
- Use local id for URIs and internal references (to break reliance on
Webfinger) #10745 <#10745>
- More robust handling of cases where username is reused or keys
change (#12148 <#12148>)
- Support 301 temporary redirect for migration (#8465
<#8465>)
- Clone/mirror content across accounts, with one account being primary
(maybe #7715 <#7715> or
#9206 <#9206> but not
exactly)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#177>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAYFQFEPZMXJYMEIJ7A263QQ47YRANCNFSM4CXEC3NA>
.
|
|
Okay, I just opened a new issue about post migration! It's over at #12423. |
|
I try to search 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? |
|
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. |
|
@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 |
|
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 ❤️ 🙏 |
and others
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:
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:
This is just my 2c on how I think this should work, but I'm interested to hear other people's thoughts.
The text was updated successfully, but these errors were encountered: