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.

[snarfed]

Hi again @bnewbold et al! I've been working through more account and data lifecycle stuff for Bridgy Fed. The explanations here are useful!...but I'm curious about expectations and obligations for consumers, eg relays (when consuming from a PDS) and appviews.

First, data. If a firehose emits #account active=false, are there any expectations for what consumers have to do with the account's data that they have stored? Is there any status that should make them fully delete (purge) it?

And second, are there any conditions that determine when an active=false account can be reactivated? Does it depend on status?

Thanks in advance! Background: snarfed/bridgy-fed#1119, snarfed/bridgy-fed#1293, snarfed/bridgy-fed#1464

[bnewbold]

We are still debating how prescriptive to be about this. Eg, to some degree this kind of behavior isn't even observable, so compliance with the spec can't be verified externally. We also want to leave wiggle room for implementations to make their own decisions.

We probably will specify that none of the account statuses are truely permanent. They are also generally only "hop by hop": account statuses probably only apply at any specific service, they are not truely network-wide. Eg, can account can be deleted on one PDS, but pop back up (same identity/DID) on a different PDS.

As a rough guide, deactivated and suspended are more temporary and the best practice would be to not purge data on downstream services. deleted and takendown are somewhat more permanent (though reversible!), and purging data would be recommended, possibly after some time delay (eg, 24 hours; not going to be specified in the protocol).

[snarfed]

Thanks! Makes sense.

I definitely get that the protocol can't make guarantees for remote deletion, but there are enough needs for data sovereignty, right to forget, legalities like CSAM etc out there that deletion is probably worth including in the subscribeRepos spec as a strong recommendation/expectation.

And maybe just as importantly, it'd help a ton to spell out explicitly what you all, ie the app.bsky relay and appview, due wrt data deletion, even if you reserve the right to change it later.

Thanks again!