* Add capability bits to announce TLV
Announces now carry an optional capabilities TLV (0x05): a little-endian
bitfield with named bits for upcoming features (prekeys, wifiBulk,
gateway, groups, board, vouch, meshDiagnostics). Old clients skip the
unknown TLV; peers without it decode as nil so features can distinguish
"legacy peer" from "advertises nothing".
PeerCapabilities lives in BitFoundation with a minimal-length encoding
that preserves unknown bits for forward compatibility. Peer capabilities
are stored in the BLE peer registry on verified announce and exposed via
BLEService.peerCapabilities(_:). The local advertisement set is empty
until each feature ships its bit.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Prekey bundles: forward-secret async first contact for courier mail
Courier envelopes were sealed with one-way Noise X to the recipient's
long-lived static key, so a later compromise of that key exposed every
envelope captured in transit. This adds one-time prekey bundles:
- PrekeyBundle (MessageType 0x24): 8 one-time Curve25519 public prekeys
bound to the owner's Noise static key by an Ed25519 signature over
"bitchat-prekey-bundle-v1" canonical bytes; gossiped mesh-wide on its
own 60s sync round (SyncTypeFlags bit 9, 200-peer cap, 24h freshness)
and verified against the announce-bound signing key before caching.
- Sealed envelope v2: Noise X where the responder static is the one-time
prekey, prologue "bitchat-prekey-v1" || prekeyID. Sender identity rides
encrypted inside and is authenticated exactly like v1 (blocked-sender
check included). CourierEnvelope gains an optional prekeyID TLV that
v1 decoders skip as unknown.
- Local prekeys live in the Keychain; consumed privates survive a 48h
grace window for spray-and-wait redeliveries, then are deleted (the
forward-secrecy clock starts at deletion). The batch tops back up and
re-gossips when unconsumed count drops below 3, and everything is
wiped in panic mode.
- Routing: courier sealing picks a cached verified bundle when one
exists (one prekey per message, reused across deposit retries), with
the advertised .prekeys capability as a veto for on-mesh peers, and
falls back to static sealing otherwise.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Prekeys: authenticate bundle packets, fix consume-republish, deflake CI
Fixes the prekey-bundle PR review + CI failure:
- CI root cause: the receive queue (mesh.message) is concurrent, so a
gossiped prekey bundle can be processed before the announce that binds
its owner's signing key. The old handler dropped such bundles outright,
so under CI parallel load the bundle was permanently lost and the
cache/gossip tests flaked (verifiedBundleEntersGossipStore,
prekeySealedMailTravelsViaCourierAndOpens). Bundles that arrive before
their binding are now retained per-owner (bounded) and re-attempted when
the verified announce lands, atomically to avoid a check-then-act race.
- Authenticate the OUTER prekey-bundle packet (Codex P2 / review MEDIUM):
require senderID == PeerID(bundle.noiseStaticPublicKey) and verify the
packet's Ed25519 signature (covers senderID + timestamp) against the
owner's bound signing key, in addition to the inner bundle signature.
Stops replay under a fresh timestamp / fake senderID.
- Key the gossip prekey-bundle store/dedup by the bundle's authenticated
identity (noiseStaticPublicKey), not the unauthenticated packet
senderID, so one valid bundle sprayed under many fabricated sender IDs
can't multiply entries and exhaust the 200-owner cap.
- Bump published-bundle generatedAt strictly on consume (Codex P1):
consuming a prekey shrinks the published bundle, so it now republishes
with a strictly newer generatedAt and re-gossips, so peers replace the
cached copy and stop assigning the consumed ID before its 48h grace.
- Guard the panic/clear detached Application Support tree-deletes behind
TestEnvironment.isRunningTests: the SPM test process shares that tree,
so the wipe could land mid-test and flake file-dependent tests.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Update sync tests for prekeyBundle as bit 9 / default sync round
Prekeys makes bit 9 (prekeyBundle) a known SyncTypeFlags bit and enables
a prekey sync round by default. That broke tests authored by other PRs
that assumed bit 9 was phantom or that only their own sync round fires:
- SyncTypeFlags(Board)Tests: move the "unknown bits" probes to bits 10+
(0xFE -> 0xFC / 0xFD), since bit 9 is now assigned.
- GossipSync(Board)Tests + GossipSyncManagerTests: disable the prekey sync
round in configs that run maintenance (as they already do for message/
fragment/fileTransfer), so they isolate the behavior under test.
Full app suite (1301 tests) green locally via SPM.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
#1379 (board) mapped bit 8 -> .boardPost in SyncTypeFlags, making it a
known bit that spills the encoded bitfield into a second byte. But the
phantom-bit tests (added by #1373) predate that change and still assert
bit 8 is unknown, so main went red once both landed. Neither PR's CI
caught it — each was green against a main without the other.
The impl is correct (board is a real sync type); the tests were stale.
Update them to treat bits 9+ as phantom, expect the all-known field to
serialize to 2 bytes, and add a regression test that the board bit
survives decode while the phantom high bits are stripped.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Follow-ups deferred from the REQUEST_SYNC review (#1371):
- SyncTypeFlags.init(rawValue:) now masks to the union of bits that map to a
known message type (derived from the bit↔type table, so it tracks new
types automatically). Phantom bits from a truncated/garbled flags field —
or a type a newer peer added — no longer live in the set as membership no
contains() matches yet toData() re-serializes.
- GossipSyncManager stored each latest announce as (hex-id string, packet)
and diffed announces against the stored string while every other type
recomputed the ID via PacketIdUtil. Collapsed the store to just the packet
and recompute the ID everywhere, removing the latent dual-path divergence.
- Documented the REQUEST_SYNC TLV table and marked fragmentIdFilter (0x06)
with a TODO(v2): it's parsed/re-serialized but never populated or honored
(reserved for incremental fragment sync) — finish or drop, not silent dead
surface.
Adds SyncTypeFlags phantom-bit/round-trip tests and a GossipSyncManager test
that an announce already in the requester's filter is suppressed (guards the
recompute path). Full suite: 1034 tests pass.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
