Deciding whether a Nostr deletion request can hide a cached note
A relay delivers a signed deletion request that names a note your client has already stored. A valid signature on the request does not automatically authorize removing the note.
Check ownership of the target
The fixture uses short names for previously validated IDs and keys. Its first test succeeds because the target matches. Its second test fails because Bob is asking to remove Alice’s note. Verify both event signatures, then compare the canonical public keys before applying a deletion to the local view.
const saved = { id: "note-A", pubkey: "Alice" };
const request = { kind: 5, pubkey: "Bob", tags: [["e", "note-A"]] };
console.log(request.tags.some(([t,id]) => t === "e" && id === saved.id));
console.log(request.pubkey === saved.pubkey);
Handle requests received before their targets
Keep the author and target together when recording a pending request. If the note later arrives from another relay, you can perform the ownership check then. For a deletion using an addressable-event coordinate, also respect the request timestamp when considering revisions. Even an authorized request only expresses the author’s intent to relays and clients; a copy exported earlier can survive.