snarfed
On opt out, delete user in bridged networks
When we bridge someone, and then they opt out, we should proactively delete their bridged accounts in all other networks, eg send an AP Delete activity to all followers' instances.
One difficulty here is that we need to deliver the Delete only to followers in the given network, which Protocol.receive isn't currently set up to do. Maybe add a target_protocol kwarg there?
You may want to broaden this and send it to all known instances on the network, since accounts can become cached somewhere just by searching for them.
That is indeed how Mastodon does it!
I'm actually curious how broad their "known instances" is. For an arbitrary instance that discovers an actor purely by searching, you'd need to extract the instance host from the HTTP user agent, which is unreliable at best. (Or the HTTP Signature's keyId, which is better, but only some instances sign their fetches.)
Regardless, Bridgy Fed isn't set up to do this right now, but you're right, it's a good idea.
The extreme answer here is all ~25k known instances, a la #552 and https://fedidb.org/ and https://fediverse.observer/stats#pod_growth , but that feels too extreme and heavy.
One difficulty here is when someone bridges their account, then un-bridges it, then re-bridges it. Current fediverse servers may not let us delete an actor and then recreate it with the same id.
Ideally we should test with a bunch of them. Whee. Alternatively, for now, we could document loudly that once you've un-bridged an account, you can't re-bridge it.
Still figuring this out in Bluesky too: https://github.com/bluesky-social/atproto/discussions/2503
I think the expectation on the fediverse is that ids may be reused, but not necessarily by the same identity. (You should probably throw away the AT-did if you receive a remote 'Delete' for this reason, if you normally hold onto it when unbridging. You should still receive the remote 'Delete' even while an account isn't currently bridged.)
Mastodon for example doesn't reserve the username, but severs all relationships irretrievably. (However, note that Mastodon sets a database lock for up to two hours, which may prevent the account from being re-created too quickly… not really a problem since it'll just get re-pulled after that, but if you e.g. try to restore follows, since they'd still exist on the AT side, that could cause some weirdness for a few hours before it settles.)
Misskey sets a flag. I didn't see anything that would indicate this actually prevents updates to the user, but also didn't see anything explicitly clear it.
This definitely is a very destructive action to be triggered by an unfollow though.
Since Bluesky is getting DMs, the imo best¹ course of action would be to make this two-tier:
If you receive an undo-follow, then delete bridged content and account info (you could do a reddit and replace their info with "[removed]" - "This user has stopped bridging their content to the fediverse.", or just clear it out as much as possible), but keep relationships and the account itself intact. Confirm that this is happening via DM, and instruct to block to 'irreversibly' sever the identity. You could still try to recreate it after that, but with no guarantees that it'd be fully functional on all remote servers.
If you receive a block, then 'Delete' the bridged account outright.
¹ very much not accounting for the amount of post, boost and like deletes you'd have to send out individually for a soft opt-out, though.
I think the expectation on the fediverse is that ids may be reused, but not necessarily by the same identity.
Wow, that's surprising. Usually not a good idea for all sorts of reasons, especially in security/auth contexts like this. 🤷 https://www.w3.org/wiki/SocialCG/ActivityPub/Authentication_Authorization
Otherwise, yeah, the UX mismatch here is difficult. It's very easy to block, unblock, and re-follow the bot user. If we can't undelete a bridged account, users will end up doing something they can't undo. 😕 Fortunately we have a lead on undelete-able delete for Bluesky, at least. As for the fediverse, sounds like I need to do some tests.
I think the expectation on the fediverse is that ids may be reused, but not necessarily by the same identity.
Wow, that's surprising. Usually not a good idea for all sorts of reasons, especially in security/auth contexts like this. 🤷 https://www.w3.org/wiki/SocialCG/ActivityPub/Authentication_Authorization
In practice, most fediverse software does reserve handles on delete, but yeah, it's very much possible for admins to release them, and there is nothing on the protocol level that really enforces that level of uniqueness. (It doesn't help that for convenience/"search"-interop it's helpful to use the profile's web URL as id.)
Brittleness aside, fediverse servers generally really don't make for good identity providers. I think there's some expectation (in practice, not theory?) that public keys are unique, but those in turn can rotate afaik.
Got this working for Bluesky! By serving a #tombstone event over subscribeRepos, as discussed in https://github.com/bluesky-social/atproto/discussions/2503#discussioncomment-9504290. Example: https://bsky.app/profile/martent.mastodon.social.ap.brid.gy
Next step is fediverse. Probably need to refactor Protocol.receive a bit so it can take an optional target protocol and only deliver to followers in that protocol.
Done! This now works for Bluesky => fediverse as well. If you're on Bluesky, and you follow the bridge, and then block it, it will delete your bridged fediverse profile on all of your followers' instances.