2 Commits

Include renames

Author	SHA1	Message	Date
4 people	87910541ef	Prekey bundles: forward-secret async first contact for courier mail (#1381) ... * 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>	2026-07-07 15:38:33 +02:00
4 people	60be88a4f5	Geohash bulletin board: persistent signed notices over mesh sync (#1379) ... * Add geohash bulletin board: persistent signed notices over mesh sync New MessageType 0x23 carries TLV-encoded board posts and tombstones, self-signed with the author's Ed25519 key ("bitchat-board-v1" / "bitchat-board-del-v1" domains) so notices verify without the author present. BoardStore persists raw signed packets under Application Support/board/ (200 posts, 5 per author, oldest evicted; expiry sweep; tombstones retained until the deleted post's original expiry) and is wiped on panic. Board packets join gossip sync as bit 8 of the existing variable-length types bitfield (a second byte old decoders already accept and ignore), with a 60s round and its own capacity, served straight from the board store so retention has one owner. Posts relay like broadcasts; urgent posts get the announce-class TTL cap. UI: a pin button in the header opens the board for the current channel (geohash board, or mesh-local board), with urgent-pinned newest-first listing, compose with urgent toggle and 1/3/7-day expiry, and swipe-delete on own posts. Geohash posts also publish one-way as Nostr kind-1 location notes when relays are reachable. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Board: bound orphan tombstones and reject future-dated posts at ingest Two hardening fixes from Codex review of the geohash bulletin board: - Orphan tombstones (P1): retention was derived solely from the sender-chosen deletedAt, so self-signed tombstones for unseen post IDs with far-future deletedAt persisted and re-entered sync unboundedly. Retention is now also clamped to receive time (now + 7d + 1h skew -- no post can outlive that), and orphans are capped at 100 globally and 5 per author key with oldest-received evicted first. Matched tombstones and disk restores keep their existing behavior. - Future-dated posts (P2): ingest only checked expiresAt > now, letting posts dated years ahead sort above honest posts and squat the 200 global slots without ever pruning. The single ingest chokepoint (radio, sync, and disk restore all funnel through it) now rejects createdAt > now + 1h skew and expiresAt > now + 7d + 1h skew; the decoder's span rule is unchanged. Adds tests for the skew boundary, far-future expiry, receive-time tombstone clamping, orphan caps/eviction, and matched-tombstone exemption. 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>	2026-07-07 14:13:25 +02:00