Add account migration UI #11846
Add account migration UI #11846
Conversation
Gargron
added
work in progress
Gargron
force-pushed
the
feature-account-migrations
branch
7 times, most recently
from
2c81b7c
to
7bad76e
Compare
|
(Haven't actually reviewed it yet, just looking at the whole “deactivates most account functions” thing) It is common for people to move to a new account and keep the old one for backup in case something goes wrong with the new instance (assuming they are changing instances). This would prevent this use case. |
|
As I wrote the option to re-activate the account remains. It's just weird when an account that cannot be followed and does not show up in searches posts or follows people. If you disable the redirect again, it's fully usable again. |
|
|
as mentioned previously: will old followers-only posts remain accessible after the move? it would seem that the "alias" UI could be used to check those accounts too, and perhaps it opens up some interesting avenues for future mirroring functionality, but right now there's a bit of confusion due to the fact that posts are currently not moved. |
|
afaik, the cost is computational, and is proportional to the number of followers one has when migrating them (that's one message to each follower's instance, then one unfollow per follower to the old account's instance, and one follow per follower on the new account's instance), which means the cost is actually very variable, but it's hard to convey how. That being said, if the I'm still not fully ok with the whole “make people unfollow the old account” thing, both because of the “backup account” use case I talked about, and because it would mean losing access to older followers-only toots. Finally, I think Mastodon is the only ActivityPub implementation implementing |
|
The reason for the cooldown is both social and technical. It generates a lot of network traffic as described in the linked #9629. Lack of cooldown and other penalties would allow the proliferation of the business of selling (real) followers. Lack of unfollowing of the old account by the recipients would make that business ever more lucrative as you could duplicate followers to as many buyers as you wanted. I consider these protections to be paramount. Mind that there is currently no cooldown on the alias part. This is because I think the use case of consolidating multiple alt accounts to a new primary one is common and legitimate, although it too carries the risk of paying for followers from other people. As the old account is unfollowed, access to private posts from that account is lost. In my personal usage patterns, access to posts older than a day, let alone private ones, is an astronomically rare necessity. I understand that some people probably do it. For those cases, my answer is: You don't have to use this feature. You may just manually post asking people to follow some other account as well like the years prior. Some other answers:
As written in the OP, after moving you keep the ability to fully re-activate that account in case you change your mind. You also keep the ability to export data or delete that account.
Under some conditions the Move handler will not fire and the follower(s) will keep following the old account. This depends on whether That is not great and I think the Move handler should be fixed to account for this case and making sure that the follow succeeds before unfollowing instead of the other way around. (1)
This is true. I'm not sure how bad it really is, because after all, people move manually all the time without any Move activities involved, so this could be seen as progressive enhancement. But, in conjunction with (1), perhaps this UI should remain inaccessible in the next release, until those two things are sorted out. |
|
I agree that the use of Move here is really progressive enhancement as far as federation is concerned—although I'd like to post something akin to an Intent to Ship to the new Socialhub forum when it's available. haven't looked at the ux yet, planning on doing a thorough review tonight |
app/models/account_alias.rb
Outdated
| end | ||
|
|
||
| def add_to_account | ||
| account.also_known_as.push(uri) |
There was a problem hiding this comment.
push doesn't seem to work. uri is not saved.
There was a problem hiding this comment.
Thanks! It's because push/<< mutates the same object, so Rails doesn't notice the attribute has changed. Instead, a new array must be created and attribute set to it.
Gargron
force-pushed
the
feature-account-migrations
branch
from
7bad76e
to
654f46d
Compare
I'm sorry, I was looking at the very first version of that code. This is already handled properly now. |
But you're not the one who gets to decide whether your friends do a Move. The force-unfollow happens entirely without your input, which makes it more like a softblock. It may be rare in your personal usage patterns, but for me I follow a lot of people who post primarily / exclusively private posts. If one of them were to initiate a Move, then I would lose access to those posts. All I would be able to hope for is that none of them do. The only thing that would assuage my concerns here is if followers-only posts remained accessible to the target of migrated accounts, I guess. Or if posts were independent of profiles and the attribution could be changed / disambiguated (but this requires a very intensive refactoring). Or if messages addressed to you were stored in your inbox rather than handled with ACLs, and you could actually browse your inbox (which would probably be a complication of UX). I also am not entirely clear how the force-unfollow is done. Is it done on the migrator's side or on the follower's side? |
|
This seems kinda ewie tbh, someone moves to a new account and i automatically follow their new account? Dont i get any say in who i follow? Hows that gonna affect people when @Emily stops posting and @bonergrinder starts showing up in their home timeline? This aside, how does this handle migrating blocks? If i move from @tom to @tommy then will people who blocked @tom automatically block @tommy? |
|
Automatic follower migration is the cornerstone of #177. If people were OK with followers who are currently inactive, afk, or not paying attention to messages on their screen being lost, then announcing new account via a manual post (or mass DMs as some people do) would be more than enough and no further action on my part would be required. |
|
Okay but what about an opt out? I dont want to be automatically unfollowing or following accounts just cuz someone decided that im gonna follow their new one. And will this migrate blocks also? Not your blocks but the people who blocked you. |
|
I don't know if I would say the same about #177 -- yes, the original post deals with auto-follow, but it also calls for no auto-unfollow. It can be summed up as a profile redirect where following the old account shows you posts from the new account; undoing the redirect returns everything to normal. There's also a good deal of later discussion about content migration in case of downed servers, which is the other half of a "true" migration. It would be a shame to stop at unfollow-and-follow and call it done, because there's a lot of other things that migration entails that have nothing to do with follows. Functionally, there's also the question of what a migration is, in its idealized form. This usually falls into one of two paradigms: export-import, and redirect. Considering that the current logic heavily deals with the profile redirect feature, I'd say Mastodon is currently ignoring the export-import paradigm (aside from extraneous things like blocks and mutes and follows). Also, there's the question of whether the new account is an entirely separate profile, or if the profile can be migrated as well; Mastodon's schema currently forces the former and obviates the latter. It's probably too late to do anything meaningful about this for 3.0, so I'd have to say that my most pressing concern in the interim is the loss of private posts. Perhaps the other things can be hashed out for a future 4.0 release... |
|
One smol suggestion regarding rate limits: plenty of people have been around the fediverse for a while, and that means lots of accounts from trying different instances. Is there any way to make an exception for people with older accounts? Like maybe if one of the source or target accounts was made before the release that added Move, they could have no limit or a substantially reduced limit. New fedinauts would hopefully not accumulate so many accounts with the option to merge as they move around. |
|
@kyefox The "new" side doesn't have limits currently, so you can consolidate as many old accounts as you want into one. |
Fix #10736 - Change data export to be available for non-functional accounts - Change non-functional accounts to include redirecting accounts
Gargron
force-pushed
the
feature-account-migrations
branch
from
654f46d
to
4087d78
Compare
|
This sounds very good! But what about migrating your posts boost and favorites? That was a main issue with the lack of account migration: Everything you've done up until that point would be lost with your old account and people had no way of copying all their activity over! Also what happens if someone needs to migrate after their old account has been banned and its contents deleted? The data is no longer there. Does this come with the ability to import the data from archives exported from the https://instance.social/settings/export menu? |
|
I've discussed various methods of content transfer with @ThibG but we think that the performance cost is a showstopper on that part. |
|
If an invalid character string is entered in the account alias old account, a 500 error occurs. |
|
I don't know if this should be a comment here or an issue, but: my mastodon.social account has long been redirected. With the update, I can no longer open mastodon.social links while logged in. It sends me to the account settings page. This is a reasonable and valid thing to do for an account no longer in use since logging out would be the next step, especially now that I can eventually move followers, but it took me a while to figure it out even knowing about the update. A notice at the top explaining the redirect when coming from a permalink page might be wise. |
|
Did you find the link to where you can disable the redirect? It should be right next to your account’s status |
|
I just used migration to move followers from my old account on mastodon.social. This works great but I noticed the new account received follow requests only from followers other than these on mastodon.social. It seems like other servers got Move activity from mastodon.social (and that's good) but mastodon.social didn't process the move itself. New account didn't get any Follow requests from mastodon.social during this process. Is this a known issue or am I holding it wrong? :) |
|
Oh, that's a very fair point. |
|
Also, maybe the |
Fix mastodon#10736 - Change data export to be available for non-functional accounts - Change non-functional accounts to include redirecting accounts
|
Ouch, it seems testing the early feature prevents me from migrating my mastodon.social followers now ( Would it be possible @Gargron to unblock the feature for my old account on mastodon.social? Thank you in advance! |
|
Just reactivate that account, unset the redirection, and try again. |
|
Oh, that worked. Thanks a log @ThibG! |
Fix #10736, fix #177, fix #6955, fix #8003
The account migration page provides a way to enter a target account, which is then not only set as the redirect banner on the current account, but which is also announced to all current followers using the
Moveactivity, the handler for which has been introduced in #9629 (in 2.7.0). Because of the high cost of this operation, this action is permitted only once every 30 days.Previously accounts marked as moved were not followable, but otherwise functional. However, it seems inappropriate that a "ghost" account like that continues posting or following other people, so a notable change is that performing an account migration deactivates most account functions. The functions that remain are exporting data, changing account settings, deleting the account, and disabling the redirect (which re-activates the account).
For a migration to be possible, the new account must reference the old account. This purpose is served by the account aliases page, which allows entering and saving an old account's handle. So the steps to moving from one account to another is: