Eigene Revision löschen (NIP-09 kind 5)

[usekaneo]

Ein Nutzer kann seine eigene Revision nicht zurücknehmen. Vorgesehen ist ein kind 5-Delete-Event auf die eigene 1818-Revision — mit der bekannten Einschränkung, dass Löschen auf Nostr eine Bitte an das Relay ist, keine Garantie.

Aufgabe: Aktion in der History für eigene Revisionen, kind 5 senden, gelöschte Revision in Kette, Diff und Blame korrekt überspringen (die Kette darf nicht reißen — parent-rev der Nachfolger beachten). In der UI ehrlich benennen, dass Kopien auf anderen Relays bleiben können.

Quelle: docs/05-versioning-history.md „Open", docs/09-security-privacy.md

---

_{Task: eqcvip35gtu1l9da0zsp3em0}

[usekaneo]

CON-10

[usekaneo]

**** commented:

Technical refinement

1. Scope

In scope — the ticket’s own wording:

• A kind 5 deletion request (NIP-09) on a user’s own 1818 page revision, published to the space’s relay.
• A "request deletion" action in HistoryView for one’s own revisions, worded honestly.
• kind 5 receipt: the deleted revision is skipped in head resolution, the chain, the diff pickers and blame — without tearing the chain: a successor whose parent-rev points at the removed revision must still reach the surviving ancestors.

Out of scope (explicitly, because the ticket stops there):

• The existing admin path via NIP-29 9005 (deleteGroupEvent). It stays; it is a different mechanism with different semantics.
• Deleting other people’s revisions (an admin tool, not this ticket).
• Deleting comments or pages, hiding pages (tombstone revision), or deleting the 31818 placement.
• Broadcasting the kind 5 to relays beyond the space’s own relay. Every content event here goes to exactly one relay (client.publish(input.relayUrl, event)), so "copies on other relays" is only named, not solved.
• NIP-29 timeline references (previous) as a gap-detection mechanism.

2. Current state

Already there:

• KINDS.DELETION_REQUEST = 5 exists but is never used anywhere — src/nostr/kinds.ts:11. No kind 5, k tag or deletion parser exists in src/.
• NIP-29 admin deletion is implemented: deleteGroupEvent publishes 9005 with an e tag — src/nostr/moderation.ts:155-160. HistoryView.removeRevision uses it, but only when isAdmin — src/routes/HistoryView.tsx:57-59, 62-92, 293-303. That relay really deletes on 9005.
• Local removal after a successful 9005: forgetEvent → SpaceStore.forget → this.revisions.delete(eventId) + rebuildPages() — src/nostr/space-store.ts:89-94, 319-321.

The gap, and why it is bigger than it looks: the existing admin path already tears the chain. forget() deletes the revision from the Map, then buildPages recomputes leaves over the survivors — a successor whose parent-rev names the removed event no longer references any loaded node, so it becomes a leaf itself and the removed revision’s ancestors drop out; firstParentChain stops dead at the missing id (src/domain/blame.ts:21-35, its test pins exactly that, src/domain/blame.test.ts:35). Head resolution is disturbed too: referenced is built from the surviving parentRevs only, so a deleted node’s parents look like leaves again (src/domain/pages.ts:42-73). So "correctly skip" is not only about the new kind 5 path — the same chain repair is needed for 9005.

Relay reality (the decisive finding, from the vendored relay source): groups_relay accepts kind 5 but does not delete anything on it. KIND_GENERAL_EVENT_DELETION = Kind::EventDeletion is in NON_GROUP_ALLOWED_KINDS (.local/groups_relay/src/group.rs:58, 97); the processor’s content branch is guarded by k if !NON_GROUP_ALLOWED_KINDS.contains(&k) && ...h tag... and falls through for kind 5 to the catch-all, which only emits StoreCommand::SaveSignedEvent — no DeleteEvents (groups_event_processor.rs:254-269). Only 9005 reaches delete_event_request (group.rs:568-616, dispatch at groups_event_processor.rs:242). validation_middleware.rs:30 also exempts kind 5 from the h-tag requirement (list at group.rs:85-100). Consequences:

1. A kind 5 sent to this relay returns OK true and the revision stays in every subsequent read — the skip must be computed by us from the kind 5 events, every session.
2. The deletion only becomes shared state if we actually read kind 5 back; SpaceStore subscribes only to 1818, 1111 and 31818 today (src/nostr/space-store.ts:211-236).
3. Because the kind 5 carries an h tag, this relay stores it inside the group’s scope and it is filterable with #h.

Where the docs stand: docs/05-versioning-history.md:82-90 lists this as Open; docs/09-security-privacy.md:28-29 demands the wording "request deletion"; docs/02-data-model-events.md:29 already documents 5 / 9005; docs/10-roadmap.md:227 lists it as unbuilt; NOSTR.md:76, 112 records "no NIP-09, deletion only via 9005".

3. Affected files

Code

• src/nostr/kinds.ts — new tag names DELETED_EVENT ('e') and DELETED_KIND ('k'), optionally APP_CONTENT_KINDS. Shared file — see collision note.
• src/domain/deletion.ts (new) — parseDeletion(event, expectedGroup) and the Deletion type.
• src/domain/pages.ts — deleted-aware leaf/head resolution and parent reconnection (pure, the core of the ticket).
• src/domain/blame.ts — chain walk over the repaired graph.
• src/nostr/publish-deletion.ts (new) — sign and publish the kind 5.
• src/nostr/space-store.ts — kind 5 subscription, tombstone state, snapshot field, EOSE gate 4 → 5.
• src/routes/HistoryView.tsx — own-revision "Request deletion" action, confirm/explanation text, tombstone-aware page.
• src/routes/BlameView.tsx — only if blame is fed raw revisions rather than page.revisions (verify at implementation time).

Tests

• extend src/domain/pages.test.ts, src/domain/blame.test.ts, src/nostr/space-store.test.ts; new src/domain/deletion.test.ts, src/nostr/publish-deletion.test.ts.

Docs

• docs/05-versioning-history.md (move the bullet from Open to Implemented, with the "relay keeps it" caveat), docs/09-security-privacy.md (one sentence on the client-side tombstone), docs/10-roadmap.md (delete the row), plausibly NOSTR.md:76, 112.

Collision warning: src/nostr/kinds.ts is touched by nearly every ticket (it is the single home of kind/tag constants, AGENTS.md), and the sibling "hiding a whole page (tombstone)" item in docs/05-versioning-history.md:89-90 will also want it, plus revision.ts, pages.ts and the store. Land this ticket’s kinds.ts change as its own small commit and keep the tombstone revision’s constants out of it.

