-
-
Notifications
You must be signed in to change notification settings - Fork 6.9k
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
Profile redirect notes #5746
Profile redirect notes #5746
Conversation
@@ -9,6 +9,7 @@ class ActivityPub::Adapter < ActiveModelSerializers::Adapter::Base | |||
{ | |||
'manuallyApprovesFollowers' => 'as:manuallyApprovesFollowers', | |||
'sensitive' => 'as:sensitive', | |||
'movedTo' => 'as:movedTo', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should you really use ActivityStreams' namespace for that? I couldn't find any documentation for “movedTo”
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made it up since it doesn't exist, but probably should exist. @cwebber is okay with it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, that's fine with me.
I'm wondering if it would make sense to redirect webfinger queries, too. |
|
@Gargron yeah, indeed, that's what I was thinking. Since the content is still there, it kind of makes sense to not stop it from federating. The advantage is that it would be completely transparent to whichever software, OStatus or ActivityPub, supporting “movedTo” or not. The downside is that it would stop the content of the old profile from federating anymore, although it's still there… it's probably not worth it, I guess. |
Another thing I'm wondering about and you haven't brought up in this PR is make every follower of the old account automatically send a follow request to the new one (and potentially unfollow the old one) once it's discovered to have moved. |
@ThibG No that's not at all included in this PR. |
Yes, I know, I was simply wondering if doing that would make sense.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not very familiar with React.js, but everything else looks fine to me.
<div className='account__moved-note'> | ||
<div className='account__moved-note__message'> | ||
<div className='account__moved-note__icon-wrapper'><i className='fa fa-fw fa-suitcase account__moved-note__icon' /></div> | ||
<FormattedMessage id='account.moved_to' defaultMessage='{name} has moved to:' values={{ name: <strong dangerouslySetInnerHTML={displayNameHtml} /> }} /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't it better if the name was a link to the new account?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's the old name
* Serialize moved accounts into REST and ActivityPub APIs * Parse federated moved accounts from ActivityPub * Add note about moved accounts to public profiles * Add moved account message to web UI * Fix code style issues
* yarn manage:translations * Add Japanese translation for mastodon#5087 * Add Japanese translation for mastodon#5616 * Add Japanese translation for mastodon#5746 * Add Japanese translation for mastodon#5750
One step further. Awesome! |
See also #177 (partial)
Please mind that this PR does not include the automatic followers unfollow/re-follow of new account, nor does it include a way to actually set this "move" information, yet. Therefore, it's only one step towards solving #177