Its mutable state is confined to the serial pacer queue; the annotation
silences the capture-of-non-Sendable warning in the scheduler callback
(NostrTransport.swift:123) under the app target's concurrency checking.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Reconnect hygiene: paced acks, persistent gift-wrap dedup, self-fragment sync fix
Remaining findings from the July 7 locked-phone test sessions, all rooted
in reconnect/relaunch behavior:
- All Nostr acks (READ and DELIVERED, direct and geohash) now flow through
the paced queue that previously only throttled direct READ receipts.
Reconnect redelivery produced 8 DELIVERED acks in under a second, which
damus rejects ("noting too much").
- Processed gift-wrap event IDs persist across launches
(NostrProcessedEventStore, wired through MessageDeduplicationService,
debounced writes, wiped on the existing clear/panic paths). NIP-59
randomizes gift-wrap timestamps, so the 24h-lookback DM subscriptions
redeliver the same events every launch; without a cross-launch record
each relaunch reprocessed old PMs and acks — the re-ack bursts and the
"delivered ack for unknown mid" warnings (now debug: a stale ack is
expected occasionally and not actionable).
- Own fragments handed back by sync replay (the deliberate RSR ttl=0
restore path) now re-enter the gossip sync store before the self-drop.
The fragment store is not archived, so after a relaunch our sync filter
did not cover our own fragments and peers re-offered them every 30s
round indefinitely; recording them stops the redelivery after one round
while keeping assembly skipped.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Address Codex review on #1398: shared ack pacer, transient clears keep disk record
- Geohash acks are sent through short-lived NostrTransport instances
(makeGeohashNostrTransport creates one per ack), so the per-instance ack
queue never paced a burst. Acks now flow through a pacer shared across
instances: Dependencies.live wires the process-wide sharedAckPacer, and
the default Dependencies init builds an isolated pacer from the same
injected scheduleAfter so tests keep stepping the throttle manually.
- clearNostrCaches() runs on every geohash channel switch, so it no longer
wipes the persisted gift-wrap record (that stays on the clearAll/panic
path). Persistence is now append-merge instead of snapshot-overwrite —
serialized on the store's IO queue — so a transient in-memory clear
between debounced flushes can't shrink the on-disk record either.
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>
Three findings from the July 7 locked-phone test sessions:
- Keychain items move from WhenUnlocked to AfterFirstUnlock: the mesh keeps
running while the device is locked (identity-cache saves failed with
-25308 throughout testing), and a wake-on-proximity relaunch via BLE
state restoration must read the noise keys before the user unlocks. A
one-time SecItemUpdate migration upgrades existing items (retried on next
launch if the device is locked); backup semantics unchanged.
- GeoDM inbound messages dedup by message ID at the handler: outbox retries
re-wrap the same message in fresh gift-wrap events, so relay-level
event-ID dedup can't catch them and every copy ran full processing
(3-6x per message observed). DELIVERED acks still go through
markGeoDeliveryAckSent first, so re-sent copies from a lost ack are
still answered.
- Periodic gossip sync logs now name the type group ("message+fragment").
The five per-type schedules log identical lines when several fire in one
maintenance tick, which reads as duplicated sends (misdiagnosed twice
during testing).
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* BLE background presence: pending-connect wake-on-proximity + wake-window maintenance (#1395)
iOS cancels nothing for us: pending CBCentralManager connects never expire,
complete whenever the peer reappears in range, and relaunch the app via the
existing state-restoration path. Use that as the wake-on-proximity mechanism:
- BLERecentPeripheralCache: retains handles to recently seen/dropped
peripherals (LRU 16, 15 min max age to respect BLE address rotation)
- On backgrounding, arm indefinite pending connects to cached peripherals
within a slot budget (2 of 6 central slots reserved for live background
discovery); armed entries carry lastConnectionAttempt == nil so a quick
background/foreground bounce can't strand them as connecting
- The 8s app-level connect timeout defers while backgrounded so
discovery-driven background connects also stay pending
- Foreground return cancels stale pending connects (including connecting
entries rebuilt by state restoration after a relaunch) and hands control
back to the scanner/scheduler
- A link dropped while backgrounded re-arms after the disconnect-settle
window, so a peer walking away and returning wakes us again
- Packet ingress while backgrounded triggers a catch-up maintenance pass
(announce/flush/drain) since the maintenance timer is suspended with the
app; rate-limited to the normal 5s cadence
Battery cost ~0: pending connects live in the controller's allowlist (no
scanning, no app CPU), and the catch-up pass only runs inside wake windows
the radio already granted.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Restore: seed wake-on-proximity cache and resume service discovery
Field finding from on-device testing: after a state-restoration relaunch,
the recent-peripheral cache starts empty, so backgrounding shortly after a
restore armed no pending connects. Seed the cache from the restored
peripherals — they are the freshest proximity candidates we have.
Also resume service discovery for peripherals restored as connected with no
characteristic: the CBCharacteristic reference dies with the old process,
and without rediscovery the link sits connected-but-unusable until the peer
drops it.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Defer restored-link service rediscovery until poweredOn
Field finding: CBPeripheral.discoverServices issued inside willRestoreState
fires before the central manager reaches poweredOn — CoreBluetooth drops the
command with an API MISUSE warning, leaving restored-connected links
characteristic-less after all. Move the rediscovery to
centralManagerDidUpdateState(.poweredOn), which restoration guarantees runs
afterwards.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Let disconnect re-arms use the freed slot (Codex P2 on #1396)
The background-entry arm reserves 2 of 6 central slots for live discovery,
but the disconnect re-arm path shared that budget: with 4+ links remaining
the budget hit zero and the just-dropped peer was never armed — defeating
walk-away/walk-back re-arming in dense meshes. The disconnect path now arms
with no reserve, consuming the slot the disconnect itself freed.
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>
iOS cancels nothing for us: pending CBCentralManager connects never expire,
complete whenever the peer reappears in range, and relaunch the app via the
existing state-restoration path. Use that as the wake-on-proximity mechanism:
- BLERecentPeripheralCache: retains handles to recently seen/dropped
peripherals (LRU 16, 15 min max age to respect BLE address rotation)
- On backgrounding, arm indefinite pending connects to cached peripherals
within a slot budget (2 of 6 central slots reserved for live background
discovery); armed entries carry lastConnectionAttempt == nil so a quick
background/foreground bounce can't strand them as connecting
- The 8s app-level connect timeout defers while backgrounded so
discovery-driven background connects also stay pending
- Foreground return cancels stale pending connects (including connecting
entries rebuilt by state restoration after a relaunch) and hands control
back to the scanner/scheduler
- A link dropped while backgrounded re-arms after the disconnect-settle
window, so a peer walking away and returning wakes us again
- Packet ingress while backgrounded triggers a catch-up maintenance pass
(announce/flush/drain) since the maintenance timer is suspended with the
app; rate-limited to the normal 5s cadence
Battery cost ~0: pending connects live in the controller's allowlist (no
scanning, no app CPU), and the catch-up pass only runs inside wake windows
the radio already granted.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
P1: TorManager.shutdownCompletely() resets didStart asynchronously
(after Arti has actually stopped, up to ~5s later). A brief
offline->online flap could call startIfNeeded() inside that window;
the guard on didStart dropped it, and nothing reevaluated afterwards,
so Tor stayed down while activationAllowed was true. Track shutdowns
in flight and record a deferred start, honored when the last shutdown
finishes (still gated on allowAutoStart/foreground at that point).
P2: NWPathReachabilityMonitor.ingest() cancelled and rescheduled the
flush a full debounce interval from "now" on every observation, even
duplicates (e.g. interface detail changes while still unsatisfied).
ReachabilityDebounce already preserves the original pending.since, so
schedule the flush for the remaining time to the true deadline instead
of restarting the window.
Tests: debounce deadline preservation (pure) + a monitor-level timing
test that a mid-window duplicate does not postpone the offline commit.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Follow-up to #1391 — the Codex review flagged that the new feature-string
batch stopped at vi, omitting fil, pt-BR, zh-Hans, and zh-Hant.
- Translate the 137 feature strings into fil, pt-BR, zh-Hans, zh-Hant (548 entries)
- Translate fingerprint.message.vouched_by (plural) into the 16 locales it
was missing, with CLDR-correct plural categories per language
- Add the 13 locales missing from the share extension catalog (78 entries),
bringing it to the same 29 locales as the main app
- Mark the '#%@' channel-hashtag format as shouldTranslate=false like '%@'
- Add LocalizationCoverageTests: fails if any translatable key in either
catalog is missing any supported locale, or if the share extension
supports fewer locales than the main app
Machine translations marked needs_review, matching #1391. Verified no
existing translation was altered; full suite (1348 tests) green.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Unified notices: merge board pins and location notes into one sheet
One pin icon in the header now opens a single Notices sheet with a
geo/mesh scope toggle, replacing the separate board, location-notes,
and mesh-only note buttons:
- geo tab: current geohash's notices — mesh-synced board posts merged
and deduped with Nostr kind-1 location notes, with per-item mesh/net
source badges. Scope follows the selected location channel, or the
device's building geohash when chatting on mesh.
- mesh tab: mesh-local board only (fully offline).
- One composer: geo posts go to the board and bridge to Nostr (existing
bridge), so mesh and internet see the same notice.
- Merged delete: tombstoning an own board post now also retracts the
bridged Nostr copy via NIP-09 (new createDeleteEvent, bridged event
ids tracked in BoardManager); own Nostr-only notes are deletable too.
- LocationNotesManager accepts any channel-precision geohash (1-12
chars), not just building-level.
BoardView and LocationNotesView are superseded by NoticesView.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Notices round 2: honest composer, friendlier copy, new-pin chat alerts
- Urgent + expiry controls now appear on the mesh tab only: the bridged
Nostr copy of a geo post carries neither, so relay-side readers would
never see them. Geo posts default to non-urgent with 7-day expiry, and
the bridged note now gets a NIP-40 expiration tag so honoring relays
drop it in step with the board copy.
- Geo tab explainer reuses the original location-notes description
(keeps its 29 existing translations); mesh tab gets a new plain-
language description.
- New-pin chat alerts, fully local (no wire traffic): BoardStore fires
postArrivals for posts newly accepted from the wire; BoardAlertsModel
filters own posts, dedups by postID, and for urgent pins created
within the last 30 minutes emits one system line into the matching
timeline (geo pin -> that geohash's chat, mesh pin -> mesh chat),
collapsing simultaneous arrivals into a count line.
- Routine pins light up the header: the pin icon tints orange whenever
the current scope has notices at all, and fills (pin.fill) while
unseen new pins are waiting; opening the sheet clears them.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* i18n: translate the unified-notices strings into all 28 non-English locales
Adds the 13 new notices keys (sheet title, geo/mesh tabs, mesh
description, source badges, urgent alert lines, button tooltip and
accessibility strings) to the string catalog with translations for
every locale the app ships. The geo tab already reuses the fully
translated location_notes.description; this covers the rest. Insertion
preserves the catalog's case-insensitive key order, so the diff is
purely additive.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Address Codex review: panic-wipe reset, scoped badge clear, geohash-aware dedupe
- BoardStore.wipe() now emits didWipe; BoardAlertsModel subscribes and
resets, so a panic wipe drops pending urgent lines (which could
otherwise re-append pre-wipe content into chat after the collapse
flush), unseen badge scopes, and handled-post history.
- Opening the notices sheet clears unseen badges only for the scopes it
actually shows (mesh + current geo scope); pins for other geohash
channels keep their badge until visited.
- LocationNotesManager.Note now retains the matched g tag, and the
bridged-copy dedupe requires the note's geohash to equal the board
post's — a same-text note from a neighboring cell is no longer
swallowed as a duplicate.
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>
Fills the translation gaps for the strings the feature program added
(capability UI, /ping /trace, board, vouch, prekeys, gateway, groups,
Cashu, Wi-Fi bulk, Tor-offline). 3300 (key,language) pairs added across
28 locales; Spanish was already fully translated, the rest land as
`needs_review` for native-speaker review before shipping.
Purely additive: main's key set (336) and existing translations are
authoritative and untouched. Verified programmatically — 0 removed,
0 changed, exactly 3300 added. (The git diff-stat shows large deletion
counts, but that's line-alignment churn from inserting into a 38k-line
JSON; no content is removed.)
Machine translation only — every `needs_review` entry needs a native
speaker before it can be trusted.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* 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>
* Private groups: creator-managed encrypted group chat over the mesh
Small encrypted crews (hard cap 16) between public broadcast and 1:1 DMs:
Protocol
- MessageType.groupMessage = 0x25: broadcast packets with a cleartext
16-byte group ID + epoch, ChaCha20-Poly1305 ciphertext (epoch bound as
AEAD AAD), inner Ed25519 sender signature over
"bitchat-group-msg-v1"|groupID|messageID|timestamp|content
- NoisePayloadType.groupInvite = 0x06 / .groupKeyUpdate = 0x07:
creator-signed group state (key, epoch, roster) 1:1 over Noise; signature
over "bitchat-group-v1"|groupID|epoch|key-hash|roster-hash and the Noise
session peer must BE the creator
- SyncTypeFlags bit 10 (groupMessage): variable-length LE bitfield widens
1 -> 2 bytes inside the length-prefixed REQUEST_SYNC TLV; old clients
ignore unknown bits and answer with types they know
- PeerCapabilities.localSupported now advertises .groups
Storage
- GroupStore: symmetric keys in the keychain, roster/name/epoch as
protected JSON in Application Support; wiped in panicClearAllData()
Behavior
- Non-members relay 0x25 like any broadcast but cannot read it; group
messages join gossip-sync backfill with the public-message window
- Receivers drop wrong-epoch envelopes, bad sender signatures, and
senders missing from the creator-signed roster
- Fire-and-flood delivery (no per-member acks in v1)
UI
- Groups open as chat windows through the private-chat sheet (virtual
"group_" peer IDs); groups section in the people sheet; /group
create/invite/remove/leave/list commands; invitees get a system message
+ notification and the group appears in their people sheet
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Private groups: fix TLV truncation, roster downgrade, removal notice, block, media, signable bytes
Addresses the Codex review and adversarial-review findings on #1383:
- TLV encoding now throws GroupTLVError.valueTooLong instead of clamping to
65535 and truncating, so an oversize group message fails to seal and
surfaces send_failed rather than shipping ciphertext recipients drop.
- Roster nicknames truncate on a Character boundary (never mid-scalar), so a
multi-byte nickname can no longer make the whole signed roster undecodable.
- Invites now bump the epoch (rotate the key) like removals, giving every
roster change a strictly-increasing epoch so out-of-order invite states no
longer last-writer-wins a just-added member back out.
- Removing a member now sends them a creator-signed roster-without-them under
a throwaway all-zero key (never the rotated key), so their client
deactivates the group and surfaces "removed" instead of going silently dark.
- /block is enforced in the group receive path: a blocked member's messages
are dropped from display and notifications, consistent with every other
inbound path.
- Media affordances are disabled in group chats (both computed sites) so the
composer can't strand a media placeholder that never sends; media-in-groups
is a documented v2 item.
- Creator signature now covers the group name and the sender signature covers
the epoch (wire-format-affecting; needs Android parity before ship).
- Explicit isGroup guard in markPrivateMessagesAsRead so read/delivered
receipts can never leak into group conversations under a future refactor.
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>
* 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>
* Add mesh diagnostics: /ping, /trace, and topology map
- New protocol types ping=0x26 / pong=0x27 (9-byte payload: 8-byte nonce
+ origin TTL) with per-peer inbound rate limiting (5 per 10s)
- /ping @name reports RTT and hop count, 10s timeout
- /trace @name prints the estimated path from gossiped directNeighbors
- Topology map sheet (circular Canvas layout) reachable from App Info
- Ping/pong ride the deterministic directed-relay path like DMs
- Tests: payload round-trip, hop-count math, command output, edge
normalization, layout
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix CI media-wipe race, per-link ping rate limiting, and /ping output routing
Three fixes for PR #1377 review:
1. CI flake (sendImage_privateChatProcessesAndTransfersImage): the
panicClearAllData / clearCurrentPublicTimeline detached utility-priority
tasks delete the real ~/Library/Application Support/files tree, which the
test process shares. The wipe fires at a nondeterministic time and raced
the sendImage test's JPEG in files/images/outgoing (write then re-read),
so prepareImagePacket threw and the test timed out. Both wipes are now
skipped under tests (existing TestEnvironment.isRunningTests pattern);
this also stops test runs from deleting the developer's real media.
2. Codex P1: ping packets are unsigned, so keying the pong rate limiter on
packet.senderID let one connected peer rotate forged sender IDs to bypass
the 5-per-10s budget. The limiter now keys on the ingress link (the
directly connected peer that delivered the packet); the pong still goes
to the claimed sender. Regression test proves rotating senders over one
link exhaust one budget (fails 10 vs 5 pongs on the old code).
3. Codex P2: /ping output arrived up to 10s later and was routed from
selectedPrivateChatPeer at callback time, misrouting the result after a
chat switch. The origin conversation is now captured when the command is
issued (CommandOutputDestination) and deferred output is routed there:
a DM result lands in the origin chat's history even if deselected, and a
mesh-timeline result pins to #mesh instead of the active channel.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* App Info: move NETWORK section under HOW TO USE and uppercase NETWORK/SYMBOLS headers
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Conform DiagnosticsMockContext to sendPublicMessage
CommandContextProvider gained sendPublicMessage (Cashu /pay, #1376) after
this branch forked, so the diagnostics test mock no longer conformed once
main was merged in. Add the no-op stub.
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>
* 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>
* Gateway mode: opt-in mesh↔Nostr uplink for geohash channels
An opt-in "internet gateway" toggle lets one connected phone bridge the
local geohash channel for mesh-only peers: signed kind-20000 events ride
a new nostrCarrier (0x28) packet — directed to the gateway for uplink,
broadcast with TTL for downlink — with Schnorr verification at every
hop, CourierStore-style quotas, and explicit loop-prevention rules.
- BitFoundation: MessageType.nostrCarrier = 0x28
- NostrCarrierPacket: 2-byte-length TLV codec (direction, geohash,
signed event JSON), 16 KiB cap, tolerant decoder
- GatewayService: closure-injected policy layer — verify gates (sig,
kind, #g tag, age, size), uplink quotas (10/min/depositor rate limit,
offline queue of 20 total / 5 per depositor, drop-oldest, flush on
reconnect), downlink budget (30/min, bounded drop-oldest backlog),
bounded loop-prevention ID sets
- BLEService: runtime capability bits (advertise .gateway only while
the toggle is on, re-announce on change), signed directed uplink
sends, carrier ingress with depositor signature verification
- Mesh-only senders uplink automatically from sendGeohash when no relay
is connected and a reachable peer advertises .gateway; once-per-
channel "sent via mesh gateway" notice
- UI: gateway toggle beside the Tor toggle, globe header indicator,
VoiceOver labels, xcstrings entries
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Gateway: harden downlink freshness, uplink verify ordering, and drain
Fixes the confirmed downlink/uplink defects from the PR #1384 review +
Codex findings:
- Downlink age + #g gate (Codex P2 / review #1): rebroadcastRelayEvent
now drops events outside the same freshness window receivers enforce
and whose #g tag mismatches the carrier geohash, BEFORE spending any
budget — so a 1h/200-event channel-resubscribe backfill no longer
burns the 30/min BLE budget on events every receiver drops.
- Rate-limit + dedup before Schnorr (review #2): handleUplinkDeposit now
runs cheap structural checks + carried-ID dedup + rate-token consume
before isValidSignature(), so a replay flood is bounded by cheap work
instead of unbounded main-actor verifies.
- Quota-dropped deposits not rendered (review #3): enqueueUplink reports
acceptance and injectInbound only fires for events actually
published/queued, ending the local-timeline divergence.
- Drain timer + mark-after-send (Codex P2 / review #4): a burst beyond
budget now arms a timer to drain when the window frees; rebroadcast
IDs are marked only after an event is actually sent, so overflow-
dropped events stay retryable.
- Symmetric publish path (review #5): the gateway publish closure now
refuses when no geo relay is known, matching the local send path
instead of publishing dead traffic to default relays.
- Loop-rule doc (review #7): softened to reflect that rule 3 is a
call-site convention with unit-tested backstops; added tests for the
publishedEventIDs backstop, downlink freshness/mismatch, drain timer,
and quota-drop non-injection.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Gateway: stop self-echo of uplinked events onto the mesh
Every event a gateway uplinks to the relays comes back through its own
geohash subscription. `rebroadcastRelayEvent` deduped against
`meshBroadcastEventIDs`, `rebroadcastEventIDs`, and `pendingDownlinks`,
but not `publishedEventIDs` — so an event this gateway just published
was downlink-rebroadcast onto the same mesh it originated from, doubling
BLE airtime per uplinked message and able to starve the 30/min downlink
budget on a busy channel (device-confirmed, filed on #1384).
Fix: also skip the downlink rebroadcast when the event id is in
`publishedEventIDs`. That set is already the bounded (drop-oldest,
capacity maxTrackedEventIDs) loop-rule-2 uplink cache, populated only by
`publish()`, so genuine inbound-from-internet events (never published
here) still rebroadcast normally. Reconciles cleanly with the existing
loop-prevention sets — no new state.
Adds a GatewayServiceTests case asserting an uplinked event that echoes
back via the subscription is not rebroadcast, while a genuine inbound
event still is.
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>
* 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>
* Transitive verification: vouch for verified peers over Noise
When a Noise session establishes with a peer I verified and that peer
advertises the .vouch capability, send signed attestations (up to 16,
most recently verified first, at most once per peer per 24h) for the
OTHER fingerprints I verified. Receivers accept vouches only from
senders they verified themselves, verify the Ed25519 signature against
the sender's announce-bound signing key, and surface the result as a
new derived trust tier: vouched (unfilled seal) between casual and
trusted.
Protocol:
- NoisePayloadType.vouch = 0x12 carries a batch of TLV attestations:
voucheeFingerprint (32B), voucheeSigningKey (32B), timestamp
(uint64 ms BE), Ed25519 signature over
"bitchat-vouch-v1" | fingerprint | signingKey | timestamp.
The voucher is implicit in the authenticated session.
- PeerCapabilities.localSupported now advertises .vouch.
Storage (SecureIdentityStateManager / IdentityCache):
- vouches keyed by vouchee, capped at 8 vouchers each; validity is
recomputed on read (voucher still verified-by-me, < 30 days old), so
unverifying a voucher retires their vouches without cascade deletes.
- New IdentityCache fields are Optional so pre-existing encrypted
caches decode cleanly; TrustLevel.vouched is inserted mid-ladder but
raw values are strings, so persisted values are unaffected (and
vouched itself is never persisted).
- Panic wipe clears vouch state with the rest of the identity cache.
UI: unfilled checkmark.seal badge in the mesh peer list (filled seal
stays exclusive to verified) and a "vouched for by N people you
verified" section with voucher names in FingerprintView; VoiceOver
labels and xcstrings entries included.
Tests: attestation encode/decode + signature (forged/tampered/expired),
accept-policy gates, batch cap, trust-level derivation incl. voucher
invalidation, persistence compat, and coordinator exchange/accept
policies. Full macOS suite: 1088 tests passing.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix CI deadlock in vouch tests and live-refresh the fingerprint sheet on vouch acceptance
Two fixes for PR #1380 review findings:
1. CI "Run Swift Tests (app)" hang (exit 137): the new
SecureIdentityStateManagerVouchTests suite was nonisolated, so Swift
Testing ran its tests in parallel on the Swift Concurrency cooperative
pool. Each test enqueues a queue.async(.barrier) write (setVerified)
and immediately blocks in queue.sync / queue.sync(.barrier)
(recordVouch / effectiveTrustLevel). On CI's few-core runners every
cooperative-pool thread ended up parked behind a pending barrier that
never got a dispatch worker, deadlocking the whole test process until
the watchdog SIGKILLed it. The suite is now @MainActor, matching the
production isolation of the vouch API (ChatVouchCoordinator is
@MainActor) and keeping blocking syncs off the cooperative pool.
2. Codex P2: an open fingerprint sheet did not refresh its vouched badge
when a vouch batch was accepted - VerificationModel.bind() never
observed the trust-change signal. It now subscribes to the
"peerStatusUpdated" notification that
ChatVouchCoordinator.notifyPeerTrustChanged() posts (same source
PeerListModel uses) and forwards it to objectWillChange. Added a
regression test that pins VerificationModel's own subscription
(verified to fail without the fix).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Skip media-wipe detached tasks under tests (shared-filesystem race)
panicClearAllData and clearCurrentPublicTimeline delete the real
~/Library/Application Support/files tree in detached utility-priority
tasks. The SPM test process shares that tree and ChatViewModelTests
invoke both methods, so under parallel scheduling the wipe lands at a
nondeterministic time — deleting media a concurrently running test just
wrote (and the developer's real app data with it). Guard both with the
existing TestEnvironment.isRunningTests pattern, mirroring the same fix
on feat/mesh-diagnostics (#1377).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Port vouch capability-race fix to feat/vouching (ports b8adcbe9)
Ports the on-device-confirmed fix from the integration test branch
(commit b8adcbe9) onto feat/vouching so PR #1380 is actually correct.
On-device testing confirmed the transitive vouch propagated once the
send was triggered on verify / announce arrival rather than auth alone.
Vouch attestations only ever sent from peerAuthenticated, gated on the
peer's .vouch capability. That capability arrives via the peer's announce,
processed independently of the Noise handshake, so at auth time the set was
usually empty -> gate failed -> vouch silently skipped and never retried.
- Refactor the send path into a reusable attemptVouch(to:fingerprint:now:).
- Trigger on peer-list updates (peersUpdated): fired after every verified
announce, so the batch goes out once the .vouch bit actually arrives.
- Trigger on local verification (vouchToConnectedVerifiedPeers): verifying a
peer runs a vouch pass over connected verified peers, covering the
verify-while-connected case and propagating the new identity onward.
- Relax the capability gate: treat an empty/unknown set as eligible (the
Noise 0x12 payload is ignored by non-supporting peers); only skip when a
non-empty set explicitly lacks .vouch.
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>
* Originate v2 source routes and wire fragmentIdFilter targeted resync
Part A — source-route origination policy:
- Gate route application (BLESourceRouteOriginationPolicy): only packets we
author, directed at a single peer, with TTL headroom, whose recipient is
not directly connected. Relays no longer attach routes to (and re-sign)
packets they merely forward.
- Version-gate paths: MeshTopologyTracker records the highest protocol
version observed per peer; BFS routes require every intermediate hop and
the recipient to be v2-observed, capped at 4 intermediate hops.
- Degrade on failure: BLESourceRouteFailureCache marks a routed send that
sees no inbound traffic from the recipient within 10s as failed and floods
for 60s before retrying routes.
Part B — REQUEST_SYNC fragmentIdFilter (TLV 0x06):
- Requester: BLEFragmentAssemblyBuffer reports stalled broadcast
reassemblies (no new fragment for 5s, retried at most every 10s); the
maintenance pass sends a types=fragment REQUEST_SYNC naming the stalled
8-byte fragment stream IDs to each connected peer.
- Responder: GossipSyncManager restricts the fragment diff to exactly the
named streams, bypassing the since-cursor while the GCS filter still
excludes pieces the requester holds; RSR/TTL-0/rate-limit semantics
unchanged and REQUEST_SYNC stays link-local.
- Bounds: at most 60 IDs per request (60*17-1 = 1019 bytes <= the 1024-byte
decoder cap); oversized 0x06 values are ignored, not fatal.
Docs: SOURCE_ROUTING.md gains the iOS origination policy (§8);
REQUEST_SYNC_MANAGER.md documents 0x05/0x06 as implemented.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix stall-clock refresh on duplicates and overflow suppression in fragment resync
Two fixes to stalledBroadcastFragmentIDs bookkeeping in
BLEFragmentAssemblyBuffer:
- Duplicate fragments no longer reset the stall clock. Fragment packets
bypass the packet deduplicator, so relayed duplicates of an
already-held index arriving every few seconds kept lastFragmentAt
fresh and suppressed the targeted REQUEST_SYNC indefinitely. Now
lastFragmentAt only updates when the index is new (actual progress).
- Only the streams that will actually be encoded on the wire are
rate-limited. Previously every stalled candidate got
lastResyncRequestAt set, but encodeFragmentIdFilter serializes at most
RequestSyncPacket.maxFragmentIdFilterCount (60) IDs, so overflow
streams were suppressed for retryAfter without ever being requested.
Selection now caps at that shared constant, oldest stall first, so
overflow stays eligible and rotates fairly on the next pass.
Tests: duplicates arriving periodically still trigger the stall report;
70 stalled streams yield the 60 oldest on the first pass and the
remaining 10 on the next.
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>
* Cashu ecash chips: detect, render, and redeem tokens + /pay command
Content-level Cashu support, no wire-protocol changes:
- CashuTokenDecoder: summarizes V3 (cashuA base64url-JSON) tokens —
amount summed across proofs, unit, mint host, memo — and V4 (cashuB)
via a minimal bounded CBOR reader. All input is treated as
adversarial: size caps, depth/item budgets, overflow guards, display
sanitization; malformed payloads fail closed to a generic chip.
- PaymentChipView: cashu chips now show "500 sat · mint.example.com"
(+ memo) instead of a generic label; tap opens a cashu: wallet URL
and falls back to https://redeem.cashu.me when no wallet handles it;
context menu adds copy token / redeem in wallet / redeem on web.
- extractCashuLinks now returns bare deduplicated bearer strings so the
chip can decode them (cashu: URIs still detected via the embedded
token).
- /pay <token>: validates the token decodes, sends it as the message
body; DMs send directly, public channels require an explicit
"/pay <token> public" confirm since tokens are bearer instruments.
Suggested everywhere except public geohash channels.
- Tests: decoder (V3/V4 decode, summation, URI forms, truncation/
garbage/huge fuzzing, CBOR depth bounds) and /pay command flows.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Cashu: strict decode on the /pay SEND path
The permissive decoder turned any non-empty cashuB… base64 that failed
CBOR parsing into a generic TokenInfo, so the /pay guard accepted base64
junk and truncated V4 tokens and relayed them with a success message.
Add a `strict` flag to CashuTokenDecoder.decode: in strict mode there is
no permissive V4 fallback and the token must resolve to a known version
with a positive amount, else it returns nil. Rendering keeps the
permissive path (an unknown chip is fine for display). /pay now decodes
with strict:true and surfaces "invalid cashu token" instead of sending.
Tests: /pay with truncated cashuB / base64 junk is rejected; valid V3
and valid definite-length V4 still send; decoder strict-mode unit tests.
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>
* 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>
* NIP-13 proof-of-work for geohash channels: mine on send, relax rate limits for PoW senders
Outgoing kind-20000 geohash messages mine a NIP-13 nonce tag (8 leading
zero bits, ~256 hashes, typically <1 ms) off the main actor before
signing. Mining is hard-capped at 2 s and cancellable (newer send or
channel switch): on cap/cancel the committed target steps down so the
message still ships promptly with an honest commitment - sending is
never blocked and nothing is dropped. The hot loop serializes the
canonical event once and rewrites only the fixed-width nonce bytes.
Inbound kind-20000 events are scored per NIP-13 commitment semantics
(committed target counts; the ID must actually meet it, extra work
earns nothing) and never hard-rejected: validated PoW >= 8 bits skips
the per-sender rate-limit bucket while the per-content flood bucket
still applies, so old non-mining clients keep working under today's
strict limits while bulk spam gets expensive.
Presence heartbeats (kind 20001), kind-1 notes, and DMs are unchanged;
no UI beyond a pow= field in an existing sampled debug log.
Reimplemented from scratch rather than cherry-picking the stale
feature/pow-geohash-mining-ui branch (unbounded loop, hard receive
filtering, mining UI, XCTest, force unwraps).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Geohash: serialize PoW sends so order matches send order
Two location-channel sends back-to-back only cancelled the previous
mining task and started a new one. Cancellation merely *expedites* NIP-13
mining (the target is polled and steps down; it never aborts the send),
so the cancelled task still appended + relayed once mining returned. Both
tasks ran concurrently and the second (shorter to mine) could finish
first, reordering messages in the timeline and on relays.
Chain the mining tasks: each geohash send captures the previous send's
task, cancels it (to expedite, so delays never stack), and awaits its
completion before it echoes and relays. Order is now always send order.
The >2s mining cap is preserved: cancellation expedites the awaited task,
so a send is never blocked beyond NostrPoW.miningTimeCap.
Test: two rapid sends where the first mines longer (larger content) still
land in send order for both the local echo and the relayed events.
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>
On a mesh-only/offline device the app used to bootstrap Tor and spin
Nostr relay reconnects forever ("connecting to Tor…"), wasting battery
even when there was provably no network path at all.
Add an NWPathMonitor-backed reachability signal (NetworkReachabilityMonitor)
and fold it into NetworkActivationService's activation gate:
- Tor bootstrap and relay connect/reconnect are now gated on the network
path being usable. When the path is fully unsatisfied (no interface at
all) we set autoStart off, shut Tor down, and disconnect relays instead
of looping. When a usable path returns we resume.
- Conservative policy: only NWPath.Status.unsatisfied counts as offline.
A flaky-but-present link stays "reachable" (Tor tolerates intermittent
connectivity); we never tear down on the first hiccup.
- Transitions are debounced (ReachabilityDebounce, ~2.5s) so path flapping
cannot thrash Tor/relay startup. The debounce is a pure value type,
unit-tested without the Network framework or real timers.
- Starts optimistic (reachable) so nothing is suppressed before the first
path evaluation arrives.
- BLE mesh never consults this gate and works fully offline.
- NWPathMonitor's background callback hops to the main actor before
touching any state.
Surfaces NetworkActivationService.isNetworkReachable for UI to distinguish
"offline" from "connecting to Tor".
Tests: pure debounce (satisfied → allowed, unsatisfied → suppressed after
interval, flap debounced, recover-after-outage) plus service wiring
(unreachable suppresses Tor+relays, recovery resumes, loss disconnects).
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
- BitchatProtocol.swift: stop advertising "timing obfuscation prevents
traffic analysis" — what exists is randomized relay jitter
(RelayController, 10-220 ms) and PKCS#7-style padding to
256/512/1024/2048-byte blocks (MessagePadding); there is no cover
traffic or per-message timing obfuscation. Also update the stale
Message Types list (Delivery/Read are Noise payloads, no Version
negotiation type; add CourierEnvelope/RequestSync/FileTransfer).
- MessageType.swift: header said "6 essential" types; the enum has 9
cases.
WHITEPAPER.md needed no changes: the #1372 rewrite already replaced the
old Bloom-filter and MessageRetryService claims, and its numbers
(dedup 1000/5min, jitter, outbox 100/peer 24h 8 attempts, courier
16 KiB/24h/40-20-5-2 quotas, spray 4/8, gossip 1000/15s/6h) all match
the code.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
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: 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>
Store-and-forward previously delivered to an out-of-range peer only if a
mutual favorite happened to be connected at send time and later met the
recipient directly, and everything except courier envelopes died with the
app process. This closes those gaps end to end:
- Persist the MessageRouter outbox to disk, sealed with a ChaChaPoly key
held only in the Keychain (no plaintext at rest); queued private
messages now survive an app kill and flush on next launch.
- Deposit retry: queued messages are re-deposited whenever a new eligible
courier connects, tracked per message so the same courier is never
double-burned, until 3 distinct couriers carry it or it expires.
- Tiered open couriering: signature-verified strangers can now carry mail
(2 envelopes/depositor into a 20-slot pool) alongside mutual favorites
(5 each); overflow evicts verified-tier mail before favorites'.
- Spray-and-wait: envelopes carry a copy budget (4, capped 8, new TLV,
wire-compatible with old clients); couriers split half their remaining
budget with each newly encountered courier so mail diffuses through a
moving crowd.
- Remote handover: a verified relayed announce now floods a copy toward
the multi-hop recipient (directed-relay treatment, 10-min per-envelope
cooldown) while the carried original stays put for a direct encounter.
- Public history: gossip-sync window for whole public messages widened
from 15 min to 6 h, matched on the receive-acceptance side, and the
message store persists to disk so devices bridge partitions and
restarts ("town crier").
- Privacy-safe local delivery counters (bare tallies, log-only) so the
store-and-forward stack is measurable on-device.
- Panic wipe now also clears the sealed outbox, gossip archive, and
counters.
- Rewrite WHITEPAPER.md to describe the app as implemented (Noise XX/X,
actual flood control, courier system, gossip sync, Nostr path); the old
document described a bloom filter, three fragment types, and a
MessageRetryService that don't exist.
1037 macOS tests pass (17 new); iOS builds.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Harden REQUEST_SYNC and stop gossip-sync re-send loops
Two fixes from an end-to-end review of the sync path:
Efficiency: the GCS filter (400B, p=7) covers ~355 packet IDs, but stores
hold up to 1000 messages + 600 fragments + 200 files. Once a mesh
accumulates more than the filter can cover, responders re-sent the entire
older tail to every requester every round — ~120KB per pair per 30s during
file transfers, dropped by dedup after the airtime was already burned.
Requesters now stamp the dormant sinceTimestamp TLV with the oldest
timestamp their filter covers, and responders skip older packets (announces
exempt: they carry the signing keys needed to verify everything else).
Periodic sync also sends one request per type schedule instead of a union
filter, so fragment floods can't crowd messages out of the filter budget.
Security: a ~40-byte unsigned REQUEST_SYNC with an empty filter could elicit
a full store replay (~900KB) — an unauthenticated >10,000x amplification
vector, repeatable in a tight loop and relayable with crafted TTL to fan the
drain out of every reachable node. Requests now require ttl == 0, a valid
signature from the claimed sender's announced signing key, and a matching
link binding; REQUEST_SYNC is never relayed regardless of TTL; and responses
are rate-limited per peer (8 per 30s sliding window, ~3x the legitimate
cadence).
Cross-platform: verified against bitchat-android — it signs REQUEST_SYNC and
sends SYNC_TTL_HOPS = 0, so both gates hold; it neither sends nor honors
sinceTimestamp yet, so mixed pairs keep today's behavior with no regression.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Address Codex review: enforce no-relay on route path, exact since-cursor
Two P2 findings from Codex on the REQUEST_SYNC hardening:
- Route-forwarding bypass: handleRequestSync's early return for a rejected
(nonzero-TTL / unsigned) request still fell through to
forwardAlongRouteIfNeeded, which relays any routed packet with ttl > 1
regardless of type. The no-relay invariant was only enforced on the flood
path. BLERouteForwardingPolicy now suppresses REQUEST_SYNC outright, so a
crafted request with a route and TTL headroom can't be forwarded to the
next hop either.
- Inexact since-cursor: GCSFilter.buildFilter trimmed by hash order when the
encoding overflowed the byte budget, so the cursor (computed from the
untrimmed prefix) could claim coverage of timestamps whose packets were
dropped from the filter — re-sending exactly those every round. buildFilter
now trims from the input tail (oldest, since candidates are newest-first)
and reports includedCount; the cursor is derived from that, so the covered
set is always a contiguous newest-prefix and the cursor is exact.
Adds GCSFilter includedCount coverage (full vs trimmed), a route-forwarding
test for REQUEST_SYNC, and makes the truncated-cursor test robust to trim
variance. Full suite: 1029 tests pass.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
The version lived in five places: Release.xcconfig (which Debug
includes) plus four literal per-target overrides in the pbxproj that
shadow it. A bump that misses any subset splits app and extension
versions, and App Store validation rejects the archive
("CFBundleShortVersionString of an app extension must match its
containing parent app"). Remove the pbxproj entries so every target in
every configuration inherits the one xcconfig value; verified all six
target/config combinations resolve to 1.5.4 via -showBuildSettings.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Deposit with couriers in parallel when the only route is a send queue
The courier path was nearly unreachable: NostrTransport claims any
favorite with a known npub as "reachable" regardless of connectivity,
and the mesh favorite exchange shares npubs, so for essentially every
courier-eligible recipient the router picked Nostr's reachable branch.
With no internet the message just sat in the relay send queue — in the
flagship scenario (internet shutdown, mutual friend standing right
there) the courier walked away carrying nothing.
Add Transport.canDeliverPromptly(to:), defaulting to reachability for
radio-backed transports; NostrTransport answers honestly by mirroring
the relay manager's connection state (fail-closed behind Tor). When the
chosen transport can't hand the message off promptly, the router now
also deposits a sealed copy with connected couriers. Double delivery is
harmless: receivers dedup by message ID, and delivered/read acks never
downgrade the carried status. When relays are up, sends are trusted and
no courier quota is spent.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Track DM-relay connectivity, not any-relay, for prompt delivery
Codex review: NostrRelayManager.isConnected is true when any relay is
up, including geohash/custom relays — but private messages target the
default (gift-wrap-capable) relay set and queue when none of those are
connected. A lone geohash relay would have suppressed the parallel
courier deposit while the DM sat in the queue. Publish a DM-scoped
connectivity flag and drive canDeliverPromptly from it.
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>
* Friend-courier store-and-forward: mutual favorites carry sealed messages to offline peers
When a private message has no reachable transport, the router now seals it
to the recipient's Noise static key (new one-way Noise X pattern) and hands
the envelope to up to three connected mutual favorites. Couriers store the
opaque ciphertext under strict quotas (20 total, 5 per depositor, 16 KiB,
24 h) and hand it over when the recipient's announce matches a rotating
HMAC recipient tag; the recipient opens it and the message flows through
the normal private-message pipeline, so dedup and delivery acks just work.
- CourierEnvelope TLV + courierEnvelope (0x04) message type in BitFoundation
- Noise X one-way pattern reusing the existing handshake machinery,
domain-separated by a courier prologue; sender identity authenticated
via the ss DH (no forward secrecy - documented tradeoff)
- CourierStore with eviction, file persistence, and panic-wipe integration
- Rotating recipient tags (HMAC over epoch day) so carried envelopes don't
correlate for observers who don't already know the recipient's key
- New "carried" delivery status with figure.walk glyph; header indicator
while carrying mail for others
- Three-node end-to-end test ferrying packets through real BLEService
instances, plus codec/crypto/store/router suites (986 tests green)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix courier handoff verification and directed sends
* Authenticate courier deposits by ingress peer
* Gate courier handover on direct announces and isolate store test
Envelopes are removed from the courier store optimistically, so releasing
them on a relayed (multi-hop) announce risks losing carried mail to a
speculative flood that never reaches the recipient. Handover now also
requires the announce to have arrived directly (full TTL), i.e. an actual
encounter with a live link; regression test builds a relayed copy of a
genuinely signed announce (TTL is excluded from announce signatures).
Also make CourierStore's on-disk location injectable so the persistence
test round-trips through a temp directory instead of wiping the real
Application Support store, and reattach BLEAnnounceHandler's doc comment
to the class it describes.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Use Xcode-bundled Swift in CI instead of a standalone toolchain
The unpinned setup-swift action installs Swift 6.1, which refuses the
SDK on runner images that have rolled to Xcode 26.5 ("this SDK is not
supported by the compiler"). Jobs passed or failed depending on which
image they landed on. The Xcode-bundled toolchain always matches the
image's SDK, and matches local development. Cache keys now include the
toolchain version so artifacts from one compiler are never restored
into builds with another.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Drop couriered mail from blocked senders at envelope open
The UI-layer block check (isPeerBlocked in the transport event
coordinator) resolves a fingerprint from the live session or peer list,
but a couriered message arrives precisely when its sender is absent —
no session, no registry entry — so the check failed open and a blocked
identity's mail was delivered anyway. Gate in openCourierEnvelope,
where the sealed sender's full static key is in hand.
End-to-end test ferries a full deposit→carry→handover round and
verifies the envelope from a blocked sender never reaches the delegate
(confirmed failing without the gate).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix favorites end-to-end: peer-list dedup, Nostr sync, /fav key corruption
- UnifiedPeerService: dedup offline favorites against mesh peers by noise
key. Phase 2 compared a 64-hex noise-key PeerID against 16-hex mesh IDs
(never equal), leaving only a nickname+isConnected heuristic — a mutual
favorite that was reachable-but-not-connected or renamed rendered twice,
and a same-nick stranger could suppress a favorite entirely.
- Nostr inbound: intercept [FAVORITED]/[UNFAVORITED] markers in the live
PM handler so they update theyFavoritedUs instead of rendering as chat
text; mutual favorites can now form over Nostr. Delete the dead
favorite-aware PM variant and ChatNostrCoordinator.handleFavoriteNotification
(unwired, parsed a stale FAVORITE:TRUE|… format no sender emits).
- NostrTransport.isPeerReachable: match short form regardless of incoming
ID width — toggling an offline favorite (addressed by 64-hex noise key)
was silently dropped with no reachable transport.
- BLEService.sendPrivateMessage: normalize recipient to the short ID like
sendFilePrivate, so a 64-hex target hits the existing Noise session
instead of initiating a handshake with a 32-byte wire recipient ID.
- /fav, /unfav: stop writing Data(hexString: peerID.id) — the 8-byte
routing ID for mesh peers — into the favorites store as a "noise key",
and stop double-sending the favorite notification; delegate to
toggleFavorite with a proper state check.
- FavoritesPersistenceService.updatePeerFavoritedUs: keep the stored
nickname when the caller passes the "Unknown" placeholder.
- Bump marketing version to 1.5.4.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Route DMs to mutual favorites via Nostr when a mesh-keyed peer goes offline
Field-tested on device: with a DM window opened while the peer was on
mesh (conversation keyed by the short 16-hex ID), walking out of range
and sending failed instantly with "peer not reachable" even though the
header showed the peer as Nostr-reachable (mutual favorite, npub known).
sendPrivateMessage derived the favorites key as Data(hexString:
peerID.id) — for a short mesh ID that is the 8-byte routing ID, never
the noise key — so the mutual-favorite/Nostr-key checks always came up
empty and the send failed before reaching MessageRouter. Conversations
keyed by the full 64-hex noise-key ID (opened from the offline favorite
row) were unaffected, which is why later tests appeared to work.
Resolve the noise key properly (peerID.noiseKey, then the unified peer
row, then the favorites store by derived short ID) and add a regression
test for the mesh-keyed-peer-goes-offline case.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Label Nostr DMs from favorites with their stored nickname
Field-tested: a DM delivered over the Nostr fallback rendered as
"anon#678e" instead of the sender's name. The inbound handler named the
sender via displayNameForNostrPubkey, which only knows geohash-scoped
names — even though the pipeline had already resolved the sender's
noise key (the conversation is keyed by it).
When the conversation key carries a noise key, prefer the favorite's
stored nickname; geohash DMs (nostr_ keys) keep the anon geo name. This
also stops an inbound Nostr [FAVORITED] from overwriting the stored
nickname with the anon fallback, since the same name feeds
updatePeerFavoritedUs.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix courier path for offline favorites addressed by noise-key IDs
Two Codex review findings, both the same ID-width confusion this PR
targets, in the courier flow:
- CourierDirectory.favoritesBacked resolved recipients only via
getFavoriteStatus(forPeerID:), which requires a short 16-hex ID —
offline favorites are addressed by the full 64-hex noise-key ID, so
attemptCourierDeposit silently bailed for exactly the peers couriers
exist to serve. The 64-hex ID now yields its own key directly.
- openCourierEnvelope emitted the derived short mesh ID even when the
sender has no live mesh identity, landing couriered mail in an
unresolvable short-ID thread labeled "Unknown". Absent senders now
emit the full noise-key ID so the message joins the stable favorite
conversation; present senders keep the live short-ID thread.
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>
* Fix lock glyph alignment, privacy-caption band, and empty-state wrapping
- Message-row locks: align to first text baseline instead of a hardcoded
top padding that left the lock ~4pt below the line's visual center
- Header/caption locks: 1pt optical lift (lock.fill ink is bottom-heavy;
geometric centering reads low); seal badge stays untouched
- DM privacy caption: sit on the themed surface like the rest of the
bottom chrome instead of painting its own orange band
- Empty-state lines: non-breaking spaces so the closing * can't orphan
and 'bitchat/ for help' can't break right after the slash
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Unify sheet close buttons, widen tiny tap targets, handle long nicknames
- New SheetCloseButton component: one glyph size/weight (13 semibold),
32pt visual box, 44pt hit target; adopted by all 7 sheets (sizes had
drifted across 12/13/14pt, two had no frame at all)
- Favorite star buttons get real tap targets (peer list + DM header)
- DM header nickname: single line with middle truncation instead of
wrapping into the fixed-height header; peer-list names truncate tail
- Geohash people rows: leading glyph 12 -> 10 to match mesh rows
- Sidebar lock glyphs get the same optical lift as the DM header
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Make channel switching, voice notes, and header actions work under VoiceOver
- Channel rows in the location sheet are now single activatable buttons
(label + selected trait + switch hint) with the bookmark toggle
mirrored as a named accessibility action; bookmark buttons labeled
- Voice-note mic: press-and-hold drag gestures can't be activated by
VoiceOver, so the default accessibility action now toggles
start/stop-and-send; announces 'recording' state; localized labels
- Attachment button: camera (long-press) path exposed as a named
action; labels localized instead of hardcoded English
- People-count button announces connected vs no-one-reachable (was
color-only); verification QR button gains a spoken name (.help is
only a hint on iOS); bitchat/ logo exposes its tap-for-app-info as a
button (panic triple-tap stays undiscoverable on purpose)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Theme-correctness sweep: palette colors everywhere, AX-size header growth
- Fingerprint/verification sheet cards: palette-tinted boxes instead of
fixed gray bands that ignored matrix green and occluded glass
- Voice-note card: palette background (translucent) instead of opaque
white/black; waveform + payment chips + image placeholder follow suit
- .secondary/.primary/Color.blue swapped for palette.secondary/primary/
accentBlue across location sheets, people sheets, message captions,
and the header count (system gray read wrong under matrix green)
- Autocomplete/command rows: dropped the uniform gray wash that dulled
the themed overlay panel
- 'tap to reveal' caption follows the theme font instead of hardcoding
monospaced
- Headers use minHeight so two-line accessibility text sizes grow the
bar instead of clipping inside it
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix main header expanding to fill the screen
The header bar's fixed height was load-bearing: its children fill the
bar with .frame(maxHeight: .infinity) tap targets, so switching to an
open-ended minHeight let the header expand to swallow all available
vertical space, centering the title mid-screen and crushing the
timeline into the composer. Restore the fixed height — headerHeight is
a @ScaledMetric, so it already grows with Dynamic Type. Reproduced and
verified both layouts with an offscreen render harness.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* DM header: floating glass panel instead of muddy orange wash under glass
Orange at 14% over the backdrop gradient reads as a gray-beige band,
not a privacy signature. Under liquid glass the DM header now uses the
same floating chrome panel as the main header; the private signature is
already carried by the orange lock, caption, and composer accents.
Matrix keeps its orange wash over the opaque themed surface, unchanged.
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>
Four spurious CI failures on July 5, all loaded-runner flakiness:
- ViewSmokeTests.voiceAndMediaViews_renderAndWarmCaches asserted an exact
bin count on WaveformCache.shared for the same URL the mounted
VoiceNoteView was concurrently warming at its default 120-bin width;
whichever barrier write landed last owned the entry. Probe the cache with
a dedicated audio file no view touches, and purge both URLs. Also replace
the fixed 250ms sleep for loadDuration's background hop with a waitUntil
poll.
- sendImage_privateChatProcessesAndTransfersImage (and its sendVoiceNote /
sendImage siblings) wait on work that hops through Task.detached; the
global executor is shared with every parallel test worker, so a loaded
runner can exceed the 5s wait. Raise those positive waits to
TestConstants.longTimeout (10s) — waitUntil returns as soon as the
condition holds, so passing runs are unaffected.
- subscribeNostrEvent_addsToTimeline_ifMatchesGeohash raced concurrently
running suites (e.g. CommandProcessorTests) on the process-wide
LocationChannelManager singleton: a mid-test channel flip reroutes or
drops the event permanently, so no fixed wait recovers. The wait loop now
re-asserts the channel and redelivers the event on each poll — idempotent
because channel switches clear the processed-event set and the store
dedups by message ID — so interference heals while genuine failures still
time out.
- The performance floor gate failed on a saturated runner
(gcs.buildAndDecode at 85% of floor). check-perf-floors.sh now re-runs
the benchmark suite up to twice when a metric lands below floor,
appending to the same PERF log and keeping each benchmark's best value
across attempts: noise clears on a retry, a real algorithmic regression
fails every attempt. Floors are unchanged and never lowered by the
mechanism; missing-benchmark failures exit immediately without retrying.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
CommandProcessor results (/help text, errors like "unknown command",
/msg confirmations) were always appended to the public timeline via
addSystemMessage, so a command typed inside a DM appeared to do
nothing until the user switched back to the public channel.
handleCommand now routes .success/.error output to the open private
chat when one is selected, falling back to the public timeline
otherwise. The DM selection is read after processing so commands that
switch chats (/msg) print into the conversation they just opened.
Follow-up to #1354, which added /help and surfaced this routing gap.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Mechanical style fixes across the enabled rule set, mostly via
swiftlint --fix (trailing_comma, comma, colon, trailing_newline,
comment_spacing, unused_closure_parameter, unneeded_break_in_switch,
opening_brace) plus hand fixes:
- non_optional_string_data_conversion (45): .data(using: .utf8)! and
?? Data() fallbacks replaced with the non-optional Data(_.utf8),
including two production sites (NIP-44 HKDF info constant and the
announce canonicalization context/nickname bytes — byte-identical
output, only the impossible-nil handling is gone).
- switch_case_alignment: LocationChannel had a misindented closing
brace; also repaired an --fix artifact in BLEService's .none case.
- redundant_string_enum_value: TrustLevel raw values equal to the case
names (encoded form unchanged).
- unused_optional_binding: let _ = binds replaced with != nil / is Bool.
- static_over_final_class: PreviewView.layerClass.
- Resolved the BinaryProtocolTests TODO by documenting that 8-byte
recipient ID truncation is the fixed wire-field size, not a bug.
The 4 remaining violations are all todo markers for a shared
test-helpers module (tracked in #1088) and one Reuse note.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
The unpinned setup-swift action installs Swift 6.1, which refuses the
SDK on runner images that have rolled to Xcode 26.5 ("this SDK is not
supported by the compiler"). Jobs passed or failed depending on which
image they landed on. The Xcode-bundled toolchain always matches the
image's SDK, and matches local development. Cache keys now include the
toolchain version so artifacts from one compiler are never restored
into builds with another.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Bisecting (base was 4/4 clean, branch 3/3 hung, reliably reproducible)
pinned the parallel-suite exit hang to the public-message signature
requirement (security fix#2), via FragmentationTests:
reassemblyFromFragmentsDeliversPublicMessage and
duplicateFragmentDoesNotBreakReassembly send fragments of an UNSIGNED
public message and `await capture.waitForPublicMessages(...)`. With #2 the
reassembled unsigned message is now (correctly) dropped, so
didReceivePublicMessage never fires. The helper then trips a latent bug:
on timeout it cancels the waiter task but never resumes its
CheckedContinuation, so the throwing task group's teardown awaits a child
that never completes and the whole test process hangs at exit (SIGKILL'd
by CI). Base never hit it because the message always arrived in time.
Fix matches the security model — real public broadcasts are signed: sign
the reassembled packet with a NoiseEncryptionService and preseed the
sender's signing key (same pattern as duplicatePacket_isDeduped), so #2
verifies and delivers it. Full parallel suite now exits cleanly 5/5 locally
(branch was 3/3 hung before).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The app test job hung at process exit (all tests pass, then SIGKILL at the
CI timeout). Root cause: fix#5 replaced the dead Timer.scheduledTimer with
a real DispatchSourceTimer, created per manager instance, resumed and never
cancelled. Those live timer sources kept the dispatch machinery alive so the
swift-testing process never exited. The earlier `isRunningTests` guard was
fragile (it does not reliably detect the swift-testing-only runner on CI).
Drop the debounce timer entirely. Mutations now persist via the same
serialized `queue` barrier their callers already run on (saveIdentityCache ->
performSave directly); forceSave is a direct, non-blocking call (no
queue.sync, which is unsafe on the cooperative pool). No timer is left
scheduled, so nothing keeps the process alive. The original bug is still
fixed — saves now actually happen, unlike the never-firing Timer.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The app test job intermittently hung at process exit. The suite is
load-sensitive and historically prone to cooperative-pool/teardown
deadlocks; the security changes added background work to the test process
that pushed it over the edge. Make the unit-test BLEService/identity
manager quiescent and remove blocking sync:
- forceSave() no longer does queue.sync(.barrier). It is reachable from
deinit and from async tests on the swift-concurrency cooperative pool,
where a blocking barrier-sync can starve/deadlock the pool. It now
cancels the debounce timer and persists directly. (Removed the
now-unneeded queue-specific-key re-entrancy machinery.)
- SecureIdentityStateManager persists synchronously under tests instead of
scheduling a DispatchSourceTimer that lingers past process exit.
- Gate gossip-sync start (in addition to the maintenance timer) behind
real Bluetooth init, so the test BLEService runs no periodic
sign/broadcast/sync churn.
- Skip the panic Nostr reconnect under tests (connecting the shared relay
singleton starts network/reconnect work that never completes).
Production behavior is unchanged: real Bluetooth builds run all timers and
the debounced save as before; the debounce save now actually fires
(previously a Timer on a GCD queue that never ran).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Root cause of the CI app-test hang was a pre-existing bleQueue<->collectionsQueue
lock inversion driven by the periodic maintenance timer (performMaintenance ->
drainAllPendingWrites takes collectionsQueue while another path holds it and
sync-waits on bleQueue via readLinkState). The timer is created unconditionally
in init, so it also ran in the unit-test process (initializeBluetoothManagers:
false), where it only churns BLE writes/notifications/announces that don't exist.
Recent timing changes made the latent deadlock surface reliably.
- Only start the maintenance timer when real CoreBluetooth managers were
initialized (maintenanceTimerEnabled). Production behavior is unchanged; the
unit-test process no longer runs the timer and cannot hit the inversion.
Also fix BLEServiceCoreTests.duplicatePacket_isDeduped, which sent an unsigned
public packet that the new signature requirement (security fix#2) correctly
drops. The test now signs the packet and preseeds the sender's signing key
(production sendMessage signs public broadcasts), exercising the dedup path
(security fix#7) end to end. _test_handlePacket gains an optional
signingPublicKey to seed the registry.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The forceSave() rewrite used queue.sync(flags: .barrier), but forceSave
is also called from deinit. The debounce timer's barrier hop captured
self strongly, so when that block dropped the last reference the manager
deallocated *on* the identity queue — deinit -> forceSave -> queue.sync
then deadlocked synchronizing onto the queue it was already running on.
This hung the test process at exit (CI SIGKILL / exit 137).
- forceSave() now detects (via a queue-specific key) when it is already
executing on the queue and runs the save directly instead of sync-ing
onto itself.
- The timer's barrier hop now captures self weakly, so it can no longer
trigger a deallocation on the queue in the first place.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The public-message signature check fell back to signedSenderDisplayName,
which only searches the asynchronously-persisted identity cache. Because
the peer registry is updated synchronously on a verified announce, a
message arriving immediately after that announce could have a valid
signature and a verified registry entry yet still be dropped (cache not
caught up).
Verify the packet signature against the signing key already present in
the synchronously-updated peer registry first; fall back to the
persisted-identity lookup only for peers not yet in the registry. The
security property is unchanged: a spoofed senderID claiming a registry
peer still fails registry verification and the persisted fallback, and
is dropped.
Adds tests for the race (delivered via registry key before cache
persists) and the spoof case (invalid signature falls back and drops).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
A broad audit surfaced ten critical/high issues across the crypto,
transport, identity, and panic-wipe layers. This fixes all ten.
Critical:
- Nostr DMs were unauthenticated. The NIP-17 seal was signed with a
throwaway ephemeral key and the receiver never verified it, so anyone
who knows a recipient's npub could forge messages (and delivery/read
receipts) into an existing trusted conversation. The seal is now
signed with the sender's real identity key, and the receiver verifies
the seal signature and that seal.pubkey == rumor.pubkey.
NOTE: this is a breaking wire-protocol change (see PR).
- Public BLE messages trusted registry membership instead of the packet
signature. Since senderID is attacker-controlled, any verified peer
could be impersonated in public chat. A valid signature from the
claimed sender is now required before any registry identity is used.
- Unverified announces still persisted the announced identity, letting a
replayed noisePublicKey overwrite a victim's stored signing key and
nickname. persistIdentity is now gated on verification.
High:
- Noise decrypt trapped on a 16-19 byte ciphertext (negative prefix
length after nonce extraction) — a remote crash. Now validated.
- Identity-cache debounce save used Timer.scheduledTimer on a GCD queue
with no run loop, so it never fired; block/verify/favorite changes
only persisted on explicit forceSave. Replaced with a
DispatchSourceTimer on the queue; forceSave is now serialized.
- Identity-cache key load couldn't tell "missing" from a transient
keychain failure and would regenerate (deleting) the key, orphaning
the cache. Now uses getIdentityKeyWithResult and falls back to a
session-only ephemeral key without clobbering the persisted key/cache.
- BLE receive-dedup key lacked a payload digest, so post-handshake
flushes (queued msgs + delivery/read acks in the same ms) were dropped
as duplicates. Digest added, matching the ingress registry.
- Maintenance timer was created only in init and never recreated after a
panic stop/start, silently degrading the mesh until app restart. Now
recreated in startServices.
- Panic wipe left persisted location state (selected channel, teleport
set, bookmarks) and cached per-geohash Nostr private keys behind. Both
are now cleared.
- Panic spawned an orphan NostrRelayManager instead of reusing .shared,
splitting relay state from every other component. Now reuses .shared.
Tests updated to assert the fixed behavior (announce no longer persists
unverified identities; public messages require a signature; receive
dedup ID includes the payload digest).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix launch crash: recursive dispatch_once between NostrRelayManager and NetworkActivationService
NostrRelayManager.init() runs applyDefaultRelayPolicy(force: true), which
calls dependencies.activationAllowed() when the user has location
permission or a mutual favorite. That closure resolves
NetworkActivationService.shared, whose init captured
NostrRelayManager.shared — re-entering the still-running dispatch_once on
the same thread. libdispatch traps on recursive dispatch_once
(EXC_BREAKPOINT in _dispatch_once_wait), killing the app ~50ms after
launch, before the first frame.
Fresh installs were unaffected (no permission, no favorites, so the
policy path never touched NetworkActivationService during init), which is
why this passed local testing but crashed established TestFlight users on
every launch. Two independent TestFlight crash reports on 1.5.2 (1)
show the identical stack.
Break the cycle by resolving the relay controller lazily: store a
provider closure in init and dereference NostrRelayManager.shared on
first use (start()/reevaluate()), after both singletons have finished
initializing. The injectable test initializer keeps its signature.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Bump version to 1.5.3
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>
* Extend mesh range: relax RSSI gates, lift sparse TTL clamps, drain connection queue
Range improvements to the BLE mesh, all policy-level (no wire/protocol
changes):
- Drain the connection candidate queue from the maintenance tick.
Weak-RSSI discoveries are enqueued rather than connected, but the
queue was only drained on disconnect/failure/timeout events — an
isolated node surrounded only by weak (distant) peers queued them
all and never connected to anyone.
- Relax isolated RSSI floors from -90/-92 to -95/-100 and relax after
30s instead of 60s. When isolated, a fringe connection beats no
connection; CoreBluetooth rarely reports below -100 so prolonged
isolation now effectively accepts any decodable peer.
- Drop the global high-timeout RSSI escalation (-80 after 3 timeouts
in 60s). One flaky distant peer could blind the node to every other
edge-of-range peer; per-peripheral cooldown, the discovery ignore
window, and score bias already contain flaky links individually.
- Relay at full incoming TTL in thin chains (degree <= 2). Sparse
line topologies are exactly where every hop counts and where flood
cost is minimal; previously messages lost a hop to the clamp.
- Raise the fragment relay TTL cap from 5 to 7 in sparse graphs so
media reaches as far as text; dense graphs keep the 5-hop clamp to
contain full-fanout fragment floods.
- Extend peer reachability retention from 21s to 60s (verified) /
45s (unverified) so duty-cycled nodes (worst-case dense announce
interval 38s) don't forget peers between announces.
- Extend the directed store-and-forward spool window from 15s to 60s
so brief link gaps heal via the periodic flush.
957 tests pass.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Reconnect quickly after walk-away disconnects
Field test (walk away + return between two devices) showed reconnect
landing exactly 15.0s after the supervision-timeout disconnect: the
scheduler records a dropped established connection via
recordDisconnectError into the same map as connect timeouts, and
handleDiscovery hard-ignores rediscoveries for 15s.
Those are different situations. A connect attempt that timed out means
the peer likely isn't reachable, so backing off is right. A dropped
established connection usually means the peer walked out of range and
will return — track it separately and only ignore rediscoveries for 3s
(enough for CoreBluetooth to settle), so walking back into range
reconnects ~12s sooner.
Disconnect errors also no longer feed the weak-link cooldown or the
candidate-score timeout bias; those penalties now apply only to peers
that never answered a connect attempt.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Honor the disconnect settle window on the queue drain path
Codex review caught that the 3s settle window was only enforced in
handleDiscovery. A candidate can already be sitting in the queue when
its peripheral drops (weak-RSSI adverts are enqueued even while
connected, since the RSSI check precedes the existing-state check),
and didDisconnectPeripheral immediately drains the queue — so the
stale entry could reconnect right through the window, recreating the
reconnect/cancel thrash it exists to prevent.
nextCandidate now defers such candidates with retryAfter for the
window's remainder, mirroring the weak-link cooldown pattern.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Relay on one link per bound peer instead of both dual-role links
Three-device field test (star topology) showed every relayed fragment
arriving twice at the leaf: dual-role pairs hold two live links (we as
central writing to their peripheral, they as central subscribed to
ours) and broadcast/relay fanout sent the same packet down both — 2x
airtime on exactly the pairs that talk most, with the receiver just
discarding the duplicate.
The fanout selector now collapses link selection to one link per bound
peer, preferring the peripheral (write) side since it has per-link
flow control via canSendWriteWithoutResponse, while notifications
share the peripheral manager's update queue across all centrals.
Links with no bound peer yet (pre-announce) pass through untouched.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Only notify "bitchatters nearby" on the empty-to-populated transition
Devices sitting idle and connected kept re-firing the notification.
Two bugs in handleNetworkAvailability:
- Peers first sighted during the 5-minute cooldown were never added to
recentlySeenPeers (the formUnion only ran when a notification
fired), so they stayed "new" forever and re-triggered on the next
routine peer-list event once the cooldown lapsed.
- There was no went-from-zero gate at all: any unseen peer notified,
even while already meshed with others who are visible in the app.
Every sighted peer is now recorded regardless of cooldown, and the
notification only fires when the mesh transitions from confirmed-empty
to populated with genuinely new peers. meshWasEmpty resets only via
the existing confirmed-empty paths (30s empty confirmation, 10-minute
quiet reset), so brief link flaps stay silent. The cooldown becomes
injectable so tests can prove the transition gate independently.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Bump version to 1.5.2; Xcode 26.5 project settings update
Marketing version 1.5.1 -> 1.5.2 (pbxproj + Release.xcconfig).
Project settings refresh from Xcode 26.5: upgrade-check stamp, drop
redundant DEVELOPMENT_TEAM self-references, scheme version stamps.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Disable string catalog symbol generation
The Xcode 26.5 settings refresh enabled STRING_CATALOG_GENERATE_SYMBOLS
(the new default), which fails on the literal "%@" key in
Localizable.xcstrings — a pure format placeholder can't become a Swift
identifier. Nothing in the codebase references generated catalog
symbols, so turn the feature off rather than renaming keys around it.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Guard _PreviewHelpers references for archive builds
Archiving for TestFlight failed: _PreviewHelpers is a development
asset, so its sources (PreviewKeychainManager, BitchatMessage.preview)
are excluded from Release/archive builds, and two call sites
referenced them unconditionally:
- TextMessageView's #Preview block — now wrapped in #if DEBUG
- FavoritesPersistenceService.makeDefaultKeychain's test branch — the
in-memory-keychain-under-test path is now #if DEBUG; tests always
run Debug so behavior is unchanged, and Release always gets the real
KeychainManager
Verified with an iOS Release arm64 build (the archive configuration).
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>
NoiseCoverageTests' session-callback test failed on the first CI run
that actually executed it (every run since it landed had hung and been
killed before completion): onSessionEstablished fires via
DispatchQueue.global().async, and the test waited only 0.5s — fine on
a dev machine, too tight on a loaded CI runner saturated by parallel
test workers.
Raise every positive-wait timeout from 0.5s to 5s (matching
TestConstants.defaultTimeout) across the suites that poll for async
callbacks. waitUntil returns as soon as the condition holds, so
passing runs are unaffected; only genuine failures wait longer. The
two negative waits in BLEServiceCoreTests ("expect nothing arrives")
deliberately keep their short windows.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Exclude perf baselines from parallel CI via --skip; sample hung tests
Every app-suite CI run since the perf baselines landed (#1335) has
timed out at the 15-minute job limit — main has been red for five
consecutive runs. The job logs show the PerformanceBaselineTests
fixtures dispatched into the parallel phase despite the
BITCHAT_SKIP_PERF_BASELINES env guard from #1336, followed by ~11
minutes of silence until the timeout kills swiftpm-testing. The suite
passes locally in seconds with identical flags, so the hang is
specific to the CI toolchain/runners — consistent with the known
XCTest-measure-under-parallel-workers hang the serial step was
created to avoid.
Two changes:
- Exclude the baselines from the parallel phase with --skip at the
SPM level, which removes them from the worker processes entirely
instead of relying on the env guard reaching setUpWithError. They
still run (and gate) in the dedicated serial step.
- Wrap the parallel run in a 10-minute watchdog that samples any
still-running test processes before killing them, so if anything
else ever hangs, the run fails fast with thread stacks in the log
instead of a silent 15-minute timeout.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Arm the test-hang watchdog only for the test execution phase
Codex review: swift test builds before running, so the watchdog timer
included dependency resolution and compilation — a cold-cache coverage
build on a slow runner could be killed before tests ever started.
Build the tests in their own step (bounded by the 15-minute job
timeout like any build) and run the watchdog around swift test
--skip-build, tightened to 5 minutes now that it times only test
execution.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Hammer transport thread-safety tests from the dispatch pool, not the cooperative pool
The watchdog added in this PR captured the actual CI hang twice, with
identical stacks both times: NostrTransportTests' 100-task groups park
every Swift Concurrency cooperative thread in a blocking queue.sync
(the pool has one thread per core — 3 on CI runners, 10+ on dev
machines, which is why this never reproduced locally). Blocking the
entire cooperative pool violates the forward-progress contract, and
the runners' dispatch wedges under the resulting asyncAndWait flood —
taking concurrently running tests down with it (the panic-reset test
deadlocked in a serviceQueue barrier that never got scheduled).
Run the same 100 concurrent hammer iterations via
DispatchQueue.concurrentPerform from a single global-queue hop instead:
identical thread-safety coverage, executed on dispatch worker threads
where blocking is legal, zero cooperative threads parked.
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>
* Centralize UI theme colors into semantic ThemePalette tokens
Introduce AppTheme/ThemePalette (Utils/Theme.swift) with an environment
key and @ThemedPalette property wrapper, persisted via @AppStorage.
Views now resolve background/primary/secondary/accentBlue/alertRed/
divider tokens from the environment instead of computing colors inline,
removing the backgroundColor/textColor/secondaryTextColor prop-drilling
through the header, composer, and people-sheet hierarchy.
Matrix theme output is pixel-identical; this is groundwork for a
user-selectable theme switcher.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Add liquid glass theme with in-app appearance switcher
Add a .liquidGlass AppTheme alongside the matrix terminal theme,
selectable from a one-line APPEARANCE row in the app info sheet
(persisted via @AppStorage, applies live).
Liquid glass renders system fonts and colors over a subtle gradient
backdrop, with the header and composer floating as Liquid Glass panels
(real .glassEffect() on iOS/macOS 26, compiler-gated with an
ultraThinMaterial fallback for older SDKs). The message list scrolls
underneath the chrome via safe-area insets, and all sheets share the
same backdrop and surface language. The matrix theme is unchanged.
Details:
- Theme is threaded through ChatMessageFormatter so message
AttributedStrings switch font design per theme; the per-message
format cache gains a variant key so themes never serve each other's
cached strings
- New palette tokens: accent (interactive tint) and locationAccent
(geohash green), replacing scattered hardcoded greens/blues in the
voice note, waveform, verification, and people-sheet views
- Header controls get full-height tap targets and the people count
becomes a real Button (previously a tap gesture on the cluster)
- CommandSuggestionsView renders nothing when empty instead of a
zero-height view that pushed the composer input off-center
- New appearance strings localized for all 29 catalog languages
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>
The intermittent CI hang was caught by the new job timeout: the run
froze on the last remaining parallel test slot, an XCTest measure
benchmark (testNostrInboundEventHandling_freshEvents), after 4 hangs
in 5 runs - while the same suite completes in seconds locally and the
test itself is bounded. Independent of the micro-cause, benchmarks
do not belong inside the parallel suite: measuring while test processes
contend for cores is where our 2x CI variance came from. The parallel
run now skips benchmarks (BITCHAT_SKIP_PERF_BASELINES=1) and a
dedicated serial step runs them on an otherwise idle runner with a
6-minute step timeout, feeding the floor gate as before.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Two app-test jobs hung intermittently (40+ minutes against a normal
~4-5), holding macOS runners against GitHub's 360-minute default and
starving the queue - subsequent runs sat pending, which read as "CI now
takes 10+ minutes". Jobs now time out at 15 minutes (3x the normal
duration) so a hang fails loudly instead of silently consuming the
runner pool. The intermittent hang itself is under investigation
separately.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The gate tripped on a uniformly slow runner: every benchmark ran at
~2/3 of the previous CI run and nostrInbound.duplicate fell to 87% of
its floor. Root cause: floors were derived from local numbers, but CI
slowdown is benchmark-dependent - sub-millisecond passes amplify runner
overhead (the duplicate path runs at ~20% of local speed on CI while
most benchmarks run at 40-60%). Floors are now ~50% of the slowest
observed CI run, recorded alongside the local references. Every floor
remains 10-200x above known regression values (the pre-optimization
duplicate path measured 2.2k/sec against the 250k floor), so order-of-
magnitude regressions still fail loudly. Verified against the slow
run's numbers: all 11 pass.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
During a panic reset, the new NoiseEncryptionService was assigned
before the identity barrier ran, so a previously queued send block
could observe the new crypto service alongside the old peer ID -
signing with the new identity while carrying the old sender. The
service teardown, replacement, callback configuration, and derived
identity swap now run inside one messageQueue barrier
(refreshPeerIdentity executes inline via its re-entrancy check), so
queued sends see either the complete old identity or the complete new
one, never a mix.
Found by Codex review on #1336.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
EOSE callbacks parked while Tor is bootstrapping now get a fallback
unblock at the standard 10s EOSE timeout (via the injected scheduler,
generation-guarded, single-fire) instead of waiting up to ~225s for
Tor-readiness retry exhaustion. The identity swap in
refreshPeerIdentity runs inside a messageQueue barrier with re-entrancy
guard, so a panic reset can no longer race in-flight packet builds
(deadlock analysis documented; both call paths verified off-queue).
Relay send-queue overflow drops now log a sampled warning.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The publish chain was healthy: the store mutates the shared
BitchatMessage and republishes, the .statusChanged fan-out reaches both
mirrored conversations, and PrivateInboxModel fires objectWillChange for
the selected DM under either key. The break was at the row view:
TextMessageView/MediaMessageView stored the reference-typed message and
read deliveryStatus in body, so SwiftUI's structural diff compared the
field by identity - same instance, mutated in place, row body skipped.
The blue tick waited for an unrelated invalidation (proven empirically
with a hosting-view probe).
Rows now snapshot deliveryStatus as a value at init; every republish
rebuilds row values with a fresh enum, the diff sees the change, and
the row re-renders immediately. Also fixes in-place send-progress
updates in media rows. Regression tests cover both mirrored selection
keyings at the feature-model level and the snapshot mechanic itself.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The enqueue/drain/still-full logs fire per fragment during media
transfers (~150 lines for one 35KB image in field captures). They now
sample first + every 25th with a running event count, the sent/pending
lines merge into one, and the redundant peripheral-ready line is gone -
same treatment the relay event logs received. The drop-after-exhaustion
error stays unsampled.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Production builds previously still emitted info/warning/error entries
via os_log (content private-redacted, but entries, categories, and
timing metadata were visible, and message strings were constructed).
For a privacy-first app the right posture is silence: every SecureLogger
wrapper and both cores are now gated behind #if DEBUG, so release
builds construct no log strings and emit nothing. Debug builds are
unchanged (public formatting, level threshold via BITCHAT_LOG_LEVEL).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
ConversationStore.auditInvariants() verifies the per-conversation and
store-level message-ID indexes, caps, timestamp ordering, unread-set
membership, and selection validity - wired to the existing read-receipt
cleanup cadence, loud (.error) on violation, sampled heartbeat when
healthy (~2.8ms per audit at 5k messages, benchmarked and floored).
Router drops log both outcomes (marked failed / skipped by no-downgrade
guard); relay cap evictions, age sweeps, and jittered reconnect delays
log their counts; mirrored republishes get a sampled proof line. 11 new
invariant tests corrupt store state through DEBUG-only hooks since the
single-writer lockdown makes those states unreachable via intents.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Package.swift's .process("Noise") resource claim silently excluded all
of bitchatTests/Noise/ from compilation since Oct 2025 - including a
complete official-vector runner (cacophony + snow XX transcripts,
transport messages, handshake hash, byte-identical to upstream).
Narrowing the resource to the JSON file and loading via Bundle.module
brings 51 Noise tests back to life, with a guard asserting each
vector's protocol name matches the app's.
CI gains a performance floor gate: perf-floors.json carries deliberately
generous floors (~25% of measured throughput) that catch algorithmic
regressions without flaking on runner variance; PERF lines reach the
gate via an O_APPEND side-channel file since swift test --parallel
swallows passing tests' stdout.
Tests are now hermetic: FavoritesPersistenceService uses an in-memory
keychain under test (fixes the securityd hang that blocked pipeline
benchmarks locally) and read-receipt persistence uses a wiped scratch
UserDefaults suite instead of .standard.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Transport callers no longer reach the raw NoiseEncryptionService:
getNoiseService() is deleted in favor of narrow purpose-named Transport
methods (session public key, identity fingerprint, static/signing keys,
sign/verify, callback installation). VerificationService now reaches
crypto through the transport, so it can no longer pin a stale service
across a panic reset. myPeerID/myNickname become private(set); the
existing setNickname mutator is the sole nickname path.
ConversationStore is now the sole owner of private-chat selection:
PrivateChatManager.selectedPeer is a published read-only mirror, and
startChat/endChat mutate through the store intent. The bridge method
and its five call sites are deleted, removing a latent bug where a
stale manager selection pushed back into the store could resurrect a
just-removed conversation.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
MessageRouter outbox drops (attempt cap, TTL expiry in flush and
cleanup, per-peer overflow eviction) now invoke onMessageDropped, wired
to mark the message .failed in the ConversationStore - guarded so a
late failure never downgrades an already delivered/read status.
NostrRelayManager pending subscriptions gain a per-relay cap (64,
oldest-by-sequence eviction; durable intent still replays from
subscriptionRequestState) and a 10-minute age sweep on the existing
connect path. Reconnect backoff gets injectable +/-20% jitter so
recovering relays don't thundering-herd.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
When a private message is mirrored into stable-key and ephemeral-peer
conversations as one shared BitchatMessage instance, the first
conversation's status apply mutated the shared object and the second
skipped as already-equal - state stayed correct but the mirrored
conversation never republished, so a view observing it rendered stale
delivery/read status. The ID-only fan-out now republishes and emits
.statusChanged for every skipped conversation whose message holds the
applied status; genuinely-rejected distinct copies (downgrades) stay
untouched, and duplicate acks still publish nothing.
Found by Codex review on #1334.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Feature models observe per-conversation objects directly: PublicChatModel
forwards the active Conversation's objectWillChange, PrivateInboxModel
republishes only for the selected peer's conversation - background
appends no longer invalidate foreground views. LegacyConversationStore,
the coalescing bridge, and IdentityResolver are deleted (resolver
canonicalization proved display-invisible: nothing enumerates direct
conversations, lookups are by exact peer ID, and raw keying is strictly
more robust - documented as a design deviation). Selection state moves
into the store. ChatViewModel.messages/privateChats survive as derived
read views for coordinators that genuinely need them; hot paths use a
new store-direct privateMessages(for:) witness.
Final numbers vs pre-migration baselines:
pipeline.privateIngest 9.7k -> 24.0k msg/s (2.5x)
pipeline.publicIngest 6.8k -> 13.7k msg/s (2.0x)
delivery updates 38k -> 117-133k/s
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
ConversationStore maintains an exact messageID -> Set<ConversationID>
map at every mutation point (append/upsert/remove/migrate/trim/clear),
so delivery updates are ID-only lookups that fan out to mirrored
ephemeral/stable copies. ChatDeliveryCoordinator shrinks 327 -> 119
lines: the positional location index, its growth-detection/rebuild
machinery, and the duplicate no-downgrade check are deleted - the rule
now lives in exactly one place. The middle-insertion regression tests
are rewritten against the store since stale positional locations are
structurally impossible now.
delivery updates: 38k -> 262k/s (~6.9x); ingest pipelines unchanged.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Mesh and geohash timelines are now store conversations. All public
mutation sites flow through store intents; PublicMessagePipeline keeps
its 80ms UI batching but commits batches via store appends with each
buffered entry carrying its destination conversation (a mid-batch
channel switch now flushes instead of dropping the buffer).
ChatViewModel.messages becomes a cached get-only view of the active
conversation, invalidated through the change subject. The mesh
late-insert threshold is consciously removed: it only ever ordered the
non-rendered messages copy, so strict timestamp insertion makes the
working set agree with rendered order. PublicTimelineStore and the
per-message full-array legacy sync are deleted; the coalescing bridge
mirrors public conversations for the remaining legacy readers.
pipeline.publicIngest: 6.6k -> 9.5k msg/s (+45%); private steady;
store.append 237k/s.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
All private-message mutations now flow through store intents:
coordinators, PrivateChatManager (its @Published dicts deleted - now
read-only views over the store), outbound sends, delivery status, and
chat migration. The O(1) store dedup replaces the full-scan duplicate
check; insertion order is maintained by the store so sanitizeChat's
re-sort is a documented no-op. Both bootstrapper Combine bridges and
the Task.yield store synchronization are deleted.
ChatViewModel.privateChats/unreadPrivateMessages become get-only derived
views (measured: naive rebuild equals a change-invalidated cache within
noise, so the simpler form stays). Feature models still read the legacy
store, fed by a coalescing LegacyConversationStoreBridge (one mirror
per burst, marked for step-5 deletion).
pipeline.privateIngest: 9.6k -> 14.7k msg/s (+53%).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Per-conversation ObservableObjects with O(1) dedup via an incrementally
maintained message-ID index, binary-search timestamp insertion, folded
cap policies, a no-downgrade delivery rule, and a typed change subject.
All mutation flows through store intents (conversation mutators are
fileprivate). The previous store is renamed LegacyConversationStore
pending deletion in step 5. 16 behavioral tests including per-
conversation publish isolation; store.append benchmarks at ~144k
messages/sec.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
docs/CONVERSATION-STORE-DESIGN.md records the approved design: a
single-writer ConversationStore of per-conversation ObservableObjects
(per-conversation publishing, incremental ID index, folded caps, typed
change subject) replacing today's four-store/three-bridge topology,
with a five-step migration plan and explicit deletions/non-goals.
New pipeline benchmarks measure the CURRENT architecture end-to-end so
every migration step is judged against real before-numbers:
pipeline.privateIngest ~9.7k msg/s, pipeline.publicIngest ~6.8k msg/s
(200-message passes, stable within 1.5%).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Make location notes robust: durable relay subscriptions, failure decay, auto-recovery
Location notes (and geohash chat / DMs) intermittently stopped showing
events because the Nostr relay layer lost subscriptions and blacklisted
relays:
- Replay active subscriptions on every relay (re)connect. Relays drop
REQs with the socket; previously a drop silently killed the
subscription on that relay for the rest of the session. Durable
subscription intent now also survives disconnect()/resetAllConnections
(background -> foreground).
- Keep failed REQ sends queued instead of dropping them.
- Raise the EOSE fallback from a fixed 2s Timer to a 10s injected
schedule (Tor needs more than 2s), and settle EOSE trackers when a
relay disconnects before answering so initial load doesn't stall.
- Decay "permanently failed" relay markings after a 10-minute cooldown;
previously ~9 minutes of outage (or one DNS hiccup) excluded a relay
until app restart, with nothing resetting it on macOS.
- Make geo relay selection deterministic (distance, then host) so
publishers and subscribers with the same directory agree on relays.
- Post .geoRelayDirectoryDidRefresh after a directory fetch and let
LocationNotesManager auto-resubscribe out of the "no relays" state
instead of requiring a manual retry.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Guard subscription activation on connection identity
A REQ send completion from a dead socket could land after
handleDisconnection cleared the relay's subscriptions and re-mark the
subscription active, making the next connection skip the durable replay
and leave that relay silent. Only mark a subscription active if the
completing socket is still the relay's live connection.
Regression test defers send completions in the mock so the stale
completion deterministically interleaves between disconnect and
reconnect.
Addresses Codex review on #1333.
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>
The coordinator scheduled its delayed owner-level read pass via
DispatchQueue.main.asyncAfter, which a busy CI runner's main queue can
delay past any reasonable polling deadline. Scheduling is now an
injected context member (scheduleOnMainAfter); the ChatViewModel witness
keeps the exact asyncAfter behavior while the test mock runs the work
synchronously, eliminating the wall-clock poll entirely.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
swift test runs with --enable-code-coverage and each matrix job prints
an llvm-cov per-file + total summary (informational only - no
thresholds, so coverage can never be the reason a build goes red).
Local baseline at introduction: 69.7% lines.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
NotificationService.shared and FavoritesPersistenceService.shared
accesses across nine coordinators/components consolidate into
ChatViewModel witnesses behind intent-named context members
(notifyPrivateMessage, notifyMention, favoriteRelationship(forNoiseKey:),
allFavoriteRelationships, postLocalNotification, ...). Singleton reach
from coordinators is now zero; nine new tests cover previously
untestable notification/favorites flows.
Also root-causes the long-flaky gift-wrap dedup test: parallel tests
share LocationChannelManager.shared, so channel-switch tests trigger
clearProcessedNostrEvents() on every live ChatViewModel, wiping the
dedup record mid-test. The invariant (forged-signature copies never
poison dedup) now lives as a deterministic NostrInboundPipeline
mock-context test; two Schnorr concurrency probes added along the way
stay as regression guards for the P256K shared-context assumptions.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The 1,109-line coordinator becomes a 187-line facade wiring three
components, each with its own narrow context protocol:
GeohashSubscriptionManager (384 lines - subscription IDs + relay
lifecycle, the only NostrRelayManager toucher), NostrInboundPipeline
(490 lines - the hot event path, dedup-before-verify ordering preserved
verbatim), and GeoPresenceTracker (192 lines - teleport detection,
sampling LRU, notification cooldowns, now directly tested).
Perf baselines confirm the hot path is unchanged: fresh events
2,131 -> 2,138/sec, duplicates ~1.41M/sec.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
ChatPeerListCoordinator, ChatComposerCoordinator, ChatOutgoingCoordinator,
and GeoChannelCoordinator complete the migration; every coordinator now
depends on a narrow @MainActor context protocol. GeoChannelCoordinator's
three injected closures collapse into a weak context. New intent op
recordPublicActivity(forChannelKey:) keeps lastPublicActivityAt
single-writer. 15 new mock-context tests; flaky-poll deadline in the
gift-wrap dedup test raised for parallel load.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
ChatTransportEventCoordinator, ChatPeerIdentityCoordinator,
ChatMediaTransferCoordinator, ChatVerificationCoordinator, and
ChatLifecycleCoordinator drop their unowned ChatViewModel back-refs for
narrow @MainActor contexts (20-36 members each), reusing shared
witnesses across protocols. The two remaining raw writers of
sentReadReceipts now route through owner intent ops
(unmarkReadReceiptsSent, syncReadReceiptsForSentMessages), closing the
gaps noted in the previous commit. NoiseEncryptionService stays fully
out of the verification coordinator via installNoiseSessionCallbacks.
26 new mock-context tests.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
nostrKeyMapping, sentGeoDeliveryAcks/sentReadReceipts dedupe,
isBatchingPublic, geo subscription lifecycle, and private-chat selection
hand-off now mutate through single intent operations on ChatViewModel,
with backing storage locked down via private(set) so the single-writer
property is compiler-enforced. Context protocols downgrade to read-only
access where reads remain. 8 new contract tests.
Known remaining writers outside the protocols: sentReadReceipts is
passed inout to PrivateChatManager.syncReadReceiptsForSentMessages and
un-marked by ChatTransportEventCoordinator on disconnect.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
New PerformanceBaselineTests measure the hot paths (Nostr inbound, BLE
packet pipeline, GCS filters, delivery index, message formatting) with
deterministic fixtures and logged PERF metrics - baselines, not
assertions, so they cannot flake CI.
The suite immediately exposed that every inbound handler ran Schnorr
verification before the dedup lookup, so duplicate events - which
dominate real multi-relay traffic - each paid ~0.5ms of main-actor
crypto for nothing. All five handlers now do cheap rejects (kind, dedup
lookup) first and only record an event as processed AFTER its signature
verifies, so a forged-signature copy can never poison the dedup set and
suppress the genuine event. Gift-wrap verification also moves entirely
off the main actor with an atomic main-actor check-and-record.
Measured: duplicate-event handling 2.2k -> 1.39M events/sec (~640x);
fresh events unchanged (crypto-bound).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
SecureLogger's public wrappers evaluated their message autoclosure before
the level check inside log(), so every filtered debug message across the
codebase still paid for string interpolation - hundreds of call sites on
the per-packet/per-event hot paths. The wrappers now guard the level
first, and debug() compiles out of release builds entirely. Regression
tests verify filtered messages are never constructed.
The two heaviest per-event debug logs (NostrRelayManager inbound events,
ChatNostrCoordinator geo events) are now sampled every 100th with a
running count, so debug-enabled dev builds stop emitting hundreds of
lines per minute in busy geohashes.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The incremental index refresh assumed growth meant appended messages,
but PublicMessagePipeline inserts out-of-order arrivals by timestamp:
the count grows while the tail ID stays put, so the inserted message
never entered the index and later delivery updates for it silently
no-op'd (and, with retain-until-ack routing, left it queued for
resend). Detect non-append growth by checking the previously indexed
tail kept its position, and rebuild when it hasn't. Same check on the
per-peer private chat arrays, which re-sort by timestamp.
Found by Codex review on #1331.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
BLEService's per-packet-type orchestration moves into owned, tested
components (BLEAnnounceHandler, BLEPublicMessageHandler,
BLENoisePacketHandler, BLEFileTransferHandler, BLEFragmentHandler),
each taking an environment struct of closures so every queue hop stays
in BLEService and the handlers are synchronously testable. Behavior is
preserved verbatim, including Noise session recovery on decrypt failure
and single-block UI event ordering. handleLeave/handleRequestSync stay
in place as already-thin delegations. BLEService drops to 3393 lines.
Four coordinators (delivery, private conversation, Nostr, public
conversation) drop their unowned/weak ChatViewModel back-references for
narrow @MainActor context protocols, with ChatViewModel conformances as
single shared witnesses for overlapping members. Their true coupling is
now an explicit, reviewable surface, and each gains a mock-context test
suite covering flows previously testable only through the full view
model. Delivery/read acks now also clear the router's retained-send
outbox via the delivery context.
New LargeTopologyTests exercise production-shaped meshes with the
in-memory harness: an 8-peer relay chain with per-hop TTL decay, a
14-peer cyclic mesh with exactly-once delivery, partition/heal, and
topology churn.
App-layer runtime/model files updated alongside.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
NostrRelayManager no longer strands work when Tor is slow to bootstrap:
failed readiness waits retry (bounded by nostrTorReadyMaxWaitAttempts)
instead of dropping queued relay connections, parked EOSE callbacks fire
after exhaustion so callers never hang, and sends made before Tor is
ready are queued locally (capped) instead of being dropped on a failed
wait - still strictly fail-closed.
MessageRouter now prefers a connected transport over a merely
window-reachable one, and sends made on a weak reachability signal are
retained in the outbox until a delivery/read ack confirms receipt
(receivers dedup by message ID), with resends bounded by attempt count.
GCS sync filters from the wire are bounds-checked (p in 1...32, m > 1)
at both the packet decode and filter decode layers; oversized Golomb
parameters previously decoded to garbage via silent shift overflow.
BLELinkStateStore is now explicitly pinned to bleQueue: debug builds
trap any access from another queue, enforcing the ownership discipline
the surrounding code already relied on by convention.
CI gains an iOS simulator build job (arm64 only; the vendored Arti
xcframework has no x86_64 simulator slice) so iOS-conditional code
paths are compile-checked - SPM tests only cover the macOS slice.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Vendored arti.xcframework rebuilt from source (Rust 1.96.0, normalized
archive metadata for reproducible hashes). New ARTI-BINARY-PROVENANCE.md
records toolchain, rebuild steps, and a SHA256 manifest for every file
in the xcframework. A new CI workflow turns that policy into a gate:
PRs must keep the binary matching the manifest, and binary changes must
ship with source/lockfile/build-script evidence.
Also raises TorManager.awaitReady's default timeout from 25s to 75s to
match the bootstrap monitor deadline - a shorter wait reported "not
ready" while Arti was still legitimately bootstrapping, silently
stranding queued relay work.
Privacy policy, Tor integration doc, and privacy assessment updated to
match the current implementation.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Refactor BLE transport event handling
* Make image output paths unique
* Keep queued Nostr read receipts alive
* Refine BLE ingress fanout
* Rediscover BLE service after invalidation
* Extract BLE notification retry buffer
* Extract BLE inbound write buffer
* Extract BLE fragment assembly buffer
* Tidy secure log handling from device run
* Extract BLE outbound fragment scheduler
* Harden app CI media tests
* Redact BLE message content from logs
* Extract BLE Noise session queues
* Fix BLE read receipt UI updates
* Allow self-authored RSR ingress replies
* Harden read receipt queue test timing
* Extract BLE outbound policy and incoming file storage
* Avoid duplicate BLE link snapshots during send
* Canonicalize Nostr relay URLs
* Extract BLE link state store
* Extract BLE connection scheduler
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
* Refactor BLE transport event handling
* Make image output paths unique
* Keep queued Nostr read receipts alive
* Refine BLE ingress fanout
* Rediscover BLE service after invalidation
* Extract BLE notification retry buffer
* Extract BLE inbound write buffer
* Extract BLE fragment assembly buffer
* Tidy secure log handling from device run
* Extract BLE outbound fragment scheduler
* Harden app CI media tests
* Redact BLE message content from logs
* Extract BLE Noise session queues
* Fix BLE read receipt UI updates
* Allow self-authored RSR ingress replies
* Harden read receipt queue test timing
* Extract BLE outbound policy and incoming file storage
* Avoid duplicate BLE link snapshots during send
* Canonicalize Nostr relay URLs
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
* Refactor BLE transport event handling
* Make image output paths unique
* Keep queued Nostr read receipts alive
* Refine BLE ingress fanout
* Rediscover BLE service after invalidation
* Extract BLE notification retry buffer
* Extract BLE inbound write buffer
* Extract BLE fragment assembly buffer
* Tidy secure log handling from device run
* Allow self-authored RSR ingress replies
* Harden read receipt queue test timing
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
* Run GeoRelay fetch pipeline off main actor
* Capture GeoRelay session before detached fetch
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
