Defederation should make follower relationships inactive instead of removing them entirely

[ianh]

Pitch

When two servers defederate, the current behavior is to delete all follower/following relationships between users of those two servers. The proposal is: instead of deleting these relationships, the server should somehow mark them as inactive. This way the relationships can be restored if the servers re-federate or the user moves to a new instance.

Motivation

This proposal is motivated by recent events between mstdn.social and mastodon.art. The two servers suddenly defederated and then re-federated due to admin conflict. In the current system, users have lost the valuable information about who they followed and are left to piece it together themselves. If this proposal were to be implemented, their follow lists would have been restored as if nothing ever happened.

[Ancient123]

Imagine using an email service where one server temporarily blocks another due to spam, leading to everyone's contacts and previous messages with the other service being auto-deleted.... This is a bad current implementation for sure.

[tcely]

Addendum: you should see the reason why your follow relationship is inactive when viewing an affected account from your instance.

[renchap]

There is something about this in the roadmap:

• get notified when there is a server block and some relationships are deleted
• have a way to retrieve a list of your follows that have been deleted
• have a way to follow those again if the server block if removed.

[ianh]

The benefit of this proposal is that users don’t need to do any extra work to refollow people. Is there a reason you wouldn’t want to follow the same people again? If not, I think it would make sense for refollows to be automatic on re-federation.

[ClearlyClaire]

This way the relationships can be restored if the servers re-federate or the user moves to a new instance.

Exposing severed relationships to the end user on the blocking side is definitely worthwhile, and automatically restoring them as well, and some of those things are planned. However, I'd like to highlight some caveats:

• automatically re-issuing follow requests for severed outgoing follows is possible, but people having stopped following you because of the block cannot be automatically restored, at least without wider protocol changes that would need careful consideration
• automatically re-issuing follow requests may not necessarily advisable depending on the time frame between the suspension and the moment the suspension is reversed (in the case motivating this feature request, it is definitely the best course of action, but what if the suspension gets reversed after months of years? automatically restoring long-forgotten follow relationships may not be advisable)
• even the tracked severed follows will be lost if the admin decides to purge known data about the suspended domains (that is a separate action from suspension though)

[ianh]

Thanks for considering this proposal, and I’m glad to hear work in this area is planned!

[ClearlyClaire]

We have started work for this feature in #27511. The idea is to record lost relationships on some events (your admins suspending a remote user or server, you blocking a remote domain), notify affected local users, and allow them to download lists of those, which in case of broken outgoing follows, can be imported straight away in this or another server.

Longer term, we plan to allow one-click re-follow when the block is lifted.

This isn't entirely satisfactory for recovering lost followers, though. We do have some ideas, but this will be a longer term ordeal.

[ianh]

Awesome, thanks for the update! I do still think it would make sense to put “lost follows” in the same list as normal follows, export them at the same time, and re-establish them automatically—if I click the follow button and don’t unfollow/block a user/domain myself, I would expect them to stay in the list of users I follow. Having to download separate lists for each relationship-severing event seems like a pain. But this would definitely be an improvement!

[ShadowJonathan]

@ClearlyClaire If i spot correctly, #27511 currently only works with outgoing domain blocks (local blocking remote), correct?

Would it be possible to spot an incoming domain block (remote blocking local)?

[renchap]

We have ideas on how to achieve this, basically "archiving" relationships that were severed by the remote instance, and then, of the remote instance unblocks you, it sends an Invite AP message for every severed relationship. Your instance can check that there is a record proving that this relationship was severed by the remote instance, and re-instanciate it.

[ianh]

Just following up on ShadowJonathan's comment, I think it would be very confusing if different events were to cause different things to happen to the data. Imagine instance A blocks instance B, then decides to unblock it again. How will you explain to the affected users what to do? This is the type of step-by-step instruction that will have to be passed around:

If you're on instance A, then go into "Follows and followers > Severed relationships", find the "Server suspension (instance B)" event, then click "Download" on lost follows. Go to "Import and export > Import", choose "Following list" from the dropdown, and upload the file you just downloaded. If you're on instance B, sorry about that -- you'll have to rebuild your list yourself, since we don't track blocks from other servers.

Ideally the process would be simpler overall (the "archiving" concept sounds promising!), but from the user's perspective, it feels weird to have to understand the details of which server caused the relationships to be severed, especially if one direction results in data loss vs data preservation.

[nemobis]

automatically re-issuing follow requests for severed outgoing follows

I don't understand why this would be necessary. If an incoming/outgoing follow is deactivated, the server can simply stop honoring it by ignoring/skipping incoming/outgoing activities.

Why would that be problematic with the existing protocol? It's not even mandatory to have followers/following collection https://www.w3.org/TR/activitypub/#followers , and only the rejection of a follow must be honored, according to https://www.w3.org/TR/activitypub/#follow-activity-inbox

In the case of receiving an Accept referencing this Follow as the object, the server SHOULD add the actor to the object actor's Followers Collection. In the case of a Reject, the server MUST NOT add the actor to the object actor's Followers Collection.
Sometimes a successful Follow subscription may occur but at some future point delivery to the follower fails for an extended period of time.

[renchap]

When there is an instance-level block, all relationships are deleted from the database tables. There is no notion of "disabled follow".

Our plan is to store those relationships in a separate table, and if the block is removed, re-issue the follow requests.

[nemobis]

Il 27/12/23 13:49, Renaud Chaput ha scritto:

There is no notion of "disabled follow".

...and I thought introducing it was the point of this request. Making the removal easier to reverse is ok as workaround for the most common use case.

[ClearlyClaire]

automatically re-issuing follow requests for severed outgoing follows

I don't understand why this would be necessary. If an incoming/outgoing follow is deactivated, the server can simply stop honoring it by ignoring/skipping incoming/outgoing activities.

Why would that be problematic with the existing protocol? It's not even mandatory to have followers/following collection https://www.w3.org/TR/activitypub/#followers , and only the rejection of a follow must be honored, according to https://www.w3.org/TR/activitypub/#follow-activity-inbox

In the case of receiving an Accept referencing this Follow as the object, the server SHOULD add the actor to the object actor's Followers Collection. In the case of a Reject, the server MUST NOT add the actor to the object actor's Followers Collection.
Sometimes a successful Follow subscription may occur but at some future point delivery to the follower fails for an extended period of time.

There are scenarios when this is needed. For instance, consider the following one:

• alice@a is followed by bob@b and eve@b
• instance a suspends eve@b without suspending the whole of b
• alice@a posts followers-ony posts

To (very significantly for accounts with a large following) cut down on network traffic, Mastodon sends the message only once to b's sharedInbox, with a to field with alice@a's follower collection. instance b then distributes the posts to alice@a's known followers on b. If we don't sever the follow relationships, that includes eve@b even though they have been suspended on a's side.