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
Comments
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. |
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. |
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. |
This would be really cool! We were actually just discussing this! It would be nice if
Does Mastodon have a way to queue this to a moment when traffic is low? |
Fix #10736 - Change data export to be available for non-functional accounts - Change non-functional accounts to include redirecting accounts
Fix mastodon#10736 - Change data export to be available for non-functional accounts - Change non-functional accounts to include redirecting accounts
Fix #10736 - Change data export to be available for non-functional accounts - Change non-functional accounts to include redirecting accounts
Fix #10736 - Change data export to be available for non-functional accounts - Change non-functional accounts to include redirecting accounts
Fix mastodon#10736 - Change data export to be available for non-functional accounts - Change non-functional accounts to include redirecting accounts
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:alsoKnownAs
valueMove
event on the old serverIt'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.
The text was updated successfully, but these errors were encountered: