2 Commits

Include renames

Author	SHA1	Message	Date
4 people	55d51ba084	DMs to unreachable peers use store-and-forward instead of failing instantly (#1415) ... * DMs to unreachable peers route through store-and-forward; drop stale reachability gates Field-found: sendPrivateMessage pre-judged reachability and marked the message failed without ever calling the router, so the retained outbox, courier deposits, and bridge drops never ran — a DM composed after a peer's reachability window lapsed was dead on arrival while an identical one sent a minute earlier delivered. Messages now always route; a live path earns "sent", everything else stays "sending" until the router reports carried/delivered or expires it as failed. A sweep for sibling gates found and fixed: - startPrivateChat refused offline non-mutual favorites ("mutual favorite required for offline messaging") — store-and-forward only needs the recipient's noise key, so the gate and its string are gone. - markPrivateMessagesAsRead skipped the whole receipt pass for peers without a stored Nostr key, starving mesh-connected non-favorites; the router picks the transport now (sentReadReceipts dedups the parallel PrivateChatManager path). - DM/geoDM blocked notices and the unknown-group error posted to the active public timeline; they now land in the thread they're about via addLocalPrivateSystemMessage. - Banned copy: literal "user" fallbacks in code become "anon" (the default-nickname convention), and es/fr/it/pt translations of four keys still saying usuario/utilisateur/utente/usuário now say person. Orphaned keys removed (system.dm.unreachable, content.delivery.reason.unreachable, system.chat.requires_favorite). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Deflake BLEServiceCoreTests: longTimeout for positive waits CI flaked on duplicatePacket_isDeduped: the first message landed after the 5s wait expired on a loaded runner (the test's later count==1 assertions passed, proving late delivery, not lost delivery). All four positive waits in the file now use TestConstants.longTimeout, which exists for exactly this — waitUntil returns as soon as the condition holds, so passing runs never pay the longer ceiling. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Fix read-receipt test contamination; baseline Periphery noiseKey flake Two CI failures, both environmental: - markReadReceiptSent_returnsFalseOnSecondCall flaked because every test ChatViewModel shared one per-process read-receipts scratch suite; the lifecycle test persists the same "read-1" ID (a path the receipt-gate removal now reaches), and test order decided who saw whose state. Each instance now gets its own UUID-suffixed suite. - Periphery intermittently misses the loadFromDisk read of PrekeyBundleStore.StoredBundle.noiseKey and fails --strict with a false "assign-only" finding (recurrence of a known flake). Its USR is baselined; an in-source periphery:ignore can't work because strict mode flags it as superfluous on runs where the indexer gets it right. 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-08 22:42:39 +02:00
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