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

Bluesky => fediverse: handle #account deactivated/deleted events from the firehose #1293

Open
snarfed opened this issue Aug 30, 2024 · 6 comments
Labels
compat Protocol differences that need special handling. now

Comments

@snarfed
Copy link
Owner

snarfed commented Aug 30, 2024

When we hear over the firehose that a bridged ATProto account has been deactivated or deleted, we should delete its bridged profile in the fediverse.

Background on these firehose events in #1119. Looks like the firehose is sending both #account ... "active": False events and #tombstone events for these accounts, but it will probably eventually drop the #tombstone events.

@snarfed snarfed changed the title Bluesky => fediverse: handle deactivated account events from the firehose Bluesky => fediverse: handle deactivated/deleted account events from the firehose Oct 22, 2024
@Tamschi Tamschi added the compat Protocol differences that need special handling. label Oct 31, 2024
@Tamschi
Copy link
Collaborator

Tamschi commented Oct 31, 2024

I'm not sure whether deactivation should cause a Delete immediately, as that's very destructive while deactivation on Bluesky is not.
Even deletions appear to be somewhat reversible on Bluesky, so it would be good to send out a Delete only after a (shorter) delay.

I think to start with, the profile should probably be Updated to only say the account is deactivated, and the bridge should refuse fetches (with a non-recoverable error other than Gone) and not bridge new activities it receives on the firehose while the account isn't active.

@snarfed
Copy link
Owner Author

snarfed commented Oct 31, 2024

Sigh, yeah, agreed. I actually talked about this with Evan and a few other people the other day, I now have "AP Deactivate actor activity" on my todo list to write up and file on https://github.com/w3c/activitypub/issues and/or https://github.com/w3c/activitystreams/issues 😆

@snarfed
Copy link
Owner Author

snarfed commented Nov 3, 2024

^ done, w3c/activitypub#475

@snarfed
Copy link
Owner Author

snarfed commented Nov 3, 2024

When we do this, we should probably delete the ATProto entity we have. #1451 is an example of someone who deleted their Bluesky account, then later created a new account (and DID) and reused the same handle, which we didn't handle well because bridged AP actor handles (and ids) use that handle, ie we're not yet handle-independent.

@Tamschi
Copy link
Collaborator

Tamschi commented Nov 3, 2024

For deletions, yes. I think deactivations are safe in this regard because the account still holds onto the handle.

@snarfed snarfed changed the title Bluesky => fediverse: handle deactivated/deleted account events from the firehose Bluesky => fediverse: handle #account deactivated/deleted events from the firehose Nov 11, 2024
@snarfed snarfed added the now label Nov 13, 2024
@snarfed
Copy link
Owner Author

snarfed commented Nov 24, 2024

Related, inspired by #1550 (comment), we should also consider what to do when we detect that a bridged Bluesky account turns on the "hide from logged-out users" setting, which we normally interpret as opting out.

First, I expect this comes over the firehose as an update to the app.bsky.actor.profile/self record, not an #account or #identity event.

Second, when this happens, should we ignore it and keep bridging the account? Or keep the bridged profile but pause bridging? Or delete the bridged profile entirely? 🤷

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compat Protocol differences that need special handling. now
Projects
None yet
Development

No branches or pull requests

2 participants