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

Add account migration UI #11846

Merged
merged 1 commit into from Sep 19, 2019

Conversation

@Gargron
Copy link
Member

commented Sep 15, 2019

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 Move activity, 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:

  1. Log in to new account, create alias to old account's handle
  2. Log in to old account, perform account migration by entering handle of new account

image

image

image

@Gargron Gargron force-pushed the feature-account-migrations branch 7 times, most recently from 2c81b7c to 7bad76e Sep 15, 2019
@Gargron Gargron marked this pull request as ready for review Sep 15, 2019
@ThibG

This comment has been minimized.

Copy link
Collaborator

commented Sep 15, 2019

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

@Gargron

This comment has been minimized.

Copy link
Member Author

commented Sep 15, 2019

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.

@ykzts
ykzts approved these changes Sep 16, 2019
@your-friend-alice

This comment has been minimized.

Copy link

commented Sep 16, 2019

  1. can a "moved" account still delete individual posts? this sort of post-move cleanup activity could be useful
  2. can a "moved" status still be revoked? (nevermind, explained in the screenshot)
  3. is the rate limit of 30 days configurable by the instance admin? is the cost you describe computational or social? if social, it's worth considering that that cost varies by community.
  4. how do followers handle the Move activity if the target instance is blocked (either by themself or their instance admin)?
  5. beyond "seems inappropriate", are there specific threats / abuse vectors you wish to mitigate by disabling account functions on "ghost" accounts?
@trwnh

This comment has been minimized.

Copy link
Contributor

commented Sep 16, 2019

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.

@ThibG

This comment has been minimized.

Copy link
Collaborator

commented Sep 16, 2019

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 Move does work, the number of followers of the account should drastically lower, so a second Move should be much less expensive.

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 Move activities that way? We discussed it a bit when first implementing it, but I don't think we ever reached out to other implementors…?

@Gargron

This comment has been minimized.

Copy link
Member Author

commented Sep 16, 2019

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:

Can a "moved" account still delete individual posts? This sort of post-move cleanup activity could be useful

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.

How do followers handle the Move activity if the target instance is blocked (either by themself or their instance admin)?

Under some conditions the Move handler will not fire and the follower(s) will keep following the old account. This depends on whether ActivityPub::FetchRemoteAccountService returns nil or not. In recent versions of Mastodon accounts from suspended domains are not resolved, thus returning nil. That is the best case. Older versions, or accounts that are already in the database but suspended, the old account will be unfollowed and the new one will not be followed.

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)

Finally, I think Mastodon is the only ActivityPub implementation implementing Move activities that way? We discussed it a bit when first implementing it, but I don't think we ever reached out to other implementors…?

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.

@nightpool

This comment has been minimized.

Copy link
Collaborator

commented Sep 16, 2019

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

end

def add_to_account
account.also_known_as.push(uri)

This comment has been minimized.

Copy link
@noellabo

noellabo Sep 16, 2019

Contributor

push doesn't seem to work. uri is not saved.

This comment has been minimized.

Copy link
@Gargron

Gargron Sep 16, 2019

Author Member

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 Gargron force-pushed the feature-account-migrations branch from 7bad76e to 654f46d Sep 16, 2019
@Gargron

This comment has been minimized.

Copy link
Member Author

commented Sep 16, 2019

Older versions, or accounts that are already in the database but suspended, the old account will be unfollowed and the new one will not be followed.

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)

I'm sorry, I was looking at the very first version of that code. This is already handled properly now.

@trwnh

This comment has been minimized.

Copy link
Contributor

commented Sep 16, 2019

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.

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?

@ghost

This comment has been minimized.

Copy link

commented Sep 17, 2019

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?

@Gargron

This comment has been minimized.

Copy link
Member Author

commented Sep 17, 2019

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.

@ghost

This comment has been minimized.

Copy link

commented Sep 17, 2019

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.

@trwnh

This comment has been minimized.

Copy link
Contributor

commented Sep 17, 2019

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

@kyefox

This comment has been minimized.

Copy link

commented Sep 18, 2019

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.

@Gargron

This comment has been minimized.

Copy link
Member Author

commented Sep 18, 2019

@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 Gargron force-pushed the feature-account-migrations branch from 654f46d to 4087d78 Sep 19, 2019
@Gargron Gargron merged commit 3ed94dc into master Sep 19, 2019
2 checks passed
2 checks passed
build-and-test Workflow: build-and-test
Details
codeclimate 1 fixed issue
Details
@Gargron Gargron deleted the feature-account-migrations branch Sep 19, 2019
@MirceaKitsune

This comment has been minimized.

Copy link

commented Sep 19, 2019

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?

@Gargron

This comment has been minimized.

Copy link
Member Author

commented Sep 19, 2019

I've discussed various methods of content transfer with @ThibG but we think that the performance cost is a showstopper on that part.

@noellabo

This comment has been minimized.

Copy link
Contributor

commented Sep 19, 2019

If an invalid character string is entered in the account alias old account, a 500 error occurs.

@kyefox

This comment has been minimized.

Copy link

commented Sep 22, 2019

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.

@Gargron

This comment has been minimized.

Copy link
Member Author

commented Sep 22, 2019

Did you find the link to where you can disable the redirect? It should be right next to your account’s status

@wiktor-k

This comment has been minimized.

Copy link
Contributor

commented Sep 25, 2019

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? :)

@Gargron

This comment has been minimized.

Copy link
Member Author

commented Sep 25, 2019

Oh, that's a very fair point.

@ThibG

This comment has been minimized.

Copy link
Collaborator

commented Sep 25, 2019

Also, maybe the Move handler should bypass follow requests when both the follower and the target account are on the local instance

hiyuki2578 added a commit to ProjectMyosotis/mastodon that referenced this pull request Oct 2, 2019
Fix tootsuite#10736

- Change data export to be available for non-functional accounts
- Change non-functional accounts to include redirecting accounts
hiyuki2578 added a commit to ProjectMyosotis/mastodon that referenced this pull request Oct 2, 2019
Fix tootsuite#10736

- Change data export to be available for non-functional accounts
- Change non-functional accounts to include redirecting accounts
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants
You can’t perform that action at this time.