Confirmed (#33) that the earlier "reuse the existing revocation-announce/gossip mechanism" idea does not hold once checked against the real code -- needs a real design pass, not a one-line reuse claim.
Three concrete problems to resolve:
revocation-claims is a closed CDDL map (management.cddl:45-50, no * tstr => any tail) -- decide whether it gets an extension tail plus a reason/kind discriminator, or whether redemption needs its own sibling redemption-claims/redemption-announce-frame.- Trust-model mismatch: revocation is issuer-only by design; a redemption fact is naturally attested by whoever received the redemption (the counterparty), often not the issuer. Design how redeemer-side attestation fits (or doesn't) the existing revocation trust model.
- No flood/re-broadcast propagation exists anywhere in the codebase today.
sendRevocationAnnounce (mesh-session.ts:586-599) sends over one direct connection only; nothing re-broadcasts to a receiving peer's own other connections; relay-hub.ts:163 drops these frames on receipt; web-console/src/webrtc-negotiation.ts:36 already documents this as a known gap for revocation itself, let alone redemption. Real propagation design is needed before "detection with propagation delay" is anything more than aspirational.
Until this lands, state plainly in any dependent design that a second presentation of an already-redeemed single-use grant to a peer that hasn't seen the redemption announcement verifies as valid -- not "best-effort detected," since no best-effort mechanism exists yet.
Blocks building any single-use/redemption capability for real (see #33's own finding that no current use case needs one yet, so this can stay a design-only issue until a real use case appears).
Sub-issue of #33.
Confirmed (#33) that the earlier "reuse the existing revocation-announce/gossip mechanism" idea does not hold once checked against the real code -- needs a real design pass, not a one-line reuse claim.
Three concrete problems to resolve:
revocation-claimsis a closed CDDL map (management.cddl:45-50, no* tstr => anytail) -- decide whether it gets an extension tail plus areason/kinddiscriminator, or whether redemption needs its own siblingredemption-claims/redemption-announce-frame.sendRevocationAnnounce(mesh-session.ts:586-599) sends over one direct connection only; nothing re-broadcasts to a receiving peer's own other connections;relay-hub.ts:163drops these frames on receipt;web-console/src/webrtc-negotiation.ts:36already documents this as a known gap for revocation itself, let alone redemption. Real propagation design is needed before "detection with propagation delay" is anything more than aspirational.Until this lands, state plainly in any dependent design that a second presentation of an already-redeemed single-use grant to a peer that hasn't seen the redemption announcement verifies as valid -- not "best-effort detected," since no best-effort mechanism exists yet.
Blocks building any single-use/redemption capability for real (see #33's own finding that no current use case needs one yet, so this can stay a design-only issue until a real use case appears).
Sub-issue of #33.