4. Approach

Step 1 — constants and parsing. Add the NIP-09 tag names in src/nostr/kinds.ts: DELETED_EVENT: 'e', DELETED_KIND: 'k'. New src/domain/deletion.ts:

• parseDeletion(event, expectedGroup): Deletion | null — accept only kind === KINDS.DELETION_REQUEST; read every e tag as a target id; the k tag must be KINDS.PAGE_REVISION when present (NIP-09 recommends it, we always write it, and a foreign k is not about a revision); an h tag, when present, must equal expectedGroup — the same rule as parseRevision (src/domain/revision.ts:39-43).
• Never honour a deletion for a revision by another author. The check happens where both are known (the store): a tombstone counts only if deletion.author === revision.author. This is the app-layer gate the relay does not provide; without it any member could publish kind 5 against anyone’s revision and hide it for clients that trust blindly.

Step 2 — keep deleted revisions out of the display and reconnect the chain (the heart of it). Do not remove the deleted revision from the store. Add it to a deleted id set and make the pure graph code skip it:

• buildPages(revisions, placements, deleted): compute byId over all revisions; build referenced from all parentRevs (a deleted revision still references its parents, so they cannot become leaves); compute leaves over the surviving revisions only; then map the exposed parentRevs of every survivor to the nearest surviving ancestor. Resolution: from each parent-rev, while the id is unknown treat it as the existing tolerated missing predecessor; while it is known and deleted, hop to that revision’s first parent-rev, with a visited set against cycles; keep order, de-duplicate. Consequence: a survivor of a deleted middle revision bridges to the deleted revision’s parent — the chain does not tear, and the removed revision appears neither in page.revisions nor as a leaf. If the deleted revision was the head, the page falls back to the newest survivor, which is the honest outcome (the request creates no new revision).
• Prefer a dedicated entry point over a fourth parameter threaded everywhere: a visibleRevisions(revisions, deleted) helper plus the parameter on buildPages; firstParentChain/blame then work on the repaired list unchanged. Also check src/domain/merge.ts: the common ancestor returned by findCommonAncestor may itself be a deleted revision and must resolve to a surviving ancestor, or the merge silently chooses a bad base.

Step 3 — store. In SpaceStore:

• Keep deletions: Map<string, Deletion> (id to parsed kind 5) and deleted: Set<string>, both cleared in dropCollected() (space-store.ts:120-129) so every round starts from nothing, like revisions.
• Add a fifth subscription { kinds: [KINDS.DELETION_REQUEST], '#h': [groupId] } to applyDeletion; raise the EOSE gate from >= 4 to >= 5 (space-store.ts:206-209).
• applyDeletion(event): parse; for every target id, if the revision is known and the authors match, add it to deleted; then rebuildPages(). One kind 5 may name several e ids, so iterate.
• rebuildPages() passes this.deleted to buildPages, so the pure skip logic is the single source of truth.
• Expose the removed count (or the set) in SpaceSnapshot so the UI can say "N revision(s) removed by their authors" without re-deriving it.
• Stop calling forgetEvent for kind 5. forget() removes the revision outright and is correct only for 9005, where the relay really deleted the event. The new path keeps it as a tombstone so the chain can bridge. HistoryView therefore switches to the deletion overlay for the kind 5 case and keeps forgetEvent for the admin 9005 case.

Step 4 — publishing. New src/nostr/publish-deletion.ts: publishRevisionDeletion(signer, { relayUrl, groupId, revisionId }) mirrors publishModeration/publishRevision (sign, verifyEvent, client.publish(relayUrl, event)). Tags: [TAGS.DELETED_EVENT, revisionId], [TAGS.DELETED_KIND, String(KINDS.PAGE_REVISION)], [TAGS.GROUP, groupId], plus an alt for foreign clients. Content is empty.

Step 5 — UI (HistoryView.tsx). In the action row (HistoryView.tsx:266-304):

• Author check session.status === 'signed-in' && session.pubkey === revision.author (same style as src/routes/PageView.tsx:198). Keep the existing admin Delete (9005) button and render "Request deletion" only for the author.
• Confirm text (English, honest, no "deleted"): e.g. "Ask this space’s relay to remove this revision? Other relays and clients may still have a copy, and newer revisions that build on it keep their text. The relay may ignore the request." After ok: true show the relay’s answer and repeat the caveat rather than claiming success — the relay answers OK true while doing nothing, so "request delivered" is the honest wording. Reuse ensureSamePubkey() and classifyRejection as the sibling actions do.
• Because the head can change under the selection, guard the diff default indices (revisions[0]/[1], HistoryView.tsx:93-94) against a page that collapsed to fewer than two revisions; a page losing its slug entirely is fine, the view already renders the existing "No revisions for this slug." branch.
• Consider a muted inline note ("1 revision removed by its author") plus a REMOVED badge instead of hard-hiding the entry; the ticket asks to skip, and a silent disappearance is the kind of dishonesty the security doc forbids. Judgment call — see open questions.

5. Alternatives considered

1. Tombstone overlay in buildPages (recommended) vs. filter the revision out at ingestion (in applyDeletion/forget): the latter is a two-line change but is the chain tear — the successor’s parent-rev then points at nothing and firstParentChain stops, exactly what the ticket forbids. Rejected.
2. Keep the graph and filter only at render time: leaves computed over survivors still break (a survivor with a dangling parent becomes a leaf) and blame walks the raw graph. Rejected for the same reason.
3. A tombstone as a new 1818 revision carrying a deleted tag plus 9005: works only for admins, appends to the history, and does not express "this user asked", so it is not NIP-09. That is the other open item (hiding a whole page). Rejected here.
4. Publish kind 5 with the h tag (recommended) vs. without it (NIP-09’s letter, where h is not a tag of that NIP): without h this relay stores the event unscoped, we cannot read it back with #h, and the tombstone lasts only until the next reload — failing the ticket’s own skip requirement across sessions. With h the relay accepts and scopes it (validation_middleware.rs:30). Recommended; the cost is that deletions become visible to every member, which is the price of shared state. Re-verify empirically that the OK does not depend on the h tag (I did not run the dev relay).
5. Trusting a foreign kind 5 vs. author-checking it: the relay enforces nothing, so trusting it lets any member hide any revision. The author check is mandatory.

6. Risks and traps

