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

[feature] Read + Write tombstones for deleted Actors #1005

Merged
merged 10 commits into from
Nov 11, 2022

Conversation

tsmethurst
Copy link
Contributor

Previous situation:

so what happens sometimes is that remote accounts send deletes, gts tries to deref the account (often with every account on the instance the delete has been delivered to!) to get the public key to authenticate the delete, and then returns a 401 because the dereference already returns 410 GONE

With these PR:

When a Delete comes in via the federating api:

  • Check if a tombstone exists in the database for the signer of the Delete.
  • If it does, halt processing and return 202.
  • It it doesn't, try to dereference the signer of the delete.
  • If they can't be dereferenced because of a 410 GONE http status code, insert a tombstone for that account in the database.
  • Return 202 Accepted for subsequent deletes, without making expensive remote http calls.

This is only done for accounts our instance didn't know about when the delete first came in. Otherwise, the http signature is validated based on the stored public key, and the delete processes as normal.

@tsmethurst tsmethurst merged commit edcee14 into main Nov 11, 2022
@tsmethurst tsmethurst deleted the create_account_tombstones branch November 11, 2022 11:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants