Problem
POST /api/dkg/memory accepts a repeated proposal for the same evidence: nothing server-side rejects a re-submission of the same (channel, evidence set). Client-side ledgers (PR #9) can only make duplication visible — a crash between relay acceptance and client bookkeeping, or two independent proposers, can still double-write, because no client state can be atomic with a remote write.
This was Hermes' explicit acceptance criterion in the Web of Trust deliberation (2026-08-13): client-side recording is at-least-once; exactly-once needs relay-enforced idempotency.
Proposal (as specified in the deliberation)
- Server-side idempotency key:
(channel, canonical evidence-set digest) — sources lowercased, de-duplicated, sorted, digested — with atomic uniqueness at the relay/gateway.
- A replayed proposal for an existing key succeeds and returns the original accepted record / event ID (so unattended retries converge instead of erroring), with a distinguishable marker (e.g.
"replay": true or 409 carrying the original record) so clients can reconcile their ledgers to accepted.
- The relay already computes the parsed, de-duplicated source set in
parse_proposal (crates/buzz-relay/src/api/dkg_memory.rs), so the digest is one step further; enforcement could live at the relay or in the gateway behind /v1/memory — whichever owns durable state.
Interaction with PR #9
PR #9's classification already reconciles duplicate/conflict responses to accepted, so it is forward-compatible with either response shape chosen here.
🤖 Generated with Claude Code
Problem
POST /api/dkg/memoryaccepts a repeated proposal for the same evidence: nothing server-side rejects a re-submission of the same(channel, evidence set). Client-side ledgers (PR #9) can only make duplication visible — a crash between relay acceptance and client bookkeeping, or two independent proposers, can still double-write, because no client state can be atomic with a remote write.This was Hermes' explicit acceptance criterion in the Web of Trust deliberation (2026-08-13): client-side recording is at-least-once; exactly-once needs relay-enforced idempotency.
Proposal (as specified in the deliberation)
(channel, canonical evidence-set digest)— sources lowercased, de-duplicated, sorted, digested — with atomic uniqueness at the relay/gateway."replay": trueor409carrying the original record) so clients can reconcile their ledgers toaccepted.parse_proposal(crates/buzz-relay/src/api/dkg_memory.rs), so the digest is one step further; enforcement could live at the relay or in the gateway behind/v1/memory— whichever owns durable state.Interaction with PR #9
PR #9's classification already reconciles duplicate/conflict responses to
accepted, so it is forward-compatible with either response shape chosen here.🤖 Generated with Claude Code