• The relay’s OK true is not deletion. This is the AGENTS.md entry "A relay’s rejection of a pending operation does not mean that operation actually failed" in reverse: here acceptance does not mean it happened. Any copy that says "deleted" is wrong; docs/09-security-privacy.md:28-29 names the wording.
• Forged h tags (AGENTS.md: "Forged h tags ... Checked after loading"): parseDeletion must drop a kind 5 whose h names another group, exactly as parseRevision does.
• The tombstone must survive a reload. It only does because the kind 5 is re-read; the next start()/identity change calls dropCollected() (space-store.ts:120-129) and everything not re-delivered is gone. Do not implement the skip as a local-state-only mutation.
• Adding a subscription without raising the EOSE gate (space-store.ts:208) leaves every space on "loading..." for a fourth EOSE that already arrived. Check src/nostr/space-store.test.ts for hard-coded subscription/EOSE counts.
• Do not reuse forgetEvent for kind 5 — it removes the node and breaks the chain (Section 4, Step 3).
• Merges with one deleted parent: keep the surviving parents only; if all parents are deleted the merger becomes a root. The first parent must stay first, or blame’s "first parent" changes meaning.
• Cycles: the parent-hop loop needs the same seen guard firstParentChain already has (blame.ts:27); a kind 5 pointing at itself or a parent-rev cycle must not hang the app.
• Subscription/AUTH traps (AGENTS.md): reading kind 5 on a private NIP-29 relay goes through the same client.subscribe path as everything else; nothing here may replace relay.onclose or subscribe outside ready. All new reads belong in SpaceStore.start(), which already serialises that.
• ensureSamePubkey() before signing (the repo checks the identity before every write): a changed signer must not publish a deletion signed by the wrong identity.
• The relay-side no-op is silent. The only signals are the publish OK and the kind 5 coming back on a later read. Assert the round trip in tests, not only the local set.

7. Test plan

src/domain/pages.test.ts (extend; fixture rev() at line 13 — add the deleted-set argument):

• deleting the head moves the head back to its parent: r1 → r2 → r3(head), delete r3 means head.id === 'r2', r3 absent from revisions and leaves.
• deleting a middle revision does not tear the chain: delete r2 means head.id === 'r3' and r3’s parent resolves to r1.
• a deleted revision’s parents are not mistaken for leaves: r1 has only the deleted child r2, which anchors r3, so leaves === ['r3'] and not ['r1', 'r3']. Fails today because referenced is built from survivors only (pages.ts:56-60).
• a merge with one deleted parent keeps the surviving parent and one leaf; two consecutive deletions bridge to the first surviving ancestor; a parent-rev cycle terminates.

src/domain/blame.test.ts (extend): the chain walk over a middle-deleted graph still reaches the deleted revision’s predecessor and lines introduced before it keep their author; an empty history yields no lines rather than a crash. Fails today at the "stops when a predecessor is missing" behaviour (blame.test.ts:35-40) as soon as the node is missing.

src/domain/deletion.test.ts (new): reads targets from e tags; rejects the wrong kind, a foreign h and a foreign k; tolerates a missing h; returns null for kind 1818.

src/nostr/publish-deletion.test.ts (new, mock client.publish as the other publish tests do): asserts kind === KINDS.DELETION_REQUEST and the e, k = 1818, h tags; asserts a relay failure propagates as { ok: false }. Mutation check: dropping the k tag or signing the wrong kind must fail the test.

src/nostr/space-store.test.ts (extend): a kind 5 from the revision’s author removes it from snapshot.pages (and reconnects the successor’s parent); the same event from another pubkey is ignored; the tombstone survives a start() rebuild when the kind 5 is re-delivered; forget() (the 9005 route) still behaves as before; five subscriptions open and EOSE completes with five - the test that catches the eoseSeen regression.

E2E: not warranted. The repo has no E2E harness (docs/10-roadmap.md:225 lists Playwright as unbuilt) and these behaviours are pure or store-level. One manual check belongs in the acceptance: publish kind 5, reload, verify the revision stays out and no message says "deleted". If a dev relay is used, also verify the relay’s OK for a kind 5 with the h tag — the one thing source reading could not settle.

Gate: npm run typecheck && npm run lint && npm test && npm run build; lint matters for the new hook surfaces in HistoryView (react-hooks rules).

8. Acceptance criteria

• A signed-in user sees "Request deletion" only on their own revisions; another user’s revision is never offered it (the admin 9005 button is a separate action).
• It signs and publishes exactly one kind 5 (kind number from KINDS.DELETION_REQUEST) with the revision id in an e tag and k = KINDS.PAGE_REVISION.
• Confirmation and result text call it a request, say other relays/clients may keep a copy, and never say "deleted".
• After the request the revision is gone from the history and the diff pickers, and a successor’s chain still reaches the deleted revision’s ancestors (proved in tests, not only visible in the UI).
• Blame still attributes every line across the gap, with no crash and no attribution to the removed revision.
• Reloading keeps the revision skipped (tombstone re-derived from the relay’s kind 5).
• The admin 9005 deletion still works and still removes the event from the relay.
• npm run typecheck && npm run lint && npm test && npm run build is green.

9. Open questions

1. Hide a deleted revision entirely, or show it greyed with a "removed" badge? I recommend the muted marker (the ticket says skip, the security doc values honesty), but it adds a small UI surface — a product call.
2. Should deletions be visible to other members, given the h tag makes them readable? A relay that truly enforced NIP-09 would remove the event; ours does not. If tombstones must stay private to the author, the read has to be author-scoped (authors: [session.pubkey]) and the h tag dropped, which loses consistency for other viewers. The ticket is silent; I recommend the shared, author-checked version.
3. Is the relay’s accept-without-deleting behaviour acceptable for this ticket, or does it need an upstream relay issue? Nothing in the app can make the relay delete; the client-side tombstone is the workaround. Worth recording in docs/05 and NOSTR.md.
4. Does the 9005 admin path need the same chain repair (it already tears the chain, per Section 2)? I recommend folding that fix in here because forget() is the shared failure mode, but it widens the ticket slightly.

10. Size

Roughly 8 source files (2 new: domain/deletion.ts, nostr/publish-deletion.ts) and 5 test files, ~400-600 lines including tests. No schema migration, no new dependency. One ticket, but split into three commits: (1) kinds.ts + parsing/publishing; (2) the buildPages/blame chain repair (pure, independently reviewable); (3) the store subscription and the HistoryView action. Item (2) carries the design weight and is where review should focus — it also fixes the pre-existing 9005 tear.

[usekaneo]

**** commented:

Technical refinement

Status: the code change is small; the hard part is the data model. Deleting a middle revision cannot be undone by a signed event, so the client has to tolerate a hole in the parent-rev chain and say so honestly.

What exists today

• Admins delete via NIP-29 9005 (deleteGroupEvent, src/nostr/moderation.ts:155, driven from HistoryView.removeRevision, line 62) and the relay enforces it. forgetEvent removes the event locally.
• KINDS.DELETION_REQUEST = 5 already exists (src/nostr/kinds.ts:11), but there is no publish helper and NOSTR.md lists NIP-09 as not implemented.
• The chain is tolerant of absent events by construction of the resolvers:
  • buildPages (src/domain/pages.ts) computes leaves by consulting parent-rev ids that are present; a missing predecessor simply leaves the successor as a leaf.
  • firstParentChain (src/domain/blame.ts:21-35) stops at byId.get(parentId) === undefined.
  • findCommonAncestor (src/domain/pages.ts:131-160) returns null when a link is missing, so a merge across a gap honestly reports a conflict instead of guessing.
• Every revision is a full-text snapshot, so DiffView can compare any two surviving revisions without the chain. Only ordering, blame and merge-base depend on parent-rev.

The core problem

A kind 5 names only the event to delete (e tag) plus its kind (k); it does not carry the deleted event's own parent-rev. So a successor's parent-rev pointing at the deleted id can only be bridged if the client still holds the deleted revision from before. A client that never saw it cannot reconstruct the chain — the honest behaviour is to show a gap, not invent one.

Approach

1. Publish helper. Add requestDeletion(signer, { relayUrl, groupId, eventId }) (new src/nostr/publish-deletion.ts, or alongside moderation.ts) signing kind 5 with tags ['e', eventId], ['k', '1818'] and ['h', groupId]. Verify the signature like publishRevision does.
2. Measure the relay before trusting it. Against groups_relay, check whether a kind 5 inside a group (a) is accepted at all, (b) needs the h tag (NIP-29 requires h on every event), (c) is honoured only for the author's own events, and (d) whether supported_kinds has to list 5. If the relay ignores NIP-09 inside groups, the feature degrades to a documented no-op and 9005 stays the only real deletion — say so rather than shipping a button that lies.
3. Store a deletion set. In SpaceStore, keep deletedIds: Set<string> and deletedRevisions: Map<string, Revision>. Subscribe to { kinds: [5], '#h': [groupId] }; when a request names a revision we currently hold, move it from revisions to deletedRevisions, add it to deletedIds, and rebuild pages. forgetEvent does the same for the 9005 path. On identity change the sets clear with dropCollected().
4. Keep the successor legible. buildPages excludes deleted revisions (they are no longer in revisions). HistoryView renders a 'deleted (requested)' placeholder at the gap when deletedRevisions still has the entry, so the timeline shows what the successor's parent-rev points at. Blame lines whose owner was deleted show as 'unknown (deleted)' rather than being silently attributed to the successor.
5. UI. In HistoryView, show Request deletion on revisions whose author === session.pubkey; keep the admin Delete (9005) for admins, and decide the precedence when both apply (recommend: 9005 for admins, kind 5 only for non-admins). The confirmation text must state what docs/09 already says: this is a request, copies on other relays remain, and everything after this revision may show a gap. Do not phrase it as 'delete'.
6. Chain semantics decision. Allowing deletion of a middle revision orphans every successor. Two options:
   • A (recommended first): only offer the request on leaf revisions (a revision nothing points at — the head or a fork tip). Deleting a leaf keeps the chain connected and head falls back to the previous revision cleanly. This is the smallest honest step.
   • B: allow any own revision and rely on the gap-tolerant resolvers above, with the warning. More faithful to the ticket, but gaps are permanent and unreconstructable elsewhere.
7. Metadata. If the relay requires it, add KINDS.DELETION_REQUEST to the supported_kinds sent by editMetadata (APP_CONTENT_KINDS in src/nostr/kinds.ts:68) — a separate decision from the content kinds, so do not just append it.

Subtasks

• Relay measurement: kind 5 in a group, with/without h, self only, supported_kinds
• requestDeletion helper + signature verification
• SpaceStore: deletedIds / deletedRevisions, kind-5 subscription, forgetEvent parity
• Gap-tolerant History rendering and blame attribution
• HistoryView action for own revisions with honest wording; precedence vs. 9005
• Decide A (leaf only) vs. B (any revision)
• Tests: buildPages with deleted ids, blame across a gap, deletion-set lifecycle
• Docs: docs/05 'Deleting' open item, docs/09 deletion wording, NOSTR.md NIP-09 row

Acceptance criteria

• A non-admin can request deletion of their own revision; the button never appears on someone else's revision.
• The UI text does not promise deletion and names the remaining copies.
• After a request, the revision disappears from the timeline/head locally; if the relay honours it, it stays gone after a reload.
• With a deletion that leaves a gap, the app still renders the page, history, diff and blame without crashing.
• Nothing in the chain resolver silently reattaches a successor to a grandparent it cannot prove.

Risks / open decisions

• Unreconstructable gaps. Option B permanently loses ordering information that existed before the deletion. This is the main reason to prefer A in a first iteration.
• Relay behaviour is unverified. Everything hinges on the measurement in step 2; do not build UI copy on the assumption that NIP-09 works in a group.
• Local suppression vs. relay reality. A locally remembered deletion may differ from the relay's state; never claim 'deleted' where the request has not been confirmed.
• Interplay with CON-8: the cached copy must be removed too, or the revision reappears on the next reload; and with CON-11, whose tombstone should be the way to remove a whole page.

Depends on / relates to

CON-11 (tombstone — page-level removal), CON-8 (cache must drop deleted events), docs/05 (Deleting), docs/09 (deletion is a request).

[usekaneo]

**** commented:

Reviewed in worktree .worktrees/con-10 (feat/con-10-delete-own-revision @ 497d27d). Verification run for this review on that worktree: npm run typecheck, npm run lint, npm test, npm run build — all four pass.

Review — CON-10: Eigene Revision löschen (NIP-09 kind 5)

Verdict

❌ Changes requested. One correctness gap in the chain repair — deleting a merge revision resurrects its other branch as a phantom leaf and breaks the merge base — should be fixed before merge. Everything else is minor or a nit; the ticket's acceptance criteria are met for the ordinary single-parent chain.

Summary

The branch adds NIP-09 tombstoning of a user's own 1818 revision. src/domain/deletion.ts parses a kind 5 into a Deletion; src/nostr/publish-deletion.ts signs and publishes it scoped to the group via the h tag; SpaceStore subscribes to kind 5 with #h and folds author-validated targets into a deleted set that buildPages uses to drop the revision and re-point survivors. HistoryView gains a "Request deletion" action on the author's own rows plus honest "request, not guarantee" wording, and the docs and NOSTR.md are updated. The chain repair is the heart of the ticket and is well covered for single-parent chains; the one place it is not is a deleted merge revision (finding 1).

Acceptance criteria

#	Criterion (from the ticket)	Where it is satisfied	Status
1	Action in the History for own revisions	HistoryView.tsx:367-377 — button rendered only when session.status === 'signed-in' && session.pubkey === revision.author	✅
2	Send kind 5	publish-deletion.ts:22-42; tags h/e/k/alt, empty content; asserted in publish-deletion.test.ts:40-52	✅ (see nit 4)
3	Deleted revision skipped in the chain	space-store.ts:138-146 + pages.ts:41-50,102; tested in pages.test.ts:97-221 and space-store.test.ts:356-371	✅
4	Deleted revision skipped in the diff	HistoryView.tsx:62 takes page.revisions; the removed revision is not in it and feeds both pickers (l. 271, 287) and the row list (l. 306)	✅
5	Deleted revision skipped in blame	BlameView.tsx:46 calls blame(page.revisions, page.head); repaired list contains no removed node; tested in blame.test.ts:72-87	✅
6	Chain must not tear — successor's parent-rev handled	pages.ts:52-78 bridges survivors to the nearest surviving ancestor; tested in pages.test.ts:113-177	️ first parent only — finding 1
7	UI honestly names that copies on other relays remain	confirm dialog HistoryView.tsx:107-112; success notice l. 239-245 with text from l. 129-132; tombstone callout l. 247-255	✅

Findings

1. [major] Deleting a merge revision resurrects one of its branches as a phantom leaf

Where: src/domain/pages.ts:73 — current = parent.parentRevs[0] ?? ''

What is wrong. When the climb out of a removed revision reaches a node with more than one parent-rev, only the first parent is followed. A successor whose parent is a removed merge is therefore re-pointed at a single grandparent; everything reachable through the removed merge's second parent is dropped from the repaired graph.

Repro (all on one slug):

• r1 (t=100, no parents), r2 (t=150, no parents)
• m (t=200, parents ['r1','r2']) — a merge revision
• s (t=300, parents ['m']) — survives; m is in the deleted set

visibleRevisions yields s with parentRevs = ['r1']; r2 is referenced by nothing visible and becomes a leaf. page.leaves is now [s, r2], so PageView.tsx:97 shows a fork and EditorView.tsx:48 offers merge mode for an ancestor/descendant pair. Because EditorView.tsx:88 then runs findCommonAncestor on the repaired list, r2 is no longer an ancestor of s, so the merge reports "No common ancestor found" (l. 100-104) and produces a conflict against an empty base. Saving makes it worse: a new merge revision with parents [s, r2] re-introduces the phantom branch as real data.

Why it matters. The ticket's explicit requirement is that the chain must not tear and that a successor's parent-rev is handled. This is the symmetric case of the case the branch already tests (pages.test.ts:162-177 covers a surviving merge with a removed parent, not a removed merge). The trigger is not exotic: after a merge, both combined leaves are typically referenced only by that merge, so deleting the merge revision with any later successor leaves one of them dangling.

Suggested fix. When climbing out of a removed node, collect all surviving ancestors reachable through it, not just the ones on the first-parent path. The minimal change that preserves firstParentChain and the "merge" badge: keep the first-parent bridge in parentRevs, but also return the additional surviving ancestors so buildPages's referenced set (pages.ts:115-118) can mark them as referenced and stop them being leaves. Alternatively add every surviving ancestor to the successor's parentRevs (faithful, but the successor would then display the "merge" badge). Either way, add the deleted-merge case to pages.test.ts.

2. [minor] The h-less and foreign-group tolerance in parseDeletion is unreachable — and its tests assert dead behaviour

Where: src/domain/deletion.ts:39-40 and src/nostr/space-store.ts:268

parseDeletion explicitly tolerates a missing h (const group = tagValues(event, TAGS.GROUP)[0] ?? null) and rejects a foreign one (if (group && group !== expectedGroup) return null). But its only caller is applyDeletion, which is only fed by client.subscribe(..., { kinds: [KINDS.DELETION_REQUEST], '#h': [this.groupId] }, ...) (space-store.ts:266-271). A relay can only return events that carry h = groupId for that filter, so group can never be null and can never differ from this.groupId. The docstring at deletion.ts:30-33 ("a client that sends one without it is still asking about a revision") promises tolerance the app does not actually exercise, and deletion.test.ts:44-65 locks in behaviour that cannot occur in production. The consequence for interop is real: a NIP-09 request written by another client without an h tag (NIP-09 does not define one) is invisible to this app.

