activitypub icon indicating copy to clipboard operation
activitypub copied to clipboard

Server-side atomic unsubscription

Open kaniini opened this issue 6 years ago • 11 comments

Right now, several implementations (Mastodon, Pleroma) force an unsubscribe by sending a Block activity followed by an Undo activity referencing that block over the wire.

This is problematic for a couple of reasons:

  • Whether Block should actually ever be federated itself is under-specified (the "blocks must never be delivered to the target inbox" language under the C2S section) (but, Block must be federated in order to perform the unsubscribe right now).

  • Block followed by Undo is not an atomic operation and therefore the relationship can wind up in limbo where the target server thinks their actor is blocked when it really isn't.

  • Block followed by Undo depends on the target having the same semantics for blocks as the rest of the fediverse (a dubious proposition at best).

It would be nice to see a proper Unsubscribe activity to replace the use of Block followed by Undo for unsubscription notifications. Or perhaps Undo.Follow where the original Follow activity is referenced.

cc @Gargron @nightpool @lambadalambda

kaniini avatar Mar 19 '19 00:03 kaniini

Hi! So I remember I talked about this with... it was either @Gargron or @nightpool but I don't remember which. Anyway we eventually realized that there's no reason you can't send a {Reject {Follow}} later, even after an Accept had been made in the past. That seemed like the most elegant solution. What do you think?

cwebber avatar Mar 19 '19 01:03 cwebber

Yes, I think Reject.Follow would work to tear down the relationship.

kaniini avatar Mar 19 '19 01:03 kaniini

Testing shows that Pleroma already accepts Reject.Follow to do this, incidentally. Now the question is what other implementations do? And when can we switch to that for unsubscribes? :)

kaniini avatar Mar 19 '19 01:03 kaniini

semantically i'd say that Undo Follow makes sense when you are unfollowing someone, while Reject Follow makes sense when you are preventing someone else from following you. so they'd describe operations in opposite directions.

trwnh avatar Mar 19 '19 01:03 trwnh

To be absolutely clear, this case is for when you are unsubscribing someone else from your own actor.

kaniini avatar Mar 19 '19 01:03 kaniini

mastodon currently supports reject.follow

nightpool avatar Mar 19 '19 02:03 nightpool

I believe we also support undo.accept.follow

nightpool avatar Mar 19 '19 02:03 nightpool

Nice. Do you know what version of Mastodon this has been supported since? I'd like to organize a flag-day to switch to reject.follow instead of soft-blocking to do unsubscribes, as it's rather fragile for reasons discussed above.

kaniini avatar Mar 19 '19 02:03 kaniini

Reject -> Follow is supported since 2.3.0, and Undo -> Accept -> Follow since 2.5.0.

puckipedia avatar Mar 19 '19 02:03 puckipedia

I think it would be reasonably safe to swap to Reject.Follow then in the short term. It'd be nice if we could get this documented as the proper way of announcing that a user has been unsubscribed.

kaniini avatar Mar 19 '19 02:03 kaniini

We talked about this in the meeting today and we're going to push forward {Reject {Follow}} as a recommended way of doing things in the editor's draft since there seems consensus about that. I'll assign myself to that task.

cwebber avatar Apr 10 '19 15:04 cwebber