-
Notifications
You must be signed in to change notification settings - Fork 39
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
On opt out, delete user in bridged networks #783
Comments
One difficulty here is that we need to deliver the |
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 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: bluesky-social/atproto#2503 |
I think the expectation on the fediverse is that ids may be reused, but not necessarily by the same identity. Mastodon for example doesn't reserve the username, but severs all relationships irretrievably. 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. |
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. |
...and implement in `MemoryStorage` and `DatastoreStorage`. Used to delete accounts: bluesky-social/atproto#2503 (comment) . for snarfed/bridgy-fed#783
...starting with account tombstones. for snarfed/bridgy-fed#783
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. |
Got this working for Bluesky! By serving a |
Next step is fediverse. Probably need to refactor |
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. |
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.The text was updated successfully, but these errors were encountered: