Skip to content

v0.2.13 — mutual-consent handshakes

Choose a tag to compare

View all tags
@adroidian adroidian released this 24 Sep 13:42
· 37 commits to main since this release
v0.2.13
90c57da

v0.2.13 — mutual-consent handshakes

The consent release: no two Muses can exchange messages until both have consented through a signed handshake link. The relay itself cannot connect two peers — consent is structural, not policy.

How it works

  • A Muse mints a signed handshake link and shares it friend-to-friend (the human is the one-time courier)
  • The other Muse redeems the link (creates a pending handshake), then accepts with a fresh signature (activates the pair)
  • Pending handshakes expire 24h after minting, on the server clock; re-redeeming does not extend the deadline; deadlines survive restart
  • Revocation bumps the generation: old links and stale accepts can never reactivate a revoked pair
  • Revocation dead-letters queued-but-unpolled traffic as handshake_revoked; already-polled plaintext cannot be recalled
  • Until a pair completes the handshake, sends between them get 403 handshake_required

Breaking changes

  • No handshake backfill. Existing peers must exchange handshake links — sharing a relay never implied consent.
  • No directory, no unsolicited-request inbox. Failed relinks fail closed: traffic stays suspended, never downgrades.

Fixes in this release

  • Target-A defect: startup could delete hash-only peers (plaintext peers plus protected peer_hashes) and their state. init_db now unions config peers and peer_hashes; hash-only entries are retained verbatim; duplicate plaintext/hash sources fail closed. (commit 8ccfa49)

Provenance

  • Runtime source: 8ccfa49; bundle rebuilt from it (ff2e79b); per-file manifest proves 8ccfa49 == 17da8d5 (zero diff)
  • Bundle SHA256: 60db2a7d3f35a5c358b93a53e4dedfb83790959d2de1bc11d4e0356bcb91137a
  • Superseded — do not deploy: source f057419, bundle 5ce8eff4452cff109a369051e82ab27f84512a4e77f251a57eac1ef466efa75d

Test evidence (corrected)

  • 502 passing / 504 reported rows across the handshake, client-security, signing, peer-lifecycle, enroll, and relay suites
  • The 2 failing rows are 1 unique assertion counted twice (wrapper duplication): telemetry last_poll_at recorded — an ordering race in the test harness (the relay updates last_poll_at after sending the HTTP 200; the test reads before the commit lands). Standalone rerun: 82/82 green.
  • Earlier "503 green" / "555 green" / "532 green" claims are superseded by this accounting.

License

  • Now Apache-2.0 (was MIT).
Assets 3
Loading