Support for Move activities targeting Actors

helene commented

2022-08-27 01:41:54 +00:00

Contributor

Account migration is a reoccuring issue. To alleviate this issue, many instance software (Mastodon, Pleroma, probably others like GoToSocial, Zot, ...) implement and support Move activities targeting actors, emitted by an actor, signalling a Move from an actor to the other.

In current implementations, the Move target actor's alsoKnownAs field is checked to see if the source actor's ID is contained; and if it is, actors receiving the activity (typically, the source actor's followers) will either be notified of the move, or automatically unfollow the source account and follow the target account, or both.

I believe it would be useful for FoundKey to support this activity type, though the manner in which you decide to implement it for the end user depends on your preferences and ideas.

Account migration is a reoccuring issue. To alleviate this issue, many instance software (Mastodon, Pleroma, probably others like GoToSocial, Zot, ...) implement and support Move activities targeting actors, emitted by an actor, signalling a Move from an actor to the other. In current implementations, the Move target actor's `alsoKnownAs` field is checked to see if the source actor's ID is contained; and if it is, actors receiving the activity (typically, the source actor's followers) will either be notified of the move, or automatically unfollow the source account and follow the target account, or both. I believe it would be useful for FoundKey to support this activity type, though the manner in which you decide to implement it for the end user depends on your preferences and ideas.

👍 2

Johann150 commented

2022-08-28 16:37:10 +00:00

Owner

see also https://github.com/misskey-dev/misskey/issues/5475 and https://github.com/misskey-dev/misskey/issues/8690

Johann150 added this to the (deleted) project 2022-08-28 16:37:35 +00:00

toast commented

2022-09-01 13:05:00 +00:00

Owner

I'm not sufficiently familiar with the database yet to really comment on that.
Re: 5475 I agree with the "automatically follow setting".

Here's how I see this feature as an overview:

It's intended as a feature to minimize friction between people that already would have done this.
The use cases are:
a) full migration (move activity) where the user does not intend to use the old account anymore
b) alt creation (no one implements this) where the user creates a secondary account that is intended to be the same in scope as the primary (I'm excluding different-purpose accounts)

As per 5475, I would have a more generalized "auto accept follow" and "auto follow" behavior.
Auto accept follow would include any profiles that match an already following profile in "alsoKnownAs" (regardless of move activity / similar) - people ticking this can be considered to explicitly trust their followers.

Similarly, auto-follow could handle more than just (verified) move activities, but any sort of activitity suggesting a new follow (such as use-case b) as long as it is verified via "alsoKnownAs".

As for automatic unfollows, they do make sense in use-case a to make following/follow list shorter.
A better approach to it (from a high level, this is hard to implement database-wise) would be an "automatic cleanup" button (with a confirmation, explaining why various accounts would be "cleaned").

B is out of scope here, and I'm mostly expanding on my thoughts on the subject, but I would probably implement it as an Announce from the origin Actor with the object being the new Actor (as a link, thanks json-ld).
The reason for the Announce (rather than, say, an Offer to follow) is that it's explicitly public. This would allow servers that want to do this to also handle their blocks internally. (Also see: Move, which doesn't need to be targetted).

I'm not sufficiently familiar with the database yet to really comment on that. Re: 5475 I agree with the "automatically follow setting". Here's how I see this feature as an overview: It's intended as a feature to minimize friction between people that already would have done this. The use cases are: a) full migration (move activity) where the user does not intend to use the old account anymore b) alt creation (no one implements this) where the user creates a secondary account that is intended to be the same in scope as the primary (I'm excluding different-purpose accounts) As per 5475, I would have a more generalized "auto accept follow" and "auto follow" behavior. Auto accept follow would include any profiles that match an already following profile in "alsoKnownAs" (regardless of move activity / similar) - people ticking this can be considered to explicitly trust their followers. Similarly, auto-follow could handle more than just (verified) move activities, but any sort of activitity suggesting a new follow (such as use-case b) as long as it is verified via "alsoKnownAs". As for automatic unfollows, they do make sense in use-case a to make following/follow list shorter. A better approach to it (from a high level, this is hard to implement database-wise) would be an "automatic cleanup" button (with a confirmation, explaining why various accounts would be "cleaned"). B is out of scope here, and I'm mostly expanding on my thoughts on the subject, but I would probably implement it as an Announce from the origin Actor with the object being the new Actor (as a link, thanks json-ld). The reason for the Announce (rather than, say, an Offer to follow) is that it's explicitly public. This would allow servers that want to do this to also handle their blocks internally. (Also see: Move, which doesn't need to be targetted).

Johann150 commented

2022-09-02 12:24:28 +00:00

Owner

b) alt creation (no one implements this) where the user creates a secondary account that is intended to be the same in scope as the primary (I'm excluding different-purpose accounts)

I don't think that is what a Move is intended for, hence why nobody implements that.

A better approach to it (from a high level, this is hard to implement database-wise) would be an "automatic cleanup" button (with a confirmation, explaining why various accounts would be "cleaned").

Mmh, not really a fan.

B is out of scope here

Yes because it does not seem to have anything to do with Move activities.

I think what we should probably do for a Move activity is:

refresh user info, as you can already do manually
do auto-(un)following stuff

Of course the part about refreshing user info would additionaly have to include the alsoKnownAs stuff.

I already laid out what I think should be done regarding (un)following and the technical implementation in this comment on the Misskey issue.

> b) alt creation (no one implements this) where the user creates a secondary account that is intended to be the same in scope as the primary (I'm excluding different-purpose accounts) I don't think that is what a `Move` is intended for, hence why nobody implements that. > A better approach to it (from a high level, this is hard to implement database-wise) would be an "automatic cleanup" button (with a confirmation, explaining why various accounts would be "cleaned"). Mmh, not really a fan. > B is out of scope here Yes because it does not seem to have anything to do with `Move` activities. - - - I think what we should probably do for a Move activity is: 1. refresh user info, as you can already do manually 2. do auto-(un)following stuff Of course the part about refreshing user info would additionaly have to include the `alsoKnownAs` stuff. I already laid out what I think should be done regarding (un)following and the technical implementation in [this comment on the Misskey issue](https://github.com/misskey-dev/misskey/issues/5475#issuecomment-1131339000).