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

Migrate account UI #10736

Open
Gargron opened this issue May 9, 2019 · 3 comments

Comments

Projects
2 participants
@Gargron
Copy link
Member

commented May 9, 2019

The last remaining step of account migration is the form that would trigger the Move event to be sent out. I imagine it would be something like this: New server has an "Import account" link, which takes you to OAuth authorization on the old server. The new server then uses the REST API to:

  1. Set the new account's alsoKnownAs value
  2. Copy over data like favourites, blocks, mutes, and the rest
  3. Trigger the Move event on the old server

It's important to save the timestamp of the performed action and prevent any repeats of it for a long time (1 month?) on both the old and the new servers.

@Gargron Gargron created this issue from a note in v3.0 (To do) May 9, 2019

@Gargron Gargron added the TODO label May 10, 2019

@mynameismonkey

This comment has been minimized.

Copy link

commented May 13, 2019

Could the prevention mechanism be moderate-able such that instance admins could manually approve a prevented repeat action? e.g. "I don't like it here I really wish I was back at instance X", "I didn't know what I was doing I want my old account back", "I was testing to see if you really let me move all my content"...

Or maybe just a less restrictive control, maybe three days cool-down before repeat allowed.

@Gargron

This comment has been minimized.

Copy link
Member Author

commented May 15, 2019

Or maybe just a less restrictive control, maybe three days cool-down before repeat allowed.

I have estimated in #9629 just how much traffic and processing a single move would generate. It's not good. That's why harsh cooldowns are required. It's serious business.

@mynameismonkey

This comment has been minimized.

Copy link

commented May 16, 2019

This may be over-thinking it, but could the cooldown be a function of the anticipated workload? In your example, a million requests to the network I understand the need to keep that amount of traffic in check. But I would guess the vast majority of accounts have significantly fewer followers (sorry, I can't find stats for this), and I further guess smaller accounts may have greater need to be "mobile" and be more willing or needing to move.

If we took your example N and M, multiplied them by an arbitrary factor (e.g. 2) and add a minimum (all-user) cooldown period (e.g. 7 days), for your account we get (5N*2)+259200 = 2604800s which leads to the UI message "If you choose to move, you will not be able to move again for ~30 days", but if an account with 2,000 followers (anecdotally seems to be a good average) makes the same move handler request they would get something more like a week and change cooldown warning.

This would allow some flexibility for smaller accounts while keeping larger accounts in check. What it does not do is disincent your anticipated problem of building a large account and selling it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.