-
Notifications
You must be signed in to change notification settings - Fork 40
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
Comments
I'm not sure whether deactivation should cause a I think to start with, the profile should probably be |
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 😆 |
^ done, w3c/activitypub#475 |
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. |
For deletions, yes. I think deactivations are safe in this regard because the account still holds onto the handle. |
#account
deactivated/deleted events from the firehose
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 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? 🤷 |
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.The text was updated successfully, but these errors were encountered: