Skip to content
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

Closed
snarfed opened this issue Jan 11, 2024 · 13 comments
Closed

On opt out, delete user in bridged networks #783

snarfed opened this issue Jan 11, 2024 · 13 comments
Labels

Comments

@snarfed
Copy link
Owner

snarfed commented Jan 11, 2024

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.

snarfed added a commit that referenced this issue Jan 28, 2024
@snarfed
Copy link
Owner Author

snarfed commented May 15, 2024

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?

@qazmlp
Copy link

qazmlp commented May 15, 2024

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.

@snarfed
Copy link
Owner Author

snarfed commented May 15, 2024

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.

@snarfed
Copy link
Owner Author

snarfed commented May 15, 2024

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.

@snarfed snarfed added the now label May 18, 2024
@snarfed
Copy link
Owner Author

snarfed commented May 20, 2024

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.

@snarfed
Copy link
Owner Author

snarfed commented May 20, 2024

Still figuring this out in Bluesky too: bluesky-social/atproto#2503

@qazmlp
Copy link

qazmlp commented May 21, 2024

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.

@qazmlp
Copy link

qazmlp commented May 21, 2024

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.

@snarfed
Copy link
Owner Author

snarfed commented May 21, 2024

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.

snarfed added a commit to snarfed/arroba that referenced this issue May 22, 2024
...and implement in `MemoryStorage` and `DatastoreStorage`. Used to delete accounts: bluesky-social/atproto#2503 (comment) . for snarfed/bridgy-fed#783
snarfed added a commit to snarfed/arroba that referenced this issue May 22, 2024
@qazmlp
Copy link

qazmlp commented May 22, 2024

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.

@snarfed
Copy link
Owner Author

snarfed commented May 23, 2024

Got this working for Bluesky! By serving a #tombstone event over subscribeRepos, as discussed in bluesky-social/atproto#2503 (reply in thread). Example: https://bsky.app/profile/martent.mastodon.social.ap.brid.gy

snarfed added a commit to snarfed/arroba that referenced this issue May 23, 2024
snarfed added a commit that referenced this issue May 23, 2024
@snarfed
Copy link
Owner Author

snarfed commented May 23, 2024

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.

@snarfed
Copy link
Owner Author

snarfed commented Jun 14, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants