implement repo tombstone handler

[whyrusleeping]

No description provided.

[ericvolp12]

Do we wanna update the ListRepos endpoint to filter out taken down and tombstoned accounts?
Might be helpful to have conditional indexes that filter out those as well so paging over it is fast and easy.

[whyrusleeping]

yeah, probably also want to add checks in other places too now that im thinking about it

[bnewbold]

I can't really remember what the repo event stream semantics are supposed to be, and I can't find our old design notes on this. From looking at the PDS code, it gets emitted when the repo is deleted from that specific PDS. I don't think the semantics are "repo is deleted for all time" (that would be a PLC identity tombstone, which is separate).

I think what the BGS needs to do on tombstone from a PDS is just

• delete all repo data from BGS, and not serve sync requests any more (this PR does that)
• emit the tombstone event for downstream folks (this PR does that)

This PR currently also records the tombstone as a flag and prevents any future event processing. I don't think we need to do that: if an account deletes their PDS account, then a couple months later decides to re-create on the same or a new PDS, and pushes records/events, that is all fine and the BGS should start processing and re-emitting events.

[dholms]

I'm not sure we fully specced out the exact semantics of the tombstone

But my thinking is that it is different from "account migration", "takedown", or "temporarily stop indexing me".

Tombstone to me implies "account deletion with no expectation of return".

If a user was migrating from PDS A -> PDS B, PDS A would not send a tombstone event, it would send an "account_migration" event.

That being said, a did can return after being tombstoned (if for instance, the tombstone was sent incorrectly or by a malicious PDS). Therefore any flag should not be permanent.

If a did is tombstoned, future events from that DID, future events should be ignored if:

• the DID does not exist
• the PDS in the DID doc is not hosting the repo for the DID

However, if that repo is "back online", then the BGS should un-tombstone the DID & re-index it just as it would a new repo that it came across

[bnewbold]

Yeah, they way I would summarize it is that after a tombstone it should be like the account never existed, and any new info is as-if coming from a brand new account.

Identity caches should probably be busted/flushed, for example, so that on any future events there is a full resolution of DID and handle from scratch.

[ericvolp12]

LGTM, I'm gonna do a pass on error messages and status codes after this