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
Merged

Add account migration UI #11846

merged 1 commit into from
Sep 19, 2019

Conversation

Gargron
Copy link
Member

@Gargron Gargron 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 added work in progress Not to be merged, currently being worked on activitypub Protocol-related changes, federation labels Sep 15, 2019
@Gargron Gargron force-pushed the feature-account-migrations branch 7 times, most recently from 2c81b7c to 7bad76e Compare September 15, 2019 21:37
@Gargron Gargron removed the work in progress Not to be merged, currently being worked on label Sep 15, 2019
@Gargron Gargron marked this pull request as ready for review September 15, 2019 21:38
@ClearlyClaire
Copy link
Contributor

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

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

@ghost
Copy link

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

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

@ClearlyClaire
Copy link
Contributor

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

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

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

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

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

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

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

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

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

Gargron 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 merged commit 3ed94dc into master Sep 19, 2019
@Gargron Gargron deleted the feature-account-migrations branch September 19, 2019 18:58
@MirceaKitsune
Copy link

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

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

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

@kyefox
Copy link

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

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

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

Gargron commented Sep 25, 2019

Oh, that's a very fair point.

@ClearlyClaire
Copy link
Contributor

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

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

- Change data export to be available for non-functional accounts
- Change non-functional accounts to include redirecting accounts
@wiktor-k
Copy link
Contributor

Ouch, it seems testing the early feature prevents me from migrating my mastodon.social followers now (Handle of the new account is the same account you have already moved to).

Would it be possible @Gargron to unblock the feature for my old account on mastodon.social? Thank you in advance!

@ClearlyClaire
Copy link
Contributor

Just reactivate that account, unset the redirection, and try again.

@wiktor-k
Copy link
Contributor

Oh, that worked. Thanks a log @ThibG!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
activitypub Protocol-related changes, federation
Projects
None yet
9 participants