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 handler for Move activity #9629

Merged
merged 1 commit into from Dec 29, 2018

Conversation

@Gargron
Copy link
Member

commented Dec 26, 2018

See: #177, #6955, #8003

Traffic

My guesses about the traffic patterns of this feature:

Given N as the number of followers on the original account, and M (M <= N) as the number of separate servers those followers are on.

  1. The Move activity is distributed to M inboxes
  2. M servers access the new account via account resolution
  3. N accounts send unfollow activity to the old server
  4. N accounts send follow activity to the new server
  5. N accept-follow activities are distributed from the new server to the new followers

Categorizing the workload by servers goes as such:

  • The old server has to make inbox deliveries M times and process N incoming activities (Simplified: 2N)
  • The new server has to answer M queries and process N incoming activities, then send out N activities more (Simplified: 3N)
  • Each server that has any followers of the old account must process 1 incoming activity and send out 2 * (x / N) activities. In some cases this includes the old and new servers, so this could add on top of their workloads as well.

Let's imagine a large account decides to move - me. At the time of writing, that's roughly N=200,000. That means the old server has to process 400,000 Sidekiq jobs, the new server has to process 600,000 Sidekiq jobs.

That is to say, that's a lot of Sidekiq jobs, and a lot of traffic. For this reason I believe that the UX around the account migration feature should be incredibly strict, to prevent multiple uses by the same person (across servers, too) as much as possible.

Risks

It allows potentially amassing a large following for a brand new account from multiple smaller parts. Kind of like that large Mastodon power ranger mech assembling from the smaller ones, or that game where you are a bubble that eats other bubbles to grow larger. Amass a number of followers, then sell your account to someone who is willing to pay for them. (Consider that I primarily view this risk not from the perspective of high follower counts being desireable, but from the perspective of being able to put a message on many people's home feeds).

Risk mitigation

On the old server side, it is easy to add a cooldown (perhaps permanent!) on sending out Move activities. On the new server side, it is required to add the old account's URI to an "also known as" attribute, otherwise the Move activities won't validate anywhere (i.e. both old and new accounts have to point at each other). So it is possible to put a cooldown on updating that attribute, as well.

However, those precautions can be patched out by a malicious admin (or non-Mastodon software), i.e. the risk of massive follower accumulation from different sources remains.

End notes

Just as a disclaimer since it may not be obvious, this PR, in any case, does not include any UIs for performing Move activities in any capacity. For this feature to be effective, the UIs cannot be released until most of the Mastodon servers in the wild have upgraded to a release that includes this Move handler.

@nightpool nightpool self-requested a review Dec 26, 2018

@Gargron Gargron force-pushed the feature-move branch from 935f035 to 77cfe87 Dec 26, 2018

@Gargron Gargron force-pushed the feature-move branch from 77cfe87 to 925ec5a Dec 27, 2018

@chartier

This comment has been minimized.

Copy link

commented Dec 28, 2018

Thank you so much for spending more time on this. I feel like it’s the last major roadblock for getting more friends on here.

Just this morning I had yet another friend really interested in trying Masto and hopefully moving to it. But he’s unfamiliar with the mechanics of instances and spooked out at the prospect of losing followers if he has to move. “I’ll wait until they fix that then.”

If you could use help beta testing, I recently switched instances. I was on .cloud with ~ 850 followers, am now on toot.cafe with ~ 360. I’d love to bring the rest of those over.

@Gargron

This comment has been minimized.

Copy link
Member Author

commented Dec 28, 2018

If you could use help beta testing

Unfortunately, you won't be able to test this until all the servers where you have followers will have this patch, by which point testing it will be useless.

@trwnh

This comment has been minimized.

Copy link
Contributor

commented Dec 29, 2018

  1. N accounts send unfollow activity to the old server

I'm concerned this means that old followers-only content will become inaccessible. Unless content is also moved over, or if the privacy code checks for relations with the alsoKnownAs/movedTo, maybe?

@Gargron

This comment has been minimized.

Copy link
Member Author

commented Dec 29, 2018

Unfollowing the old account is a crucial safety mechanism. Otherwise there's gonna be a business of selling followers, not just once to one person, but to as many people as are willing to pay.

@ykzts
ykzts approved these changes Dec 29, 2018

@Gargron Gargron merged commit 0f938ff into master Dec 29, 2018

11 checks passed

ci/circleci: build Your tests passed on CircleCI!
Details
ci/circleci: check-i18n Your tests passed on CircleCI!
Details
ci/circleci: install Your tests passed on CircleCI!
Details
ci/circleci: install-ruby2.3 Your tests passed on CircleCI!
Details
ci/circleci: install-ruby2.4 Your tests passed on CircleCI!
Details
ci/circleci: install-ruby2.5 Your tests passed on CircleCI!
Details
ci/circleci: test-ruby2.3 Your tests passed on CircleCI!
Details
ci/circleci: test-ruby2.4 Your tests passed on CircleCI!
Details
ci/circleci: test-ruby2.5 Your tests passed on CircleCI!
Details
ci/circleci: test-webui Your tests passed on CircleCI!
Details
codeclimate All good!
Details

@Gargron Gargron deleted the feature-move branch Dec 29, 2018

@ThibG

This comment has been minimized.

Copy link
Collaborator

commented Dec 30, 2018

I understand your concerns, but I'm really uneasy with the unfollow part… especially with the code attempting to unfollow, then attempting to follow, possibly failing in the process.

I wonder if we really need fully-automated migration? What about some kind of notification giving user the choice to follow the new account and (separately) unfollow the old one?

@nightpool

This comment has been minimized.

Copy link
Collaborator

commented Dec 30, 2018

Yeah, after looking closely at this, a fully-automated unfollowing that removes access to previously accessible follower-only content is going to be really surprising for most people. Let's fix this in a follow-up before release—probably by making it it partially automated, like @ThibG suggests

ThibG added a commit to ThibG/mastodon that referenced this pull request Jan 2, 2019
ThibG added a commit to ThibG/mastodon that referenced this pull request Jan 2, 2019
@Kjwon15

This comment has been minimized.

Copy link
Contributor

commented Jan 4, 2019

I think that unfollowing part should changed.

  1. Not every server is Mastodon.
    If follower is on non-mastodon server(or older version of Mastodon), unfollowing is never happened.
  2. If original account concerns about privacy, Use Block-Unblock(or something) to force remove followers. And it should be checkboxed option for migrator.
ThibG added a commit to ThibG/mastodon that referenced this pull request Jan 10, 2019
@Gargron Gargron referenced this pull request May 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.