Adopt applicable Concord privacy and reliability patterns

[tidley]

Summary

Evaluate and incrementally adopt the parts of Concord that can materially improve this project's privacy, consistency, recovery, and relay resilience without replacing its blind-signature voting model.

Concord is an evolving specification for encrypted Nostr communities, not a voting protocol. Its shared-key membership and signed inner identities are not suitable for anonymous ballots. The useful parts are its URL-fragment invite secrets, deterministic state folding, explicit epochs, authority citations, relay migration, bounded parsing, and signed recovery/checkpoint patterns.

This is an umbrella issue. Each implementation phase should be independently specified, tested, documented, and delivered in a small PR.

Expected Benefits

Privacy and anonymity

1. Keep bearer invite secrets out of query strings

Current private links place invite_code in the query string. Query values can leak into browser history/synchronisation, screenshots, analytics, diagnostics, access logs, and referrers.

Adopt Concord's locator/unlock-token pattern:

https://tidley.github.io/auditable-voting/?role=voter&q=...#invite_code=SECRET

Implementation:

• Keep non-secret bootstrap data such as questionnaire ID, coordinator and relay hints in the query.
• Put bearer secrets and other sensitive invite material in the fragment.
• Parse the fragment locally before application bootstrap.
• Immediately remove consumed secrets from the address bar with history.replaceState.
• Never include the raw secret in relay events, logs, telemetry, error messages or copied diagnostics.
• Continue parsing already-issued query-string invites during a documented migration period, but generate only fragment-based links after rollout.
• Add tests proving the generated URL has no bearer secret in URL.search and that bootstrap still works after the fragment is scrubbed.

Benefit: a concrete reduction in invite-secret leakage. This improves access privacy but does not itself make ballots more anonymous.

2. Research opaque, rotating issuance mailboxes

Concord's private streams use opaque key-derived stream addresses. A voting adaptation could use per-questionnaire or per-request mailbox coordinates so relays do not directly see a long-term voter npub as the private issuance recipient.

Research only until relay interoperability is demonstrated:

• Prototype a per-questionnaire voter/coordinator mailbox derived from fresh shared material.
• Rotate coordinates between questionnaires or issuance epochs.
• Preserve authenticated inner messages and strict questionnaire/context binding.
• Measure compatibility with current public relays, especially relays enforcing recipient-oriented NIP-59 behaviour.
• Document remaining timing, IP, traffic-volume, ciphertext-size and within-epoch linkage leakage.
• Compare the result against ordinary NIP-17 before deciding whether the metadata reduction justifies a custom transport.

Benefit: potentially hides long-term participant identities from relays. It does not hide timing/IP metadata and must not be used for public ballot authorship.

3. Preserve the existing blind-signature anonymity boundary

Do not adopt Concord's real-author inner signatures for anonymous ballots. Keep the current separation between authenticated eligibility, blind credential issuance, fresh response identities, and public nullifier verification.

Reliability and auditability

4. Define one normative deterministic event fold

Concord specifies how unordered relay events converge into one state. Define a shared pure reducer used by organiser, voter where relevant, worker, and auditor for:

• questionnaire definition selection and same-ID conflicts;
• delegation activation, replacement, expiry and revocation;
• questionnaire open/close state;
• worker configuration versions;
• canonical response ordering;
• first valid use of each nullifier;
• conflicting acceptance/rejection decisions;
• result-summary selection and validation;
• incomplete or partitioned relay views.

Implementation:

• Write a normative fold specification before changing runtime behaviour.
• Define validation, precedence and deterministic tie-break rules for every event family.
• Make event author/signature validation part of admission, not a caller responsibility.
• Use the same implementation in organiser and auditor paths.
• Add permutation/property tests proving identical valid event sets produce identical state regardless of fetch order or relay duplication.
• Add adversarial fixtures for conflicting definitions, equal versions, stale delegations, duplicate nullifiers and forged coordinator decisions.

Benefit: deterministic convergence, fewer component-specific interpretations, and easier independent audit.

5. Introduce explicit delegation epochs

Separate delegation replacement from configuration updates:

questionnaire_id
delegation_epoch
delegation_id
config_version_within_epoch

Rules:

• A higher valid epoch permanently supersedes lower epochs.
• A matching revocation closes an epoch.
• Configuration versions increase monotonically within one epoch.
• A worker never accepts configuration for a closed or superseded epoch.
• Browser recovery may reconstruct missing local metadata but cannot reopen a revoked epoch.
• Historical worker actions remain auditable against the epoch valid when they were produced.

Benefit: removes ambiguity between replacement, recovery and version reset; reduces stale browser/proxy state races.

6. Require exact authority citations

Every delegated worker action should cite the authority that permits it:

{
  "delegation_event_id": "...",
  "delegation_hash": "...",
  "delegation_epoch": 3,
  "capability": "publish_submission_decisions"
}

