Add Move activity for user migration
#2970
Conversation
* update User model to allow for moved_to and also_known_as values * allow users to add aliases (also_known_as) in UI * allow users to move account to another one (moved_to) * redirect webfinger to the new account after a move * present notification to followers inviting to follow at new account Note: unlike Mastodon we're not running any unfollow/autofollow action here: users can decide for themselves This makes undoing moves easier. TODO There is still a bug with incoming Moves, at least from Mastodon. This seems to be something to do with Update activities (rather than Move, strictly).
This comment was marked as resolved.
This comment was marked as resolved.
- minor template fixes - notification logic fixes - don't dedupe on moved_to or also_known_as - add migration
also cleans up some templates
hughrun
changed the title
Move activity for user migration
|
This one is great. @mouse-reeve I reviewed it and I would merge this. As this is a big one please do a review as well. Thanks! |
There was a problem hiding this comment.
This works really smoothly! My main question is about the additional notification model. I know that I've been the blocker on this PR, so I'm happy to consider my translation items non-blockers on merging this, and I can change them this weekend.
The bigger question (which again, I don't want to make a blocker), is how functional a moved account should be. I mentioned showing other parts of the UI in the comments, but I believe a moved account will also still receive updates to its activitystreams, and otherwise behave like a fully operational account. I suspect that's the correct behavior, because I think it is supposed to be possible to, for example, follow a moved account, and I think it would be challenging to re-build the activitystream if the user decided to un-move. However, it seems odd that a moved account can post statuses.
I definitely didn't mean to leave that ability in, oops. Basically I agree. See comment on your review - I really just wasn't sure what to leave available and what to block, and if I'm honest it seemed a bit complicated and I took an easy route. I agree: restoring accounts should be reasonably painless but other than that moved accounts should be essentially non-functional. I'll take a look at this and adjust the UI changes - it may make sense to just create a new template and redirect to that. |
- make Move notifications less complicated - moved users cannot do anything other than unmove or log out - refactor translations for moved users
|
With the changes I've made post-review, it should be that the only thing a |
There was a problem hiding this comment.
I can't for the LIFE of me figure out how to create a PR that merges into this PR and I don't want to keep making you make stupidly tiny changes to the blocktrans tag, so I'm going to merge this into a new branch and then commit my changes and then merge THAT branch in, which seems like a ridiculous way to do it but at least it will be merged
| <p> | ||
| {% id_to_username request.user.moved_to as username %} | ||
| {% blocktrans %} | ||
| <strong>You have moved your account</strong> to <a href="{{user.moved_to}}">{{ username }}</a> |
There was a problem hiding this comment.
This link doesn't resolve -- annoyingly, you can't access key value pairs in a blocktrans tag, so user.moved_to is undefined. You have to define the variable in the opening tag, like {% blocktrans trimmed with moved_to_url=user.moved_to %}. trimmed is also necessary or all the whitespace will be preserved in the translation file.
This is both a stand-alone PR and works in partnership with #2868 - migrating user data from one server to another is Step 1, but we then need a way to tell Fediverse servers that the user has moved: that's what this PR does.
Additionally, this will cover a gap where we're currently ignoring incoming
Movenotifications, including when e.g. a Mastodon user migrates from one server to another. This means those users effectively become orphaned from BookWyrm because we don't follow them to the new account.This largely follows the precedent set by Mastodon, since there is no ActivityPub standard for account migration, however there are a few differences.
Features:
Moveaction is received from any ActivityPub server;Moveactivity to followers when a user moves from one AP account to another;alsoKnownAs/also_known_asaka an alias;movedTo/moved_tovalue to the source accountFollowing behaviour:
Unlike Mastodon I've set this up so that followers are notified of the move but there is no action taken regarding following unless initiated by the follower (Mastodon auto-unfollows the old user and auto-follows the new user when receiving a
Moveactivity). Notifications have a button to follow the new account, but the user remains following the old account.This makes moves less high-stakes and provides more autonomy to the follower. It also spreads out load on servers when a popular user moves their account as follows/unfollows will happen at the speed other users see and act on notifications.
We could change this so that the button in the notification unfollows the old user as well - happy to take advice on that.
Context: