Claude e09a939b08 refactor: reduce deletion sync to "send deletions for need ids", nothing else ...

Per the actual requirement, deletion propagation is exactly: for the ids the
relay HAS that we LACK (the negentropy need set), if we hold a kind-5 deletion
targeting one of them, publish that deletion up — so a note we deleted is
deleted on the relay too instead of being re-downloaded. Only the need ids,
only kind-5, up only.

This removes all the machinery the earlier approach accreted and that the audit
flagged as over-broad / data-loss-prone:
- deleted NostrClientDeletionSyncExt (the bidirectional side-channel, author
  scoping, vanish gating, kind selection);
- reverted geode MirrorWorker to base (no deletion side-channel, live-sub
  changes, catch-up ordering, or convergence changes);
- dropped the 3-phase SyncCommand flow (deletions-first pull, author-scope
  derivation, reject-reaction backstop, --sync-vanish, deletions_* output).

The new path pulls nothing down and applies nothing locally, so it cannot
over-delete the store, and it needs no author scoping — the need set already
bounds it. Kind-62 is intentionally excluded: a vanish is not "of an id".

Emits deletions_sent. DeletionSyncTest now exercises the exact wiring
(reconcile → look up local kind-5 by its e tag for the need ids → publish),
including the negative case (a need id we never had sends nothing).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JgL1WTV4Hkp2uuXcUHCHGt

2026-07-08 02:29:52 +00:00

..

plans

docs(geode): SQLite knobs A/B verdict — no winner, knobs stay off by default

2026-07-04 00:50:37 +00:00

src

refactor: reduce deletion sync to "send deletions for need ids", nothing else

2026-07-08 02:29:52 +00:00

build.gradle.kts

test(geode): sync-benchmark knobs + corpus-server tool for the negentropy comparison

2026-07-05 02:29:58 +00:00

config.example.toml

fix(geode): validate config knobs and mirror filter at boot

2026-07-04 02:32:35 +00:00