Suggested fix. Decide and align: either drop the tolerance and its two tests and say so in the docstring, or make the subscription able to receive such requests (for example scope by authors/#e or drop #h and filter client-side). The current middle ground is both misleading and untested-in-practice. (On the bundled relay a no-h kind 5 is also stored outside group scoping, which makes the tolerance doubly moot.)

3. [minor] When the page's only revision is removed, the explanation the ticket asks for never renders

Where: src/routes/HistoryView.tsx:49-57 versus HistoryView.tsx:247-255

Removing a page's last remaining revision makes buildPages drop the page entirely (pages.test.ts:179-181). HistoryView then hits const page = space.pages.find(...) → if (!page) and renders only "No revisions for this slug." (l. 52-54), returning before the "Removed by their authors" callout (l. 247-255) and before the success notice (l. 239-245). So the one case where the user most needs to be told "a request was sent, the relay may still hold it, other copies remain" is exactly the case where the app says nothing. The same effect removes the page from the sidebar (space.tree).

Suggested fix. Compute the removed-revision count for the route slug before the !page early return and render the tombstone callout (or a page-shell variant of it) in that branch too.

4. [nit] kind 5 is not declared in APP_CONTENT_KINDS

Where: src/nostr/kinds.ts:68, used by CreateSpaceForm.tsx:94 and SpaceSettings.tsx:116

New and re-configured groups declare supported_kinds = [1818, 1111, 31818] only, so this app never advertises that it writes kind 5. I verified this is latent for the bundled relay: it does not enforce supported_kinds on writes at all (no such check in .local/groups_relay/src; groups_event_processor.rs:254-269 falls through to SaveSignedEvent for kind 5 because it is in NON_GROUP_ALLOWED_KINDS, group.rs:97). On any relay that does enforce the list, the deletion request would be rejected. Worth a one-line addition or an explicit note that it is intentional.

5. [nit] Unrelated test changes are bundled into the CON-10 branch

src/ui/editor-complete.test.ts, src/ui/formatting-help.test.ts, src/ui/markdown-flavour.test.tsx and src/ui/task-marker.test.ts gain a vi.mock('../nostr/profile-store', ...) that has nothing to do with deletion (each also gets a doubled blank line after the mock). Harmless, but it hides the ticket's real footprint and should either be split out or mentioned in the PR description.

Tests

Are they meaningful? Yes. deletion.test.ts and publish-deletion.test.ts would fail against a dummy (they assert the parsed e/k/h tags, the empty content, the target pubkey, and the relay URL). The eight new buildPages cases (pages.test.ts:97-221) fail against the pre-CON-10 code: without the repair, r1 looks like a leaf after a middle removal, the head is wrong when the head was removed, and the cycle case would not terminate as asserted. The store tests (space-store.test.ts:332-438) cover the live subscription shape, the author gate, rebuild re-derivation from the relay, and that admin forget still removes outright. The blame test (blame.test.ts:72-87) is a genuine integration test of repair + attribution, not a restatement of the unit.

Edge cases covered well: head removal, middle removal, consecutive removals, a removed revision's parent not becoming a leaf, a merge whose first parent was removed, a page losing its only revision, a parent cycle between removed revisions (termination), a tolerated missing predecessor, and the no-op path.

Missing cases (in priority order):

1. Request arriving before its revision. space-store.ts:148-153 claims deriving the set on every rebuild "keeps the result independent of the order in which the revision and the request arrive", but every test delivers the revision first (space-store.test.ts:359-363, 393-396, 403-405). Add a test that delivers the kind 5 first and the revision afterwards.
2. A deleted merge revision (finding 1) — add the repro above to pages.test.ts.
3. The UI action is untested. There is no HistoryView test at all (confirmed: only HistoryView.tsx exists), so the author gate, the confirmation, and the notice/tombstone callouts have no regression guard — exactly the "honest wording" part of the ticket.
4. Low value: the invalid-signature early return at publish-deletion.ts:38-40 is not exercised.

Docs

• Updated and accurate: docs/05-versioning-history.md:89-97 (moved from "Open" to "Implemented"), docs/09-security-privacy.md:28-33, the backlog row removed from docs/10-roadmap.md:225, and both NOSTR.md rows (NIP-09 table and kind 5 table). docs/02-data-model-events.md:29 already listed 5.
• Verified claim: "the NIP-29 relay we run stores it without deleting anything" is true for the bundled relay — groups_event_processor.rs:254-269 saves kind 5 as an ordinary signed event and only handles 9005/9008 as deletions.
• Two wording issues. docs/05:95 says a successor is "re-pointed at the nearest surviving ancestor" (singular) without mentioning multi-parent merges — that omission is finding 1. And "keeps the revision as a tombstone" (docs/05:93, docs/09:30) is loose: no tombstone event is written; the retained thing is the kind 5 request, from which the skip is re-derived. The behaviour is right, the noun is not.

What is good

• Clean layering and conventions. Parsing in domain/deletion.ts, publishing in nostr/publish-deletion.ts, and both new tag names centralised in nostr/kinds.ts:95-98 — no magic strings or kinds in the UI.
• The author gate is in exactly the right place (space-store.ts:155-164, where request and revision are both known) rather than in the parser, and it is re-derived on every rebuild — which is what makes the ordering genuinely irrelevant (finding on tests aside).
• The repair is defensive: the cycle guard (pages.ts:62-67) terminates instead of hanging, and an unloaded predecessor survives as a tolerated missing link (pages.ts:69-72).
• The UI is honest in three places, including the confirmation before the action, and the enabled-by-default button only on the user's own revisions.
• Documentation was swept, not just the two files named in the ticket, and the roadmap backlog was updated.

---

Reviewed at 497d27d, diff main...HEAD (21 files). Findings verified by reading the worktree files and, for the relay-storage claim, .local/groups_relay.

[usekaneo]

**** commented:

Review response — CON-10

Worked in .worktrees/con-10 (feat/con-10-delete-own-revision), on top of 497d27d. All changes are left uncommitted in the working tree for review.

Gate, run from that worktree after the changes:

npm run typecheck   ✅ (tsc --noEmit, no output)
npm run lint        ✅ (eslint ., no findings)
npm test            ✅ 47 files, 478 tests passed
npm run build       ✅ built in 36.33s (pre-existing >500 kB chunk warning only)

---

Finding 1 — [major] Deleting a merge revision resurrects one of its branches as a phantom leaf

Verified, exactly as described. Wrote the review's repro as a test first and ran it against the unfixed code:

FAIL  buildPages — revisions removed by a NIP-09 request
      > does not resurrect the second branch of a removed merge as a leaf
AssertionError: expected [ 'after', 'r2' ] to deeply equal [ 'after' ]

reconnectParents climbed out of the removed merge along parent.parentRevs[0] only (pages.ts:73 at the reviewed commit), so r2 ended up referenced by nothing visible and came back as a leaf.

Fixed in src/domain/pages.ts. Took the review's first suggestion — the one that preserves arity:

• repairChain() (replaces the old visibleRevisions) now returns { revisions, bridged }, where bridged maps a survivor's id to the surviving ancestors it reaches only through removed revisions and that are not among its own parents.
• firstSurvivingAncestor() keeps the first-parent bridge (so firstParentChain and blame keep their meaning, and the successor does not inherit a "merge" badge for a merge nobody made).
• survivingAncestors() walks the whole removed sub-graph breadth-first, with the same seen guard, and those ids are added to the per-slug referenced set in buildPages — so they are referenced exactly as they were before the removal, just not as parents.

Test added at src/domain/pages.test.ts ("does not resurrect the second branch of a removed merge as a leaf"): it asserts leaves === ['after'] and that after.parentRevs === ['r1'], i.e. the successor keeps the arity its author signed.

One consequence worth naming, since the review raised findCommonAncestor: the off-path ancestor is expressed as referenced, not as a parent, so findCommonAncestor still cannot prove r2 is an ancestor of after. That path is no longer reachable from the UI — merge mode is gated on page.leaves.length > 1 (EditorView.tsx:48) and the phantom leaf is gone, so no merge against an unprovable base is ever offered. Making the ancestor a real parent instead would fix the graph relation but mislabel the successor as a merge; I judged the badge the worse lie. Happy to swap if you disagree.

Finding 2 — [minor] The h-less tolerance in parseDeletion is unreachable and its tests assert dead behaviour

Verified. The only caller is applyDeletion, fed exclusively by the { kinds: [5], '#h': [groupId] } subscription (space-store.ts:266-271), and our own publisher always writes h.

Fixed by aligning in the "drop the tolerance" direction (src/domain/deletion.ts): Deletion.group is now string, and a request without an h tag is rejected. deletion.test.ts follows: "tolerates a request without an h tag" became "rejects a request without an h tag", and two other cases that happened to omit h now carry it, so they test the thing their name says.

One correction to the finding, though: I kept the foreign-h rejection, and it is not dead code. docs/09-security-privacy.md:43 states the rule explicitly ("Forged h tags … Checked after loading: h must match the open space, otherwise the event is discarded"), and parseRevision (revision.ts:39-43), parseComment and parsePlacement all do the same under the identical #h filter. The filter is the relay's promise, not a guarantee — a relay that ignores it could otherwise remove a revision in this space with a request scoped to another. The docstring now says why the check stays instead of implying the tolerance exists.

The interop cost the review names is real and unchanged by this: a NIP-09 request from a foreign client, without h, still never reaches us, because the subscription filters on #h. The only way to change that would be to drop #h and read every kind 5 the relay holds, across groups, and filter client-side. That is a scope decision (a much broader, unscoped read on a private relay), so I did not take it — flagging it as open below.

Finding 3 — [minor] When the page's only revision is removed, the explanation never renders

Verified, and it is the case the ticket cares most about.

Fixed in src/routes/HistoryView.tsx: removedHere is now computed from the route's slug before the if (!page) early return, and the error / "Deletion requested — not a guarantee" / "Removed by their authors" callouts are extracted into one feedback fragment rendered in both branches. The dead-end text also reads "No revisions left for this slug." when a removal is the reason.

Regression test: src/routes/HistoryView.test.tsx → "still explains the removal when the page has no revisions left". Confirmed it fails against the unfixed view (restored afterwards):

FAIL  still explains the removal when the page has no revisions left
AssertionError: expected 'Engineering/HistoryNo revisions for t…' to contain 'Removed by their authors'

Finding 4 — [nit] kind 5 is not declared in APP_CONTENT_KINDS

Fixed in src/nostr/kinds.ts: KINDS.DELETION_REQUEST added, with a comment saying why a non-content kind belongs in that list (it is written into the group with an h tag like the rest, and a relay that enforces supported_kinds would otherwise reject the one event whose entire purpose is to be accepted) and that our own relay enforces nothing here.

Checked for the obvious side effect first: the "missing kinds" warning in SpaceOverview.tsx:63-67 uses its own hard-coded [PAGE_REVISION, PAGE_PLACEMENT] pair, not this constant, so existing spaces do not suddenly start warning. The list is only read by CreateSpaceForm.tsx:94 and SpaceSettings.tsx:116.

Finding 5 — [nit] Unrelated test changes bundled into the branch

Confirmed, and they are genuinely unrelated: the vi.mock('../nostr/profile-store', …) additions in the four src/ui/* tests came in with commit 5c8390f ("request deletion of one's own revision in the history"), and are fallout from CON-33 landing on main, not from deletion.

Measured whether they are load-bearing: reverting src/ui/editor-complete.test.ts to the pre-branch version and running it → 12 passed. So the mocks are network hygiene (they keep the real profile store from opening a WebSocket to VITE_PROFILE_RELAYS), not a fix for a failing test.

What I changed: only the doubled blank line after each mock, in all four files. Splitting them into their own commit is a history change, and the instruction for this pass was to commit nothing — so that part is left to you when the branch is cleaned up or described.

Docs — the two wording issues

Both fixed.

• docs/05-versioning-history.md: "re-pointed at the nearest surviving ancestor" now says along the first parent, and adds the removed-merge case (the ancestors on the other branches stay referenced, otherwise the page shows a fork nobody created) — i.e. the doc now describes the behaviour after finding 1's fix.
• "keeps the revision as a tombstone" is gone from both docs/05 and docs/09-security-privacy.md. The noun was wrong: no tombstone event is written; what is kept is the kind 5 request, and the skip is re-derived from it on every read. Both files now say that.

Missing tests

1. Request arriving before its revision — added to src/nostr/space-store.test.ts ("skips a revision that arrives after the request naming it"): the kind 5 is delivered first, the three revisions after it, and the result is the same skip plus bridge. This is what makes the "order is irrelevant" claim in space-store.ts:148-153 actually tested.
2. Deleted merge — added, see finding 1 (verified failing pre-fix).
3. The UI action was untested — new src/routes/HistoryView.test.tsx, 8 tests: the action is offered on one's own revision, never on someone else's, never to a signed-out reader; the confirmation is asked and contains "request, not a guarantee"; declining publishes nothing; a relay rejection is surfaced verbatim; the success notice reads as a request and not as a completed deletion; and the two removed-revision callout cases (including the finding-3 regression).
4. The invalid-signature early return — added to publish-deletion.test.ts. Note for whoever writes the next one of these: the obvious fixture (spread a finalizeEvent result, overwrite sig) does not work — nostr-tools stamps finalized events as verified via a symbol property that the spread copies, so verifyEvent returns true without checking. The test builds the event by hand instead, and asserts client.publish was never called.

Open — for you to decide, not changed

1. Should foreign NIP-09 requests (no h tag) be honoured at all? Doing so means dropping #h from the subscription and reading every kind 5 on the relay, unscoped, then filtering client-side. That is a materially broader read on a private relay and the ticket never asked for it, so the branch stays scoped to requests carrying h. Finding 2 is resolved in the "aligned and honest" direction either way.
2. Whether supported_kinds should really advertise kind 5 (finding 4). I took it as the cheap, clearly-right reading, but it does change what every newly created or re-saved space announces about itself. Easy to revert to a comment-only note if you would rather not widen the declaration.

Files changed

src/domain/pages.ts, src/domain/pages.test.ts, src/domain/deletion.ts, src/domain/deletion.test.ts, src/routes/HistoryView.tsx, src/routes/HistoryView.test.tsx (new), src/nostr/kinds.ts, src/nostr/space-store.test.ts, src/nostr/publish-deletion.test.ts, docs/05-versioning-history.md, docs/09-security-privacy.md, plus the blank-line tidy in the four src/ui/* test files. Nothing staged, nothing committed.

[usekaneo]

**** commented:

Follow-up — independent verification of the review response

The previous pass was interrupted by a rate limit right after it posted its write-up above. This is a verification pass over that work, not a second round of changes: I re-read the worktree against the review finding by finding, re-ran the gate, and independently re-confirmed the two regression tests by reverting the fixes myself. No further code changes were needed — the worktree is exactly as the previous pass left it.

Gate, re-run from .worktrees/con-10 on the uncommitted tree

npm run typecheck   ✅ tsc --noEmit, no output
npm run lint        ✅ eslint ., no findings
npm test            ✅ 47 files, 478 tests passed (7.38s, no flakes this run)
npm run build       ✅ built in 2.60s (pre-existing >500 kB chunk warning only)

None of the three known load-sensitive tests (editor-enter, editor-slash-menu, markdown-live) failed in this run.

What I verified, beyond re-reading

Finding 1 (major, deleted merge) — fix confirmed by reverting it. I restored src/domain/pages.ts from HEAD and ran src/domain/pages.test.ts:

FAIL  does not resurrect the second branch of a removed merge as a leaf
AssertionError: expected [ 'after', 'r2' ] to deeply equal [ 'after' ]

1 failed, 29 passed — so the new test genuinely pins the fix rather than restating it, and the quoted output matches the previous pass's claim verbatim. Restored afterwards.

Finding 3 (minor, page with no revisions left) — same treatment. Restored src/routes/HistoryView.tsx from HEAD and ran the new src/routes/HistoryView.test.tsx:

FAIL  still explains the removal when the page has no revisions left
AssertionError: expected 'Engineering/HistoryNo revisions for t…' to contain 'Removed by their authors'

1 failed, 7 passed. Restored afterwards; git diff --stat came back to the identical 14 files changed, 276 insertions(+), 93 deletions(-), so the tree is byte-for-byte what it was.

Finding 2 — I independently checked the previous pass's push-back, and it holds. The review called the whole h handling in parseDeletion dead. The no-h tolerance part was right and has been dropped. The foreign-h rejection part was not, and the evidence is in the tree: parseRevision (src/domain/revision.ts:43) applies the identical !group || group !== expectedGroup test under the same #h subscription, and docs/09-security-privacy.md:44 states the rule as a threat-model line ("Forged h tags … must match the open space, otherwise the event is discarded"). Removing it in parseDeletion alone would have made deletion the one parser that trusts the relay's filter. Keeping it is consistent, not redundant.

Dead-code check after the refactor. visibleRevisions was exported before and is now the private repairChain; I grepped src/ and it has no remaining callers or stale imports anywhere, tests included.

Still open — unchanged, and still for you

Both items the previous pass flagged remain product decisions and I deliberately did not decide them:

1. Whether foreign NIP-09 requests without an h tag should be honoured at all. Doing so means dropping #h from the subscription and reading every kind 5 on the relay unscoped, then filtering client-side — a materially broader read on a private relay, which the ticket never asked for.
2. Whether supported_kinds should really advertise kind 5 (finding 4). It is the cheap and defensible reading, but it changes what every newly created or re-saved space announces about itself; trivially revertible to a comment-only note.

One thing I judged and would flag for the PR description

Finding 5 (the four unrelated vi.mock('../nostr/profile-store', …) additions, fallout from CON-33) is still resolved only cosmetically — the doubled blank lines are gone, the mocks stay in the branch. That is the right call under a no-commit instruction, since splitting them is a history change. It does mean the branch's diff still overstates CON-10's footprint by four files, so it is worth a line in the PR description when this lands.

Nothing staged, nothing committed.

[usekaneo]

**** commented:

UI test pass — 2026-09-16, PR #83, c702dec

Tested in the running dev app against the local NIP-29 relay, with two signed-in members (A and B) on one page so authorship is mixed. Six of the seven steps in the PR's "How to test" pass. Step 5 does not, and it takes step 6 with it.

What passes

1–2. The gate. A page with six revisions, three by A and three by B. Signed in as B, the history shows all six; "Request deletion" appears on exactly the three B wrote and on none of A's. "Restore" stays on all of them, which is right. Signed out, the private space is not readable at all, so the button is gone along with everything else — worth knowing that the closed-teams model means the signed-out case is never actually reached on a private space.

3. The wording never says "deleted". Verbatim from the confirmation:

Ask this space's relay to remove the revision from 16.9.2026, 00:58:50?

This is a request, not a guarantee. The relay may keep the revision, copies on other relays and clients can remain, and newer revisions that build on it keep their text.

and the result:

The deletion request reached the relay. It may keep the revision anyway; copies on other relays and clients can remain.

4. A middle revision. Requesting deletion of the middle of B's three: the list goes 6 → 5, the revisions either side stay adjacent, nothing is marked as a fork, no second root appears, no merge badge. The callout reads "Removed by their authors — 1 revision of this page was hidden after a NIP-09 request."

7. Declining publishes nothing. Dismissing the confirmation leaves the relay at zero kind-5 events for the group (nak req -k 5 -t h=engineering → 0).

Step 5 fails: the removal survives a reload, the explanation does not

After reloading the history of that same page:

• 5 revisions — the removal is still there, derived from the relay, as the step promises.
• The "Removed by their authors" callout is gone. Waited 10s for late subscription delivery, then reloaded a second time: still gone.

And that is what breaks step 6

Removing the last remaining revision of a page behaves exactly as described in the session that did it: the page disappears from the tree and the history shows "No revisions left for this slug." plus the callout.

Reload that same URL and the whole page reads:

History

No revisions for this slug.

That is the bare message step 6 says this change stops a reader from landing on. The improvement only exists for the person who clicked the button, in the tab they clicked it in — never for anybody else, and not for them after a refresh.

Why (measured, not guessed)

The relay really deletes the event. After the request, nak req -k 1818 -t d=con-10-delete-check returns 5 events, not 6 — the revision is gone from the relay, not merely flagged.

What remains is the kind 5 request, and its tags are:

["h","engineering"]
["e","d936e6c038b82e496806abf6f08caf635e078c81f2d2a1094238d474d6fcdcab"]
["k","1818"]
["alt","Deletion request for a wiki revision in space engineering"]

There is no slug on it. src/routes/HistoryView.tsx:52 needs one:

const removedHere = space.removedRevisions.filter((revision) => revision.slug === slug)

A removed revision can only carry a slug if the store still holds the revision it was derived from. On a fresh load that revision is unobtainable — the relay deleted it — so nothing in removedRevisions can be attributed to this page and the filter is empty. It works before a reload purely because the revision was still in the store from before the deletion.

The comment above that line anticipates precisely the case that now fails:

Computed off the route's slug, not off page: removing the last revision of a page makes the page itself disappear, and that is precisely the moment the reader has to be told why

Suggested fix: put the slug on the kind 5 event as a d tag, the way the revision itself carries it. NIP-09 permits extra tags, parseDeletion already insists on h, and it would make the removal self-describing without depending on an event that no longer exists.

Scope note

Everything else — the reconnected chain, the gate, the h requirement, the wording — holds up. This is one missing tag, not a design problem.