Apply this to credential issuance metadata, close events, submission decisions and result summaries where produced by a worker.

Verification must reject actions when the cited grant:

• is missing or malformed;
• was authored by the wrong coordinator;
• belongs to another questionnaire or epoch;
• lacked the cited capability;
• was expired, revoked or superseded at the action's canonical position.

Benefit: independently verifiable delegated authority instead of inference from a worker identity.

7. Separate authoritative, audit, advisory and recovery events

Document and enforce four conceptual planes:

• Authoritative: definitions, delegations, revocations, state/close events.
• Audit: credential proofs, anonymous responses, nullifiers, decisions and summaries.
• Advisory: pending status, delivery acknowledgements and provisional charts.
• Recovery: encrypted self-snapshots and checkpoints.

Advisory and recovery events must never affect ballot admission or counts.

Benefit: clearer security boundaries and reduced risk that UX/status data accidentally becomes consensus state.

8. Make relay migration signed protocol state

Implementation:

• Treat invite relay parameters as bootstrap hints only.
• Keep authoritative relay sets in signed questionnaire/delegation state.
• Define a signed, versioned relay-update event or include relay changes in a versioned definition/state edition.
• During migration, publish critical events to both old and new relay sets for a bounded overlap period.
• Let auditors merge and deduplicate all authoritative relay views.
• Record relay coverage in diagnostics without treating one relay as canonical.

Benefit: questionnaires remain recoverable when relays disappear, reject event kinds, or lose history.

9. Add signed recovery checkpoints without replacing transcripts

A checkpoint may accelerate recovery but must reference, not replace, the public evidence:

• selected definition event/hash;
• current delegation epoch and revocation head;
• close state;
• accepted nullifiers and source response IDs;
• result hash;
• source relay coverage and checkpoint producer.

Auditors must be able to replay source events and verify the checkpoint. A compacted head without its referenced evidence must be displayed as incomplete, not fully audited.

Benefit: faster browser/auditor recovery while retaining public verifiability.

10. Define strict attacker-controlled resource limits

Specify and enforce bounds before parsing, decrypting, decompressing or allocating:

• event/envelope bytes;
• question and answer counts;
• answer lengths;
• invite-code and whitelist entries;
• relay count and URL length;
• proof and configuration structures;
• pagination depth and total fetched events;
• result-pack compressed and uncompressed sizes.

Benefit: predictable behaviour under malformed events and reduced browser/worker denial-of-service exposure.

11. Use signed revocations/tombstones rather than relay deletion

Delegations, invite capabilities and authoritative state should be invalidated by signed protocol events. Relay deletion is only best-effort cleanup and must not be a correctness requirement.

Benefit: revocation remains auditable across relays with different retention/deletion policies.

Explicit Non-Goals

• Replacing RFC 9474 blind credentials with shared community keys.
• Treating key possession as voter eligibility.
• Encrypting the public audit transcript so only members can verify it.
• Using group rekeying instead of one-use credentials and nullifiers.
• Adding real-identity signatures to anonymous ballot events.
• Claiming network anonymity, receipt-freeness or coercion resistance.
• Adopting Concord's reversed NIP-59 stream format without a relay interoperability report.
• Depending directly on Concord while it has no released implementation, conformance suite, test vectors or security audit.

Suggested Delivery Order

1. Fragment-based private invite secrets and URL scrubbing.
2. Normative deterministic fold plus shared reducer and adversarial tests.
3. Delegation epochs and exact authority citations.
4. Signed relay migration and overlap/rebroadcast rules.
5. Resource bounds and signed recovery checkpoints.
6. Optional opaque-mailbox interoperability research spike.

Acceptance Criteria

• A protocol note defines the deterministic fold and conflict rules.
• Organiser and auditor use the same fold implementation for shared event families.
• Newly generated bearer invite secrets never appear in URL query parameters.
• Consumed fragment secrets are removed from the visible URL immediately.
• Delegated actions carry and verify exact election-scoped authority citations.
• Delegation replacement/revocation follows explicit epoch semantics.
• Signed relay migration is tested across old/new relay overlap and duplicate delivery.
• Recovery checkpoints can be independently replayed and cannot silently replace missing evidence.
• Resource limits have boundary and malicious-input tests.
• Existing blind issuance, unlinkable response identity and nullifier properties remain unchanged.
• Relevant protocol, threat-model, README, public explainer and presentation copy are updated with current guarantees and limitations.
• Any opaque-mailbox proposal includes a relay compatibility matrix and metadata-leakage analysis before implementation approval.

References

• Concord README
• CORD-01: Private Streams
• CORD-02: Communities
• CORD-04: Roles and deterministic authority
• CORD-05: Invites
• CORD-06: Rekeys and epochs
• NIP-44 limitations
• RFC 9474: RSA Blind Signatures