Is there any documentation on how to handle account deactivation/reactivation events through the firehose?

[ggwc82]

The only reference I can find is a thread from the Bluesky safety account https://bsky.app/profile/safety.bsky.app/post/3ku74woxysv2d

Thanks

[bnewbold]

That is a TODO on our stack that we haven't gotten to yet, sorry! There are some brief notes in the subscribeRepos Lexicons (in this repo).

Short summary for account deactivation/reactivation specifically:

• users control this state on their account on their PDS. it is similar but distinct to account deletion, and separate from account takedowns or suspension (which are actioned by the PDS operator/administrator).
• "downstream" services are expected to respect account deactivation the same way that they are expected to respect account deletion. content from that account (including all records, repo, blobs, profile, avatar, etc) should not be served or re-distributed. identity and account state (handle, DID, active/deactive status) can continue to be served and re-distributed. services and apps may chose to display the reason the account isn't available (aka, "deleted" vs "deactivated" vs "takedown"); if they don't distinguish, they should at least not display an incorrect reason (aka, don't say "deleted" if just "deactivated"; ok to just say "account not available")
• an #account event is transmitted over the firehose when account status changes. the active boolean flag indicates the overall state, and the status flag indicates the reason (eg, takedown vs deactivated). for deactivation, Relays will pass this event through. the event isn't signed, so it isn't fully authoritative / self-certifying, but services could decide to simply trust the PDS/Relay
• services which want to confirm the account status can resolve the account DID to a PDS service endpoint, and call the com.atproto.sync.getRepoStatus endpoint. this returns the same information that the #account event does, but is coming straight from the PDS. note that the authority for this state is rooted in the PDS instance; the user controls it by making requests to the PDS, but this isn't something that is included in the account DID or signed using the account's key
• it is allowed for services to internally/privately keep a copy of account state (repo contents, blobs, etc) while an account is deativated, as long as they don't serve that content up or re-distribute it. this is similar to takedowns, and distinct from account deletion
• the intention is that accounts can not mutate their repo state while the account is in deactivated state. this is expected to be enforced by the PDS. any #commit events that come in over the firehose while an account is not active for any reason should be ignored. if the PDS wants to allow repo changes while in-active, and then send those all out right after re-activating, that is fine.

[ggwc82]

Thanks for the explanation.

"downstream" services are expected to respect account deactivation the same way that they are expected to respect account deletion. content from that account (including all records, repo, blobs, profile, avatar, etc) should not be served or re-distributed.

What about reposts and likes from other users? When a post is deleted, are all associated likes and reposts from other users deleted too (as in, do we see an event for each of these?). What about when the account is deactivated or reactivated? Are we expected to just toggle a show and hide on not just the user's posts, but that of all the likes or reposts that appear on other user's feeds in the BSky app?

Also, is there any documentation on takedowns and supressions?

[snarfed]

Afaict yes, "all records" includes likes and reposts. Pretty sure you won't see #account or similar events for individual records, but yes, if you're a app or service, and you store or cache records from external PDSes, when you see an account deactivate or otherwise disappear, you'd stop serving that account's likes, reposts, etc as well as their posts.