* Add 26 code-referenced keys to the catalog + a test that closes the gap
LocalizationCoverageTests validated the catalog but never the code: a
String(localized:) whose key is missing from every catalog compiles
fine and silently ships its English defaultValue to all 29 non-source
locales. That blind spot let 26 keys go untranslated while CI stayed
green: the entire notices/board composer (10), the private-media
encryption warnings and delivery-failure reasons (9), both
courier-header strings, two delivery states, two media failure
reasons, and the [? people] channel row.
- All 26 keys added with full 30-locale coverage.
- New everyCodeReferencedKeyExistsInACatalog scans the source for
literal String(localized:) keys and fails on any key absent from
both catalogs. (The audit's original count of 17 was itself an
undercount — its scan missed multi-line String( localized: calls;
the test's regex does not.)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Localize CommandProcessor: all 48 command strings, 30 locales
CommandProcessor had zero String(localized:) calls — every command
error, usage hint, and the entire /help reference was hardcoded
English. The autocomplete panel (CommandInfo) is fully localized, so a
non-English speaker got localized suggestions while typing and English
the moment anything went wrong or they asked for help.
- 47 literal sites converted to String(localized:)/String(format:)
with positional specifiers where languages reorder (%1$@, %2$lld).
- /trace's "hop"/"hops" pluralization split into path_one/path_many;
the "you" chain label localized too.
- helpText and groupUsage become computed so they resolve per-locale.
- 49 command.* keys added with full 30-locale coverage (command
syntax stays verbatim; only prose translates).
- Copy fix from the audit: "blocked X. you will no longer receive
messages from them" → "…no longer see their messages" (blocking
filters at display time; packets still arrive and relay).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Localize the last hardcoded UI strings; wire up two dead translations
The stragglers from the unlocalized-strings audit:
- Nearby push notification: "bitchatters nearby!" title and the
hand-rolled English pluralization ("1 person around" / "N people
around") now localize via body_one/body_many.
- Voice recording errors (mic permission, start/too-short/save
failures) and the "Recording Error" alert title — also brought into
the lowercase house voice.
- The recording HUD's Cancel label now uses common.cancel.
- "No image selected" in both image pickers.
- The DM screenshot echo "you took a screenshot" (the wire-format
sibling stays English for Android compat).
- "Voice/Images are only available in mesh chats." had fully
translated catalog entries in all 30 locales that were never looked
up — the call sites passed the raw string instead of resolving the
key. Wired up via String(localized:).
10 new keys x 30 locales.
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 26 code-referenced keys to the catalog + a test that closes the gap
LocalizationCoverageTests validated the catalog but never the code: a
String(localized:) whose key is missing from every catalog compiles
fine and silently ships its English defaultValue to all 29 non-source
locales. That blind spot let 26 keys go untranslated while CI stayed
green: the entire notices/board composer (10), the private-media
encryption warnings and delivery-failure reasons (9), both
courier-header strings, two delivery states, two media failure
reasons, and the [? people] channel row.
- All 26 keys added with full 30-locale coverage.
- New everyCodeReferencedKeyExistsInACatalog scans the source for
literal String(localized:) keys and fails on any key absent from
both catalogs. (The audit's original count of 17 was itself an
undercount — its scan missed multi-line String( localized: calls;
the test's regex does not.)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Localize CommandProcessor: all 48 command strings, 30 locales
CommandProcessor had zero String(localized:) calls — every command
error, usage hint, and the entire /help reference was hardcoded
English. The autocomplete panel (CommandInfo) is fully localized, so a
non-English speaker got localized suggestions while typing and English
the moment anything went wrong or they asked for help.
- 47 literal sites converted to String(localized:)/String(format:)
with positional specifiers where languages reorder (%1$@, %2$lld).
- /trace's "hop"/"hops" pluralization split into path_one/path_many;
the "you" chain label localized too.
- helpText and groupUsage become computed so they resolve per-locale.
- 49 command.* keys added with full 30-locale coverage (command
syntax stays verbatim; only prose translates).
- Copy fix from the audit: "blocked X. you will no longer receive
messages from them" → "…no longer see their messages" (blocking
filters at display time; packets still arrive and relay).
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>
LocalizationCoverageTests validated the catalog but never the code: a
String(localized:) whose key is missing from every catalog compiles
fine and silently ships its English defaultValue to all 29 non-source
locales. That blind spot let 26 keys go untranslated while CI stayed
green: the entire notices/board composer (10), the private-media
encryption warnings and delivery-failure reasons (9), both
courier-header strings, two delivery states, two media failure
reasons, and the [? people] channel row.
- All 26 keys added with full 30-locale coverage.
- New everyCodeReferencedKeyExistsInACatalog scans the source for
literal String(localized:) keys and fails on any key absent from
both catalogs. (The audit's original count of 17 was itself an
undercount — its scan missed multi-line String( localized: calls;
the test's regex does not.)
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Deflake AppArchitectureTests: raise the local waitUntil to settleTimeout
The file-local waitUntil defaulted to 3s — below the documented
minimumSettleTimeout floor — and the recent-chats geo-dedup wait
missed it on a loaded runner right after merge (the Combine hop
through receive(on: .main) was starved). Every caller waits for a
condition to become true, so green runs return immediately and never
pay the 30s deadline.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix the real geo-dedup race: re-assert tracker state on each poll
The 30s deadline didn't help — the recent-chats geo-dedup wait wasn't
slow, it was permanently broken under parallel swift-test load: the
view model's own channel binding delivers its initial .mesh selection
asynchronously and resets the active participant geohash when it lands
(GeohashSubscriptionManager → setActiveParticipantGeohash(nil)),
wiping the test's setup so the dedup could never happen. Reproduced
locally with `swift test --parallel`; standalone runs never hit it.
The wait now re-asserts setActiveGeohash + recordParticipant on every
poll (both idempotent) — the same self-healing pattern the geohash
timeline test already uses for singleton interference. Interference
heals on the next poll; a genuine dedup failure still times out.
6× full parallel runs green.
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 a persistent connectivity banner and stop the radar lying
Two "the app looks fine while it isn't" problems from the UX audit:
- Bluetooth-off had exactly one signal: a dismissible alert. Once
dismissed, the app looked completely normal — empty timeline, radar
sweeping "searching for people" — while the radio was off. The radar
animation now requires a radio that can actually scan, and a
persistent red banner under the header carries the state instead:
off (tap → settings), denied (tap → settings), or unsupported
(mesh unavailable; location channels still work).
- A Tor bootstrap stall was only ever announced inside geohash
timelines (addGeohashOnlySystemMessage), so someone sitting in #mesh
or a DM whose messages route over Nostr got silence and hanging
"sent" states. The stall now also drives a chrome-level torBlocked
flag and the same banner: "tor can't connect — internet features are
paused. mesh still works."
The banner renders nothing when everything is healthy, and .unknown/
.resetting radio states deliberately stay quiet — a false "bluetooth is
off" flash at launch would be the same kind of lie. Priority and
quiet-start behavior are pinned by ConnectivityIssueTests. 4 new
strings, all 30 locales.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Review fixes: banner in the sheet, real fix targets, tor-clear tests
- The people/DM sheet covers the root header, so the connectivity
banner vanished exactly where people sit longest. It now mirrors
into the sheet via a top safe-area inset over both the people list
and the DM view.
- "tap to fix" for powered-off Bluetooth opened the macOS privacy
permission pane, where an already-authorized person can't fix
anything. New SystemSettings.bluetoothPower routes to the Bluetooth
pane; denied still goes to the privacy anchor. The one-shot alert's
settings button routes by state the same way.
- Tests pin that torBlocked clears on tor-ready and on preference
change (no stale "tor can't connect" after toggling tor off).
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>
* Make the panic wipe confirmable and its outcome visible
The triple-tap panic wipe fired instantly with no confirmation, on the
same 18pt logo whose single tap opens App Info — while the far less
destructive triple-tap-to-clear-chat 40pt below it asks first, and the
Settings-pane panic button has always confirmed. A fumbled tap on the
app's only help affordance could permanently destroy identity, keys,
and messages.
- Triple-tap now raises the same confirmation dialog the Settings pane
uses (one extra tap under duress; zero accidental wipes).
- A successful wipe leaves a "all data wiped — new identity created"
system message: in duress, "did it work?" must not be a guess — the
natural response to uncertainty is tapping again.
- A wipe that does not commit (panicRecoveryBlocked) was previously
invisible: the app looked wiped, sat silently offline, and keys could
still be on disk. It now shows a persistent red banner under the
header saying data may remain and a relaunch retries.
- Settings/privacy copy no longer says "instantly" (all 30 locales).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Review fixes: dismiss sheets on wipe; host the dialog durably
- Codex P1: the App Info danger-zone wipe left its sheet presented, so
the failed-wipe banner (and the success message) rendered underneath
an opaque modal. panicClearAllData now dismisses all chrome-owned
presentation first; pinned by a new architecture test.
- Review nit: the confirmation dialog moved from the logo Text to the
ContentView header stack, so a covered/removed header can't take a
pending dialog down with 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>
* Add a recent-chats section so DM conversations can't become unreachable
The largest IA hole from the design/UX audit: a direct conversation
with someone who went offline (and isn't a mutual favorite) had no row
anywhere in the UI. The roster filters to connected/reachable/mutual-
favorite, the header envelope only exists while unread, and /msg can't
resolve offline strangers — read a DM from a passerby, close the
sheet, and the thread was still in memory with no way back to it.
- PeerListModel now derives RecentChatRow entries from the
ConversationStore's direct conversations: people absent from the
rosters above, newest activity first, unread flag, deduplicated by
fingerprint across ephemeral/stable peer-ID mirrors (newest wins),
groups and blocked peers excluded.
- A "chats" section (same header shape as #mesh/groups) renders them
in the people sheet on both mesh and location channels — geoDMs from
a channel since left stay reachable too. Tapping reopens the DM via
the existing startConversation path; the section renders nothing
when empty.
- Rebuilds are driven by direct-conversation store changes only, so
public-timeline traffic doesn't churn the sheet.
2 new strings, all 30 locales. New architecture test pins that an
offline stranger's thread gets a row while group threads don't.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Review fixes: geo dedup and geoDM names in recent chats
- A person still visible in the geohash roster could also get a recent
chat row (the builder only subtracted mesh rows). Visible geohash
pubkeys now join the identity set via their PeerID(nostr_:) form, so
the absent-from-rosters contract holds on location channels too.
- GeoDM rows went through resolveNickname, which only consults mesh
identity sources and rendered nostr_… keys as an opaque anon
fallback. They now resolve through geohashDisplayName (Nostr key
mapping, bare-key fallback).
Both pinned in the recent-chats architecture test.
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>
* Remove the public-channel screenshot broadcast
Taking a screenshot used to announce "* nickname took a screenshot *"
to the entire active public channel — a mesh broadcast, or on geohash
channels a mined ephemeral event published to the 5 nearest Nostr
relays, permanently timestamping that this nickname was present and
active at that place. Documenting something (or someone) is a core use
of a protest app; it must not out the person doing it.
- Public channels (mesh and geohash) no longer send anything on
screenshot. The mined-event helper is deleted and the lifecycle
context trimmed of its now-unused requirements.
- A geohash timeline screenshot instead raises the existing local
location-privacy warning alert (same one the channel sheet uses) —
warn the person, tell no one.
- DM screenshot notices remain, and the local "you took a screenshot"
echo is now honest: it only appears when the notice actually went to
the peer (it used to render even when no established session existed
and nothing was sent).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Review fixes: pin the screenshot routing table
The geohash warn path lived only in AppRuntime with no coverage. The
decision is now a pure nonisolated table
(AppRuntime.resolveScreenshotResponse) pinned by tests: location sheet
or geohash timeline → local privacy alert (nothing sent), App Info →
nothing, mesh/DM → chat layer (where public channels stay silent).
Mesh deliberately gets no local alert: a mesh screenshot reveals no
place and triggers no send, so there is nothing actionable to warn
about — alerting on every screenshot would train people to dismiss the
one alert that matters. Rationale now documented on the response enum.
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>
* Stop claiming encryption and privacy properties that aren't live
Two of the app's most safety-critical signals could show more security
than actually existed:
1. getEncryptionStatus was sticky-optimistic: any peer whose fingerprint
was ever persisted resolved to noiseSecured/noiseVerified even when
the live Noise session was .none, .handshaking, or .failed. After a
cold launch or a handshake failure the DM header showed a solid lock
and the composer caption claimed "end-to-end encrypted" with no
secure session in existence. The status now reflects only the live
session; a remembered fingerprint decides what an established
session upgrades to (verified vs secured), nothing more. Peers
reachable only over Nostr keep the encrypted caption — gift-wrapped
delivery is end-to-end without a Noise session.
2. Privacy copy told three lies (all 30 locales fixed):
- "ephemeral identity — new peer ID generated regularly": the peer
ID is stable until a panic wipe (rotation is spec-only). Now
"local-only identity — your identity is a keypair created on this
device; panic wipe replaces it instantly."
- "no servers, accounts, or data collection": location channels and
internet delivery go through Nostr relays. Now "no accounts, no
phone numbers, no data collection."
- location channels: "your IP address is hidden by routing all
traffic over tor" — tor is a toggle. The description now says tor
is the default, and the sheet shows the existing red tor-off
warning at the point of joining whenever the toggle is off.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Review fixes: gate nostr availability on a stored recipient key
- Codex P2 / review: a mutual favorite with a nil peerNostrPublicKey
still reported .nostrAvailable, so the DM caption could claim
"end-to-end encrypted" with neither a Noise session nor a usable
Nostr key. BitchatPeer.connectionState (and the header fallback in
PrivateConversationModel) now require a stored recipient key —
mirroring NostrTransport's reachability rule. Regression test:
mutual + nil key → .offline; key present → .nostrAvailable.
- Copy: "local-only identity" → "device-local identity" (all 30
locales) — once a fingerprint or QR is shared it isn't "only" local;
device-local says where the keys live without over-claiming.
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>
* Deflake gift-wrap tests: settle deadlines, not latency budgets
The gift-wrap round-trip tests failed three CI runs this week
(handleGiftWrap_privateMessageStoresConversationAndMapping,
handleGiftWrap_deliveredAckUpdatesExistingMessage,
handleGiftWrap_routesEmbeddedPrivateMessageAndDeduplicates), each with
the same signature: the async NIP-17 unwrap missed a 5s wait on a
loaded runner. 40 local iterations of both suites pass clean — the
failures are scheduler starvation, exactly the class
TestConstants.settleTimeout documents.
Every positive wait in ChatViewModelExtensionsTests and
ChatNostrCoordinatorContextTests now uses settleTimeout (30s): the
explicit 5.0s literals on the gift-wrap waits, the longTimeout media
waits, and the bare-default channel-switch waits. All are
expected-true waits, so passing runs return immediately and never pay
the deadline.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Deflake SimulatedMesh TTL budget: settle discovery before the baseline
publicMessageRelaysAcrossLineTopologyWithinTTLBudget snapshotted its
frame baseline after a single 2s advance, but discovery is not quiet
by then: every first-seen peer schedules an afterglow re-announce at a
random 0.3-0.6s delay (BLEAnnounceHandler), and each of those can
cascade another relay round. Whether that traffic lands before or
after the snapshot depends on the draw — CI measured the "single
message" at 14 and 18 frames against a budget of 12.
The test now advances until the mesh goes a full window with no new
frames before taking the baseline, so the budget only ever measures
the message under test. 30 local iterations green.
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 job shipped with its own promotion condition — "drop
continue-on-error once the baseline proves stable" — and the baseline
has now been stable across a month of merges since it landed July 8
(#1410). Known macOS-scan false positives stay suppressed by the
committed baseline; --strict already fails the step on NEW dead code,
so the only change is that the failure now blocks instead of annotating.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Two re-assessment findings:
- verifyScannedQR checked only staleness (now - ts > maxAge), so a
future-dated timestamp bought a QR a longer validity window than a
fresh one. The freshness check is now symmetric.
- Inbound Nostr DMs had no client-side created_at validation; the age
bound relied entirely on relays honoring the subscription's `since`
filter. Both gift-wrap decrypt paths now drop rumors outside
[now - lookback - skew, now + skew]. The inner rumor timestamp is the
sender's true send time (only the outer gift wrap is randomized per
NIP-17), so the window mirrors exactly what an honest relay already
guarantees — a dishonest relay can no longer inject stale or
future-dated DMs. Existing mitigations (persistent gift-wrap dedup,
relay-side since) are unchanged; this closes the malicious-relay gap.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Make SwiftLint blocking in CI now that the violation backlog is zero
The lint job has been advisory since #1361, with the backlog tracked in
#1088. That backlog is now down to 28 violations, so this clears it and
flips the job to enforcing instead of adding baseline machinery:
- Fix all remaining violations: closure parameters/capture lists joined
onto their opening-brace line (BLEService, NoiseSessionManager,
ChatMediaTransferCoordinator, BLENoisePacketHandlerTests), one
trailing comma, one opening-brace spacing (both via swiftlint --fix).
- Move the two periphery:ignore comments above the doc blocks they were
orphaning; verified with a periphery --strict scan that the commands
still register (no new findings vs baseline).
- Disable the todo rule: the single TODO cites tracked issue #1434 and
is a deliberate marker, not lint debt.
- Exclude .device-lab from local runs (untracked; CI never sees it).
- CI: drop continue-on-error and the "(advisory)" label; run with
--strict so any new warning fails the job.
Full SwiftPM suite green (2,004 tests / 216 suites) after the
formatting changes; swiftlint lint --strict exits 0 with the same
0.65.0 the CI container pins.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix is_disjoint violation introduced by #1542
The strict lint gate caught this on its first run: the mention-suggestion
key handler used modifierFlags.intersection([...]).isEmpty, which is
exactly the pattern isDisjoint(with:) expresses directly.
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>
Two hardening fixes from the repo evaluation:
- NoiseSessionManager.authenticatedRemoteKey returned true for peer IDs
that are neither 16-hex wire IDs nor full Noise-key IDs — an
accept-any-key fallback kept for test harnesses. It now fails closed;
the Noise/integration/E2E tests that relied on it address peers by
key-derived wire IDs instead (the pattern NoiseCoverageTests already
used), and a new regression test pins the rejection.
- Four SecRandomCopyBytes call sites discarded the return status. The
two verification nonces now fail their operation on error, the Nostr
device identity seed uses CryptoKit key generation (cannot fail, and
can no longer silently persist an all-zero seed), and BIP-340 aux
randomness throws on failure like the adjacent nonce path.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Tab and arrow keys for mention autocomplete
Highlight the selected suggestion and let Tab accept it. Up/down move
the selection when the mention panel is open; Tab otherwise still
cycles focus.
Co-authored-by: Cursor <cursoragent@cursor.com>
* Retrigger CI after flaky GeoRelayDirectory iOS test
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix: navigate mention suggestions with the same macOS key monitor as commands
Arrow keys never reach SwiftUI while the composer field editor has
focus, so adopt the NSEvent local monitor from #1504. Align accept
keys (Return or Tab), add Escape to dismiss, and match highlight opacity.
Co-authored-by: Cursor <cursoragent@cursor.com>
* Fix dead key monitor: gate on live state, not a value-captured Bool
A synthetic-event harness against the extracted modifier showed the
realistic path broken: the panel is hidden when the composer appears, so
onChange(of: isActive) ran on the previous render's modifier value and
installed a monitor whose closure had captured isActive == false — it
passed every key through forever. Arrows/Tab/Escape never worked on a
real Mac.
Install the monitor once for the view's lifetime and gate each event on
an isActive closure that reads the reference-typed model live. Same fix
applies to the iOS onKeyPress guards for consistency. Harness now passes
all paths including deactivate/reactivate.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* feat: show verification seal on private message sender rows
DM-only filled seal next to verified peers' names closes the remaining
UI gap from #1439 without dressing public mesh timelines.
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix: skip in-string verified ✓ on private rows with SF Symbol seal
Co-authored-by: Cursor <cursoragent@cursor.com>
* Add verified_sender catalog entry (30 locales) + live seal repaint on verify
The accessibility label existed only in code, so VoiceOver read english
in 29 locales; the coverage test can't see source-only keys. Also forward
peerIdentityStore.$verifiedFingerprints into objectWillChange so toggling
verification repaints rows in an open DM instead of waiting for the next
unrelated invalidation.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* feat: share location channel invites via the system share sheet
Adds text-first geohash invites (deep link + App Store URL) from
channel rows and the active-channel header, with an OpSec warning
for neighborhood-or-finer cells.
Closes#1497
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix: add Localizable.xcstrings entries for channel share copy
Cover all six new share/done keys across the 30-locale catalog so
LocalizationCoverageTests and non-English builds stop falling back
to English defaults.
Co-authored-by: Cursor <cursoragent@cursor.com>
* chore: retrigger CI after unrelated VoiceRecorder flake
Co-authored-by: Cursor <cursoragent@cursor.com>
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
* feat: let users set a local alias on the fingerprint sheet
Wire the existing localPetname field to a write path so peers can be
renamed locally; read paths already prefer the alias when present.
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix: make local aliases visible and localize the fingerprint field
Give local petnames display precedence over announced nicknames across
peer rows, DM headers, and resolveNickname; rebuild peer state after a
save so lists update immediately. Load the alias draft when the
fingerprint arrives, and add the three local-alias strings across all
30 locales.
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix: use macOS 13-compatible onChange for fingerprint alias sync
The two-parameter onChange API requires macOS 14; match the rest of the
views so release and Periphery builds stay green on the 13.0 deployment target.
Co-authored-by: Cursor <cursoragent@cursor.com>
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
The channels sheet grows a "quick join" row: one tap into the region-level
geohash channel around the device region's main population center — the
same path as typing the geohash and teleporting, no location access used.
Review of the first cut (a curated "heavily censored countries" roster)
called out that a hand-picked list invites inclusion disputes, goes stale
with politics, and is App Store / geopolitical exposure. The suggestion now
derives from the device locale under one neutral rule for every country:
ISO region → the 2-char geohash cell of the main population center (the
largest metro, not always the capital: US → New York, TR → Istanbul).
219 regions covered; the twelve cells the earlier roster shipped were
independently verified in review and reproduce unchanged.
The caption is deliberately blunt, per the same review: the cell belongs
to the main population center — it is not "your country's channel" and
not your location; the channel is public and well-known, so assume it is
watched; quick join is discovery — it hides nothing and bypasses nothing.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
MacImagePickerView used English string literals, so it skipped the string catalog and localization coverage. Move the user-facing strings into Localizable.xcstrings for all supported locales.
Co-authored-by: jack <212554440+jackjackbits@users.noreply.github.com>
* Add macOS camera QR scanning for peer verification.
Mac verification previously only supported paste/validate. Reuse the same AVCapture metadata pipeline as iOS, keep paste as a fallback, and extend the scanner smoke test to macOS.
* Grant sandboxed macOS camera access for QR scanning.
NSCameraUsageDescription alone is not enough under App Sandbox. Add com.apple.security.device.camera so the new macOS AVCapture QR path can open the camera after user permission.
* Check camera auth before capture input for QR scanning.
Consult AVCaptureDevice.authorizationStatus before creating AVCaptureDeviceInput so smoke tests and cold launches do not trigger TCC prompts, gate the smoke test on prior authorization, and show a one-line hint when the camera is unavailable.
* docs: specify peer ID rotation for cross-platform review
Draft protocol spec for review by both iOS and Android before any
implementation. Nothing here is implemented; this is the artifact to
agree on, since the change is a wire revision neither platform can ship
alone.
The headline correction, because it is easy to get wrong: rotating the
peer ID alone accomplishes nothing. The announce carries the Noise static
key, the Ed25519 signing key and the nickname in cleartext, so a rotated
ID is re-linked to the same device on its first announce. Rotation and
announce confidentiality have to land together.
The second thing an implementer needs to know up front is that
peerID == SHA-256(noiseStaticKey)[0..8] is not a convention, it is the
mechanism that makes peer IDs unforgeable, enforced in the announce
preflight and again at handshake completion. Making IDs independent of
the key fails both checks for every peer, so a replacement binding has to
ship in the same change. The spec proposes one: an Ed25519 proof over
(context, epoch, rotating ID, static key) carried inside the completed
Noise session via the existing AuthenticatedPeerStatePacket, checked
against a pinned signing key — strictly stronger than today's
self-signed announce.
Design summary: hour-epoch IDs derived from private key material via
HKDF+HMAC so no observer can predict or link them; pairwise recognition
tags from the X25519 shared secret so mutual favourites still recognise
each other with no handshake, padded to fixed slots so the tag count does
not leak how many favourites someone has; strangers discovered by
handshake-first-identify-second over Noise XX, whose static keys are
already encrypted on the wire. Nickname moves inside the session and the
neighbour list is dropped rather than rotated.
Includes a verified impact inventory separating what breaks hard (the
handshake check, the announce preflight, the disk outbox keyed by peer ID,
private-media stable IDs and their deletion tombstones, the initiator
tie-break, fingerprint-prefix lookups) from what degrades gracefully and
what is already safe because it keys on fingerprints or Noise keys.
Rollout uses the two mechanisms already proven in this repo: a
PeerCapabilities bit (11 is next; 10 is burned) with
capabilitiesWereExplicitlyAdvertised to tell an old client from a new one
with the bit off, and observed-version gating as used for source routing.
Two findings surfaced while writing this and are recorded in the spec.
CourierEnvelope.recipientTag is HMAC keyed on the recipient's *public*
static key, and since that key is broadcast in cleartext today, any
observer in radio range can compute a peer's courier tags for any day —
so the whitepaper's "cannot link it across days" does not currently hold,
and the pattern must not be copied. And NoiseEncryptionService's
buildAnnounceSignature/verifyAnnounceSignature/canonicalAnnounceBytes are
present but production-dead, called only from tests; the binding above
deliberately uses a different context string so the two can never be
confused.
Eight open questions are left explicitly unresolved, including the
rotation period, whether unsigned v2 announces are an acceptable posture,
and whether Android's decoder tolerates trailing bytes the way iOS's does
(which decides whether padding coverage can ship ungated).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* Implement the peer ID rotation primitives
Code is a better thing to argue with than prose, so the spec now has a
working, tested base under it. Every number and context string is a
concrete proposal you can reject by changing one function and watching a
test vector move.
What is implemented:
- PeerIDRotation: hour epochs with a ±1 matching window, the rotation
secret from the Noise static *private* key, per-epoch peer IDs, pairwise
recognition keys and tags from an X25519 shared secret, the fixed-width
tag block with CSPRNG padding and constant-time matching, and the
canonical bytes for the identity binding.
- AnnounceV2Packet (announceV2 = 0x05): TLV wire format carrying an epoch,
a 64-byte tag block, capabilities and an optional bridge cell — and
nothing else. No nickname, no public keys, no neighbour list. Rejects a
wrong-width tag block on both encode and decode, since a short block
would disclose how many mutual favourites someone has, and rejects
non-canonical capability encodings the way AuthenticatedPeerStatePacket
does. Unknown TLVs are skipped for forward compatibility.
- 37 tests, three of which are hex vectors cross-checked against an
independent implementation written from the spec alone (Python
hmac/hashlib, HKDF extract-then-expand, empty salt) and matching byte
for byte. That is the property Android needs: the document is sufficient
to reproduce the numbers without reading this code.
What is deliberately NOT implemented: nothing emits a v2 announce, and
BLEService parses the type and explicitly ignores it. Consuming presence
needs both the replacement identity binding and a decision on how
unverified presence appears in the peer list, and accepting it now would
put unauthenticated entries in front of people.
Adding the message type forced three policy decisions, all reviewable:
- Not gossip-synced. Syncing presence would defeat the point — a device
never in radio range could collect tag blocks, turning a local beacon
into a network-wide one.
- Not padded. At ~75 bytes the smallest bucket would triple the airtime of
the most frequent packet in the protocol; the format is already
near-constant width, and fixing the capability and geohash field widths
would be cheaper than padding.
- Parsed but ignored on receive, as above.
Notably the v2 announce is *smaller* than v1 (~75 vs ~229 bytes): dropping
two 32-byte keys, the neighbour list and the signature more than pays for
64 bytes of tags, so unlinkability here costs less airtime rather than
more.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* Mark the rotation primitives periphery:ignore
The dead-code scan correctly flagged both new types as unused, which they
intentionally are: they exist to be reviewed and argued with before the
protocol change they belong to can ship.
Annotated in place rather than added to .periphery.baseline.json so the
reason sits next to the code and disappears with it, following the
existing convention in MessageRouter. Both notes say to delete the
annotation once the mesh starts using the type.
`periphery scan --strict` locally: no unused code detected.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* Fix two P1 flaws in the recognition tag design (Codex #1487)
Both findings are correct and both were real. This is the argument for
shipping code next to the prose: neither was obvious in the design text.
**Tags were symmetric, which leaked the social graph.** `HMAC(K_AB, epoch)`
produces the same 8 bytes for both parties, so an observer who saw one
value in two different announces would learn those two devices are mutual
favourites, and could link their two rotating IDs to each other — handing
over exactly the graph the design exists to hide, plus a cross-epoch
correlation handle. Tags are now directional: the MAC covers the ordered
sender and recipient static public keys, so A→B and B→A differ. Both
parties can still compute both directions because both hold both keys.
**Tags were replayable under any ID.** A tag depending only on
(pair, epoch) could be lifted from a recorded announce and replayed in a
fresh announce under an attacker-chosen ID; the recipient would match and
treat that ID as the favourite, and since epoch-1 is accepted it would
keep working into the next period. The MAC now covers the announced peer
ID, which reduces this to replaying the victim's own presence.
That residual is unfixable while announces are unsigned, so the spec now
states plainly that recognition is a hint only: presence may be populated,
but routing a DM or showing a verified badge must wait for a handshake
whose static key equals the favourite that produced the match. O4 is
rewritten around that, with the two alternatives named (per-epoch
ephemeral signing key, or a freshness nonce echoed by the recipient).
Tests: two regression cases named for the findings, plus a
wrong-direction-does-not-match case so the directional fix cannot silently
become cosmetic. The vector table now gives both directions, because their
difference is the security property — an implementation that produces one
value for both has reintroduced the flaw. Recomputed independently in
Python from the spec and matched byte for byte.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs: record that padding changes are cross-platform coordinated
O7 began as a question about whether Android tolerates trailing bytes.
The firmer answer, found while attempting the padding fix unilaterally:
toBinaryDataForSigning encodes with padding enabled, so the padding bytes
are inside the signed material for every signed packet. Changing the
algorithm changes the signed byte stream and breaks verification against
any peer that has not made the identical change.
So both outstanding padding fixes — coverage beyond Noise frames, and the
gap where a frame needing over 255 bytes of padding ships unpadded — are
wire changes requiring both platforms, not local cleanups. O7 now says so,
and names the two things to settle.
Also updates the related-work section: dropping the neighbour list and
randomizing origin TTL did turn out to be unilateral and have landed
separately.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* Close the review findings on the rotation spec
**P1 — the binding proof was replayable onto another session.** The §4.5
verifier checklist omitted the check that the proof's noiseStaticPublicKey
equals the remote static key the Noise session actually established. The
proof is a self-contained signed blob with nothing tying it to the session
it arrives on, so a peer M that had seen A's proof could replay it verbatim
inside M's own session with B; B would verify A's signature, see a
well-formed binding, and on first contact TOFU-pin A's signing key against
M's fingerprint. Added as the first item in the checklist, with the attack
written out, because "signed" and "bound to this conversation" are
different properties and the difference is easy to lose in a bullet list.
**announceV2 is 0x2C, not 0x05.** 0x05 only looks free. It has been
recycled twice — announce, then bulkTransferResponse, then fragmentStart
until #446 — so an old peer could still map it to a fragment header and
misparse presence as a partial message. Values above voiceFrame = 0x29
have only ever been allocated forward, and 0x2A/0x2B belong to the courier
spray-ack work, leaving 0x2C. Confirmed never used anywhere in this
repository's history.
**Outbound priority is now stated, not inherited.** announceV2 fell through
to `default: .high`. High is the right answer — presence is small,
time-bounded to its epoch and useless once stale — but for a type nothing
emits yet, a fall-through means the choice gets made without anyone seeing
it.
**Reverted unexplained pbxproj churn.** Xcode had rewritten resource-phase
ordering and dropped a share-extension entitlements membership exception;
none of it belongs in this PR. The file now matches main byte for byte.
**O7 said "payloads" where the arithmetic is over encoded frames.** The
241-256 / 497-768 / 1009-1792 ranges are what `pad` receives, which is the
whole encoded packet, not the payload alone.
**Added O9: a seized device recomputes every past peer ID.** K_rot is
long-lived, so peerID_e is computable for any epoch by whoever holds it —
someone who seizes a phone, or pulls the static key from a backup, can go
back over historical radio captures and identify which were this device.
Rotation defends against the passive observer, not against later key
compromise. A hash ratchet would give forward secrecy for the ID stream at
the cost of state that must survive restarts, tolerate clock jumps, and
resynchronise after a gap — a real trade rather than an obvious win, so it
is written down as a question rather than silently adopted.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs: rotation capability bit is 14 now — 11-13 claimed by in-flight work
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
All four surfaced in the 1.7.1 RC window and are behavior-neutral:
- sendPacket(to:) discarded sendPacketDirected's Bool through generic
onEngine, tripping unused-result (from #1547's engine-domain flip).
- Both _test_drain*Pipeline helpers captured non-Sendable self in
@Sendable dispatch closures; they only need the queue, which is
Sendable — capture that instead.
- removeEphemeralSession returned removeValue's result out of the
barrier closure, tripping unused-result on sync(flags:execute:).
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
waitUntilActivationBegan hardcoded a 5-second DispatchSemaphore timeout
— below the 10s house floor and invisible to TestTimingHygieneTests
(it's a semaphore wait, not a helper-timeout parameter). On a starved
runner the window expired before the recorder's session-acquire task
was scheduled, failing cancelWhileSessionAcquireIsInFlightNeverCreates-
ARecorder — 7 sightings, including three in the last two days (#1506
and #1528 merge runs, #1550's PR run).
The fix is extracted verbatim from #1107 (mmalmi), which carries it but
is blocked on a V3 rebase: both test gates (activation and padding)
drop their DispatchSemaphore + timeout for an untimed async-event wait
(VoiceRecorderAsyncEvent), so there is no timing constant left to
starve — the test framework's own timeout is the backstop. Extracting
it unblocks CI now; #1107's rebase will see this file already matching
its branch.
Verified (count-checked via xcresulttool): 7/7 VoiceRecorderTests on
the iOS simulator, and 7/7 x 5 consecutive runs under 16x CPU
oversubscription.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
`BitchatFilePacket.decode` skips tags it does not recognise
(`case nil: continue`), which is what keeps the TLV list a floor rather
than a ceiling: a field the sender considered optional costs the receiver
that field, not the whole file.
Nothing pinned it. The behaviour is load-bearing for any peer, version or
third-party client that adds a field this build has not seen, and it is
also where the two implementations diverge — the Android decoder returns
null on an unknown tag, which is why `PrivateMediaMessageIdentity` has to
derive its receipt key from fields already on the wire instead of adding
one. Worth a test on the side that gets it right so it cannot quietly
drift into the strict behaviour.
Two cases, both hand-built so they do not depend on our own encoder:
an unknown TLV between MIME_TYPE and CONTENT (where an encoder appending
content last would put it), and one trailing CONTENT. Changing
`case nil: continue` to `return nil` fails both.
Co-authored-by: jack <212554440+jackjackbits@users.noreply.github.com>
Media payload writes used .atomic alone and inherited the container
default; the courier store, outbox, gossip archive, and receipt index
all state their protection class at the write site. Media now follows
the same convention: until-first-user-authentication on payload writes
and on every site that creates a media directory (the store's helpers,
live captures, the outgoing writers, and the files/ root creators), so
recordings that save as they go inherit it. A best-effort launch
migration stamps files written by older builds, applying only to items
at the container default or weaker so it can never downgrade, running
detached after the retention sweep from #1484. On stock devices the
container default already yields this class, so behavior does not
change; the protection is now stated in the code instead of inherited.
Full iOS suite green; macOS builds; swiftlint adds no violations.
Co-authored-by: jack <212554440+jackjackbits@users.noreply.github.com>
* fix: re-inject environment objects into the people sheet
Sheets hosting a NavigationStack can drop inherited EnvironmentObjects on
some iOS versions, crashing ContentPeopleListView / MessageListView (#1558).
Co-authored-by: Cursor <cursoragent@cursor.com>
* test: note people-sheet environment contract in smoke mount
Make the #1558 regression visible next to the ContentView / people-sheet
smoke mounts so a future env-object trim is harder to miss.
Co-authored-by: Cursor <cursoragent@cursor.com>
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: jack <212554440+jackjackbits@users.noreply.github.com>
* Cohere per-link Noise auth and rebind containment into BLELinkAuthState
The authenticated-link owners, the reconnect revalidation policy, and
the two rebind-containment cooldowns were four loose bleQueue-owned
maps whose invariants lived in call-site discipline: every teardown
path had to remember to retire the proof AND close the revalidation
epoch (the pair appeared seven times), and both cooldowns hand-rolled
the same prune-check-record dance. BLELinkAuthState owns them as whole
transitions — retireLink, retireLinks(ownedBy:), permitRebind,
permitRedundantRetirement — with the ownership question (bleQueue
today, engine after the option-B flip) answered in one place.
No behavior change; the one call-site reordering (redundant retirement
computes the survivor before the cooldown check instead of after) is
outcome-equivalent since the cooldown only ever recorded when a
survivor existed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Split identity-link bindings out of the physical link store
BLELinkStateStore owned two different kinds of truth: what physical
links exist (CB handles, connect lifecycles, characteristics, stream
assemblers) and who each link belongs to (peer bindings in both roles
plus the preferred-peripheral reverse map for directed sends and fanout
collapse). The bindings now live on BLELinkBindings — same bleQueue
ownership, whole-transition methods, direct tests for the rotation
reverse-map cleanup and the preferred-link survivor repair that were
previously only exercised end to end. Composed operations that need
both truths (remove-with-repair, direct link state, the subscribed-
central snapshot, bind-only-live-links) live on the transport as
explicitly bleQueue-confined helpers.
This is the structural half of the option-B boundary flip
(docs/BLE-ARCHITECTURE-V3.md): ownership of the bindings can now move
to the engine without touching what-links-exist. An audit of every
physical clear/remove found three sites (emergency clear, both
unauthorized branches) that needed explicit binding-clear pairing under
the split — each now clears both.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix iOS-gated constructors and preserve containment cooldowns on reset
CI caught what the macOS SwiftPM build cannot see: two #if os(iOS)
sites still passed the peerID field that slice B1 removed from
BLEPeripheralLinkState (willRestoreState in BLEService and
armPendingBackgroundConnects in BLERadioController). Both fixed and
verified with a local iOS simulator xcodebuild.
Codex also caught a real regression: BLELinkAuthState.removeAll()
cleared the rebind/retirement cooldown maps, which the original panic
and emergency reset paths deliberately left alive. A stable
CoreBluetooth UUID must not earn a fresh rebind allowance just because
the session state around it was wiped. removeAll() now clears only the
proofs and revalidation epochs, and BLELinkAuthStateTests pins the
survival invariant along with the other auth-state transitions.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Link layer slice 3: the option-B domain flip — bindings and link-auth move to the engine
The identity domain (BLELinkBindings + BLELinkAuthState) is now owned
by the engine queue, with a DEBUG dispatchPrecondition trapping any
access from another queue. bleQueue keeps only physical link state.
What changed shape:
- Receive path is sans-I/O: bleQueue decodes frames and hands
(packet, linkID) up through ingestDecodedPacket (panic lifecycle
captured at the handoff); attributeAndHandlePacket resolves the
sender binding, rejects spoofed senders, applies raw-announce
binding, and records ingress on the engine. Per-link frame order is
preserved end to end (both queues serial), which supersedes the old
batch-local TOCTOU binding in the notification path.
- The rotation rebind is one engine slot: containment checks, proof
retirement, binding flip, reconnect decision, and rotated-identity
retirement run straight-line; only CoreBluetooth cancels hop to
bleQueue. The engine->bleQueue->engine ping-pong is gone, along with
the _test_afterVerifiedDirectRebindEnqueued pause hook — the test
that used it now asserts the atomicity directly (a paused engine
wedged the old gate design into a three-queue deadlock).
- Authenticated-send eligibility (notifyOrEnqueueIfAccepted,
writeOrEnqueueIfAccepted) is checked on the engine, serialized
against rebinds by construction; only physical admission
(updateValue/write/backpressure) runs on bleQueue.
- Teardown splits into discardPeripheralLinkPhysical (bleQueue, inline
in the delegates) + retirePeripheralLinkIdentity (engine hop with
survivor repair reading liveness via readLinkState). A binding can
briefly outlive its physical link; liveness queries join against the
physical store and the queued retirement converges the two.
- Gossip delegate sends enter the engine via onEngine — safe because
mesh.sync sits above the engine in the sync order (production engine
code only async-dispatches into the manager).
- checkPeerConnectivity rides an engine slot from the bleQueue
maintenance tick.
No wire changes. 1,974 tests green (parallel and serial), iOS
simulator build clean, Periphery clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Link layer slice 4: deterministic multi-node mesh simulation — and the panic-announce bug it caught
SimulatedMesh wires real CoreBluetooth-free BLEService engines
edge-to-edge through the outbound packet tap and _test_ingestFrame
(the production attribution path the B2 flip created), with per-edge
synthetic link IDs and manual-scheduler time. Five multi-node tests
run in ~40ms with no wall-clock waits:
- announce exchange binds simulated links and connects peers
- Noise sessions establish end-to-end (real crypto, both directions)
- a public message relays across a line topology inside a TTL/frame
budget (storm bound asserted)
- an 8x duplicate flood delivers exactly once
- a panic rotation rebinds the survivor's link exactly once and stays
— the scenario that previously needed two phones and log archaeology
Fidelity boundary (documented in the harness): no physical links, so
fanout planning and backpressure are not exercised; attribution,
binding, dedup, TTL, relay decisions, and sessions are the real
engine code.
The simulator found a real bug on its first run: the forced-announce
throttle's lastSent survived a panic, so a rotation within
bleForceAnnounceMinIntervalSeconds of the last announce silently
swallowed the new identity's announce — leaving it invisible to the
mesh until the next maintenance cycle. Today's device test only
passed because the previous announce happened to be minutes old.
BLEAnnounceThrottle gains reset(), called from the panic slot so the
rotated identity owes no throttle debt; pinned by a unit test and the
mesh rotation test.
New DEBUG seams: _test_ingestFrame (production ingress attribution),
_test_forceAnnounce, _test_fenceEngine.
1,980 tests green, Periphery clean, iOS simulator build clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Link layer slice 5: name the port — BLELinkEvent, one engine entry, delegates in their own files
The upward half of the link-layer port is now a type. BLELinkEvent
enumerates everything the bleQueue link layer tells the engine:
frameDecoded plus the four physical lifecycle transitions
(peripheralLinkEnded, centralLinkEnded, allPeripheralLinksEnded,
allCentralLinksEnded). Every bleQueue→engine crossing goes through
emitLinkEvent into one engine consumer (handleLinkEvent) — the
scattered messageQueue.async identity hops in the delegates collapse
into event emission, and the engine-side retirement/bookkeeping logic
now lives in one switch.
The CoreBluetooth delegate extensions move to their own files as
physical bookkeeping plus event emission:
- BLEService+LinkLayerCentralRole.swift (CBCentralManagerDelegate +
CBPeripheralDelegate)
- BLEService+LinkLayerPeripheralRole.swift (CBPeripheralManagerDelegate
+ write accumulation)
BLEService.swift drops from 7,836 to ~7,100 lines. The physical-domain
members the role files share flip private→internal; the queue contract
is enforced by the existing DEBUG traps and grep guards, not access
control. (Two of the flips — isAppActive, logBluetoothStatus — only
surfaced on the iOS build; macOS SwiftPM cannot see #if os(iOS) code.
Verified with a local iOS simulator build.)
The simulated mesh now drives lifecycle events through the identical
enum a radio does: linkDropEventRetiresBindingAndReconnectHeals covers
drop → identity retirement → last-link peer bookkeeping → re-announce
heal, entirely through the port. New seam _test_resetAnnounceThrottle
models elapsed wall-clock for the throttle (deliberately separate from
_test_forceAnnounce so the panic-rotation test keeps its regression
value: the production panic path must do its own reset). The panic
test's containment re-announces reset throttles explicitly so those
assertions exercise real delivered announces instead of silently
throttled ones. noiseSessionEstablishesEndToEnd gains a bounded
scheduler-time settle loop after a one-in-many parallel-suite flake
(no wall-clock waits).
Deliberately not done (recorded in docs/BLE-ARCHITECTURE-V3.md): a
formal handle(event)->[Effect] system and further engine-domain file
splits — both would flip the engine's private state to internal for
cosmetic file counts; the effect formalization rides future feature-
module extractions instead.
1,981 tests green, Periphery clean, iOS simulator build clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Baseline logBluetoothStatus for the macOS Periphery scan
Its callers are all inside #if os(iOS) (willRestoreState in both role
files plus the app-state handlers), so the macOS-scheme scan sees the
now-internal declaration with zero callers — the same class as the
baselined candidateCount. Verified 1-USR diff; the previously private
mangled variant was already baselined, which is why the pre-split scan
never flagged it.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix#1538: release stale bindings on rotation instead of leaving a ghost
With two live links to one phone, a panic rotation healed only the link
the verified announce arrived on. The second link kept its binding to
the retired identity, so that dead ID stayed in the peer list — and was
kept alive by the NEW identity's own traffic, since a bound link
attributes non-announce frames to its bound peer. It only healed when
the stale link physically dropped.
The issue proposed exempting the containment rule via retiredBy[X] = Y
so the second link could rebind. Two problems: the exemption's stated
precondition (X removed by retireRotatedPeer) can never hold in this
scenario — the retire is gated on X having no remaining links, which is
false precisely because the stale link exists — and it would loosen a
security rule to fix a liveness bug.
Instead the rotation now RELEASES every link still bound to the
rotated-away identity (unbind + retire that link's Noise proof) and
retires the identity. No containment rule changes: unbinding is
strictly less trusting than any binding, and it is correct under both
readings of a second link bound to the retired ID — same physical
device (the field case), or one link is a spoofer holding a forged
binding, since a peer ID is a Noise-key fingerprint and two devices
cannot both legitimately own it. Released links reconverge through the
ordinary unbound-link path: the next raw direct announce binds them to
whoever they actually carry.
Reproduced and fixed under the slice-4 simulator, which is why this
lands as tests rather than another two-phone session:
- duplicateLinkPanicRotationLeavesNoGhostAndHealsBothLinks fails
without the fix (ghost in both knownPeers and getConnectedPeers,
duplicate link still bound to the dead ID)
- replayedVerifiedAnnounceCannotStealALinkOrEvictTheVictim pins the
#1401 containment rule against exactly the attack this fix had to
avoid re-opening, with a positive control proving the refusal is the
containment check and not duplicate suppression
Harness gains connectDuplicateLinks (two links to one peer, modelled in
the central role — the links we cannot cancel, and the only role whose
bindings a CB-free harness can form), silence (range loss without a
link event, so a packet can be captured that the far side never saw),
and emittedPackets (the attacker's capture buffer).
Residual, documented at the fix: an attacker who binds their own link
to X by replaying X's raw announce can drive a rebind there and so
evict X's registry entry; X's next announce restores it, and the
per-link rebind cooldown bounds the rate. This is the same class of
capability the containment already accepts, not a new one.
1,983 tests green, Periphery clean, iOS simulator build clean.
Closes#1538
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix the retire↔reconnect oscillation: redundant-link survivor is the newest connection
Field-observed July 31 on main: with a restored old-address link and a
fresh-address duplicate to the same phone, redundant-link consolidation
kept choosing the restored link as survivor (it carried the announce
ingress and the binding) and cancelling the fresh one — which the radio
promptly rediscovered and reconnected, because the fresh link sits on
the BLE address the peer still advertises. Retire, reconnect, repeat at
the retirement cooldown (~1/min) until the ingress happened to flip.
Battery and airtime noise on every restore-with-duplicates.
BLERedundantLinkPolicy now prefers the most recently CONNECTED
candidate. Only the newest connection lives on the currently advertised
address; the older-address link cannot return once cancelled, so
consolidation converges on the first pass. BLEPeripheralLinkState gains
lastConnectedAt (set by markConnected; nil for restored links, whose
connect predates the process — exactly the 'stale address' signal).
Security note: physical connect recency is a signal an announce replay
cannot nominate, unlike the previous ingress-link preference — the
announce anchors (ingress, then most recently bound) are demoted to
tie-breakers and the fallback for all-restored links. Writability still
trumps everything: a newest link mid-service-rediscovery is never kept
over a writable duplicate. Containment (bound-links-only, one
retirement per peer per cooldown, peer keeps a live link) unchanged.
Six policy tests pin the new order, including the field scenario
(restored link holding both announce anchors loses to the fresh
connection) and the legacy fallback.
1,988 tests green, Periphery clean, iOS simulator build clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Defer consolidation while the newest connection is still mid-discovery
Codex P2 on #1566: a fresh duplicate that has connected but not yet
finished service discovery was excluded from the writable candidate
set, so the policy kept the older writable (restored) link and
cancelled the freshly advertised connection — recreating the
retire↔reconnect oscillation inside the discovery window. Now, when
the physically newest connection is not writable yet while a writable
duplicate exists, consolidation defers to a later announce instead of
guessing. Also documents that RSSI is deliberately not a policy input
(Chessing234's rule-pinning ask) and pins the defer window, the
restored-anchor variant, the co-newest writable tie, and the
all-unwritable recency path with 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>
SimulatedMesh.addNode installed the outbound tap one statement after
setNickname, but setNickname force-announces asynchronously on the
engine. When a starved runner let that slot run inside the gap, the
announce was emitted invisibly while still stamping the wall-clock
announce throttle, and announceAll's forced announce — arriving well
inside the 0.15s forced minimum interval — was swallowed. No discovery
traffic ever reached the mesh, so bindings stayed nil and peer lists
empty: the exact 4-issue signature that failed three main runs and one
PR run on July 30.
Reproduced deterministically by forcing the ordering with a 5ms sleep
after setNickname: all 8 SimulatedMesh tests fail on the old harness
and pass on the fixed one.
Fixes: install the tap before setNickname so an early nickname announce
is captured instead of lost; reset each node's throttle in announceAll
so wall-clock throttle debt can never swallow the discovery round
(forceAnnounce(from:) deliberately keeps no-reset — the panic-rotation
tests pin the production reset behavior through it); and take the lock
around addNode's array appends, which could race the tap reading
`emitted` on an earlier node's engine.
Verified: suite green normally, 8/8 tests x 6 runs under 16x CPU
oversubscription, and 8/8 under the adversarial forced ordering —
all count-verified via xcresulttool (an earlier single-test
-only-testing filter silently matched zero tests, so every result
here was re-checked against reported test counts).
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
immediateLegacyRestartDuringCompletionGrace injected a 0.03s initiator
completion grace period and needed the restart initiation to arrive
inside it. Constructing the restarted service (keypair generation) sits
between starting that clock and processing the message, so on a starved
CI runner the window expired first, the initiation was processed as a
legitimate fresh handshake, and the nil-expectations cascaded — the
most-sighted flake in CI (7 runs across #1502, #1477, #883, #1364, and
main).
The test now injects a grace period no test run can outlive, so the
in-grace suppression and the duplicate-initiation coalescing are decided
deterministically, and fires the deferred recovery through a DEBUG hook
on NoiseSessionManager instead of waiting out the real timer. The hook
cancels the scheduled work item before requesting recovery, so the
converged-once assertion cannot double-fire either.
Verified (count-checked via xcresulttool): the full 30-test
NoiseEncryptionServiceTests suite green on the iOS simulator, and
30/30 x 5 consecutive runs under 16x CPU oversubscription (a 6th run
was lost to a simulator app-launch refusal under load — no tests
executed). The old test did not reproduce locally in 2 suite runs
under the same load; the starvation needs the slow 2-core CI runner,
so the diagnosis rests on the mechanism plus the identical assertion
signature in all seven CI sightings.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
reservePendingStarts() decremented availableSlots for every dequeued pending
transfer before checking whether it would actually be admitted. A request
blocked because its transferId is already active (a resend of in-flight
content sitting at the front of the queue) still consumed a slot even
though it was deferred back into the queue rather than started -- so a
single blocked front-of-queue item could zero out the budget and end the
loop before ever reaching a later, unrelated, genuinely startable pending
transfer. That transfer then sat starved until some other transfer
happened to complete and trigger another pass, rather than starting
immediately when real capacity was already available.
Move the decrement to the point where a transfer is actually admitted into
activeTransfers, so only genuine starts spend the budget.
* Replace try! regex construction with a non-trapping SafeRegex helper
MessageFormattingEngine and MessageDeduplicationService compiled eight
bundled regex literals with try!, so a bad pattern would crash the app
at startup - in the middle of the message-render path (#645).
Add SafeRegex.compile: it compiles the pattern normally, and on failure
logs through SecureLogger and returns a never-matching regex ('(?!)'),
so a broken pattern degrades that one formatting feature instead of
trapping. Pattern properties stay non-optional, so no call-site churn
across ChatMessageFormatter, MessageTextHelpers, and
ChatComposerCoordinator.
The compile-time guarantee try! provided moves into tests: each
production pattern is asserted to compile and match a known-good sample,
so a typo in a pattern now fails CI instead of crashing users.
Part of #645 (the remaining try! sites; NoiseSessionManager's
force-unwrap is addressed separately in #1456).
* Normalize nicknames to Unicode NFC at storage and comparison boundaries
A nickname containing an accent can arrive in two canonically equivalent
but bytewise different forms: precomposed (U+00E9) or decomposed
(e + U+0301), depending on the keyboard and platform that produced it.
Nicknames were stored and compared without normalization, so visually
identical names silently failed to match: mentions of your own name did
not highlight or notify, /msg and /block could not resolve the peer,
autocomplete skipped candidates, and geohash DM resolution failed (#214).
Fix by canonicalizing to NFC (String.normalizedNickname) at every
boundary where a nickname enters storage - own nickname (ChatViewModel
didSet, alongside the existing trim), verified announce ingest
(BLEPeerRegistry), geohash presence (LocationPresenceStore), and
InputValidator.validateNickname - and by normalizing both sides at
comparison sites that can still see pre-normalization data (persisted
favorites, message-content mentions): peer resolution in
UnifiedPeerService and ChatPeerIdentityCoordinator, the three mention
checks, and autocomplete prefix matching.
The wire codec (AnnouncementPacket) is deliberately untouched: announces
are signature-verified against raw bytes, so canonicalization happens at
the storage layer, never during parsing.
Fixes#214
Correct a confirmation label typo in the public-chat E2E suite and bump
the README relay-network claim to match the current GPS relay list.
Co-authored-by: Cursor <cursoragent@cursor.com>
Surface fingerprint verification in the message timeline so a verified
contact is distinguishable from an impersonator without opening the
fingerprint sheet.
Co-authored-by: Cursor <cursoragent@cursor.com>
MessageFormattingEngine and MessageDeduplicationService compiled eight
bundled regex literals with try!, so a bad pattern would crash the app
at startup - in the middle of the message-render path (#645).
Add SafeRegex.compile: it compiles the pattern normally, and on failure
logs through SecureLogger and returns a never-matching regex ('(?!)'),
so a broken pattern degrades that one formatting feature instead of
trapping. Pattern properties stay non-optional, so no call-site churn
across ChatMessageFormatter, MessageTextHelpers, and
ChatComposerCoordinator.
The compile-time guarantee try! provided moves into tests: each
production pattern is asserted to compile and match a known-good sample,
so a typo in a pattern now fails CI instead of crashing users.
Part of #645 (the remaining try! sites; NoiseSessionManager's
force-unwrap is addressed separately in #1456).
BitchatMessage.deliveryStatus was Optional, with nil implicitly meaning
'no tracking' for public messages. Every consumer had to branch on the
absent case, ranking needed an optional-aware helper, and the UI treated
nil as an invisible state (#644).
Model delivery as a total state machine instead:
- New DeliveryStatus.notSentYet: created but not yet handed to any
transport. Public messages initialize to it; private messages keep
their historical .sending default.
- BitchatMessage.deliveryStatus becomes non-optional. Archives written
while the field was optional decode with the absent key mapped to
.notSentYet. The wire format is untouched (toBinaryPayload never
carried the field).
- deliveryStatusRank drops its optional parameter; .notSentYet ranks
below .failed, preserving the existing dedup preference order.
- Conversation.shouldSkipStatusUpdate treats a write back to .notSentYet
as a downgrade and skips it.
- The status indicator renders exactly as before: .notSentYet draws
nothing in message rows (the state nil used to represent), and
DeliveryStatusView gains a glyph and description for it only so the
view stays total.
Tests: initialization defaults, legacy-archive decoding, round-trip,
the extended rank order, and the new downgrade rule.
Fixes#644
* Keep blocked peers out of @-mention suggestions
Blocked mesh nicknames and blocked geohash pubkeys no longer show up
in the composer autocomplete list.
Co-authored-by: Cursor <cursoragent@cursor.com>
* Fix blocked-mention test resetting private(set) state
Co-authored-by: Cursor <cursoragent@cursor.com>
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
* Cohere per-link Noise auth and rebind containment into BLELinkAuthState
The authenticated-link owners, the reconnect revalidation policy, and
the two rebind-containment cooldowns were four loose bleQueue-owned
maps whose invariants lived in call-site discipline: every teardown
path had to remember to retire the proof AND close the revalidation
epoch (the pair appeared seven times), and both cooldowns hand-rolled
the same prune-check-record dance. BLELinkAuthState owns them as whole
transitions — retireLink, retireLinks(ownedBy:), permitRebind,
permitRedundantRetirement — with the ownership question (bleQueue
today, engine after the option-B flip) answered in one place.
No behavior change; the one call-site reordering (redundant retirement
computes the survivor before the cooldown check instead of after) is
outcome-equivalent since the cooldown only ever recorded when a
survivor existed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Split identity-link bindings out of the physical link store
BLELinkStateStore owned two different kinds of truth: what physical
links exist (CB handles, connect lifecycles, characteristics, stream
assemblers) and who each link belongs to (peer bindings in both roles
plus the preferred-peripheral reverse map for directed sends and fanout
collapse). The bindings now live on BLELinkBindings — same bleQueue
ownership, whole-transition methods, direct tests for the rotation
reverse-map cleanup and the preferred-link survivor repair that were
previously only exercised end to end. Composed operations that need
both truths (remove-with-repair, direct link state, the subscribed-
central snapshot, bind-only-live-links) live on the transport as
explicitly bleQueue-confined helpers.
This is the structural half of the option-B boundary flip
(docs/BLE-ARCHITECTURE-V3.md): ownership of the bindings can now move
to the engine without touching what-links-exist. An audit of every
physical clear/remove found three sites (emergency clear, both
unauthorized branches) that needed explicit binding-clear pairing under
the split — each now clears both.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix iOS-gated constructors and preserve containment cooldowns on reset
CI caught what the macOS SwiftPM build cannot see: two #if os(iOS)
sites still passed the peerID field that slice B1 removed from
BLEPeripheralLinkState (willRestoreState in BLEService and
armPendingBackgroundConnects in BLERadioController). Both fixed and
verified with a local iOS simulator xcodebuild.
Codex also caught a real regression: BLELinkAuthState.removeAll()
cleared the rebind/retirement cooldown maps, which the original panic
and emergency reset paths deliberately left alive. A stable
CoreBluetooth UUID must not earn a fresh rebind allowance just because
the session state around it was wiped. removeAll() now clears only the
proofs and revalidation epochs, and BLELinkAuthStateTests pins the
survival invariant along with the other auth-state transitions.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Link layer slice 3: the option-B domain flip — bindings and link-auth move to the engine
The identity domain (BLELinkBindings + BLELinkAuthState) is now owned
by the engine queue, with a DEBUG dispatchPrecondition trapping any
access from another queue. bleQueue keeps only physical link state.
What changed shape:
- Receive path is sans-I/O: bleQueue decodes frames and hands
(packet, linkID) up through ingestDecodedPacket (panic lifecycle
captured at the handoff); attributeAndHandlePacket resolves the
sender binding, rejects spoofed senders, applies raw-announce
binding, and records ingress on the engine. Per-link frame order is
preserved end to end (both queues serial), which supersedes the old
batch-local TOCTOU binding in the notification path.
- The rotation rebind is one engine slot: containment checks, proof
retirement, binding flip, reconnect decision, and rotated-identity
retirement run straight-line; only CoreBluetooth cancels hop to
bleQueue. The engine->bleQueue->engine ping-pong is gone, along with
the _test_afterVerifiedDirectRebindEnqueued pause hook — the test
that used it now asserts the atomicity directly (a paused engine
wedged the old gate design into a three-queue deadlock).
- Authenticated-send eligibility (notifyOrEnqueueIfAccepted,
writeOrEnqueueIfAccepted) is checked on the engine, serialized
against rebinds by construction; only physical admission
(updateValue/write/backpressure) runs on bleQueue.
- Teardown splits into discardPeripheralLinkPhysical (bleQueue, inline
in the delegates) + retirePeripheralLinkIdentity (engine hop with
survivor repair reading liveness via readLinkState). A binding can
briefly outlive its physical link; liveness queries join against the
physical store and the queued retirement converges the two.
- Gossip delegate sends enter the engine via onEngine — safe because
mesh.sync sits above the engine in the sync order (production engine
code only async-dispatches into the manager).
- checkPeerConnectivity rides an engine slot from the bleQueue
maintenance tick.
No wire changes. 1,974 tests green (parallel and serial), iOS
simulator build clean, Periphery clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Link layer slice 4: deterministic multi-node mesh simulation — and the panic-announce bug it caught
SimulatedMesh wires real CoreBluetooth-free BLEService engines
edge-to-edge through the outbound packet tap and _test_ingestFrame
(the production attribution path the B2 flip created), with per-edge
synthetic link IDs and manual-scheduler time. Five multi-node tests
run in ~40ms with no wall-clock waits:
- announce exchange binds simulated links and connects peers
- Noise sessions establish end-to-end (real crypto, both directions)
- a public message relays across a line topology inside a TTL/frame
budget (storm bound asserted)
- an 8x duplicate flood delivers exactly once
- a panic rotation rebinds the survivor's link exactly once and stays
— the scenario that previously needed two phones and log archaeology
Fidelity boundary (documented in the harness): no physical links, so
fanout planning and backpressure are not exercised; attribution,
binding, dedup, TTL, relay decisions, and sessions are the real
engine code.
The simulator found a real bug on its first run: the forced-announce
throttle's lastSent survived a panic, so a rotation within
bleForceAnnounceMinIntervalSeconds of the last announce silently
swallowed the new identity's announce — leaving it invisible to the
mesh until the next maintenance cycle. Today's device test only
passed because the previous announce happened to be minutes old.
BLEAnnounceThrottle gains reset(), called from the panic slot so the
rotated identity owes no throttle debt; pinned by a unit test and the
mesh rotation test.
New DEBUG seams: _test_ingestFrame (production ingress attribution),
_test_forceAnnounce, _test_fenceEngine.
1,980 tests green, Periphery clean, iOS simulator build clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Link layer slice 5: name the port — BLELinkEvent, one engine entry, delegates in their own files
The upward half of the link-layer port is now a type. BLELinkEvent
enumerates everything the bleQueue link layer tells the engine:
frameDecoded plus the four physical lifecycle transitions
(peripheralLinkEnded, centralLinkEnded, allPeripheralLinksEnded,
allCentralLinksEnded). Every bleQueue→engine crossing goes through
emitLinkEvent into one engine consumer (handleLinkEvent) — the
scattered messageQueue.async identity hops in the delegates collapse
into event emission, and the engine-side retirement/bookkeeping logic
now lives in one switch.
The CoreBluetooth delegate extensions move to their own files as
physical bookkeeping plus event emission:
- BLEService+LinkLayerCentralRole.swift (CBCentralManagerDelegate +
CBPeripheralDelegate)
- BLEService+LinkLayerPeripheralRole.swift (CBPeripheralManagerDelegate
+ write accumulation)
BLEService.swift drops from 7,836 to ~7,100 lines. The physical-domain
members the role files share flip private→internal; the queue contract
is enforced by the existing DEBUG traps and grep guards, not access
control. (Two of the flips — isAppActive, logBluetoothStatus — only
surfaced on the iOS build; macOS SwiftPM cannot see #if os(iOS) code.
Verified with a local iOS simulator build.)
The simulated mesh now drives lifecycle events through the identical
enum a radio does: linkDropEventRetiresBindingAndReconnectHeals covers
drop → identity retirement → last-link peer bookkeeping → re-announce
heal, entirely through the port. New seam _test_resetAnnounceThrottle
models elapsed wall-clock for the throttle (deliberately separate from
_test_forceAnnounce so the panic-rotation test keeps its regression
value: the production panic path must do its own reset). The panic
test's containment re-announces reset throttles explicitly so those
assertions exercise real delivered announces instead of silently
throttled ones. noiseSessionEstablishesEndToEnd gains a bounded
scheduler-time settle loop after a one-in-many parallel-suite flake
(no wall-clock waits).
Deliberately not done (recorded in docs/BLE-ARCHITECTURE-V3.md): a
formal handle(event)->[Effect] system and further engine-domain file
splits — both would flip the engine's private state to internal for
cosmetic file counts; the effect formalization rides future feature-
module extractions instead.
1,981 tests green, Periphery clean, iOS simulator build clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Baseline logBluetoothStatus for the macOS Periphery scan
Its callers are all inside #if os(iOS) (willRestoreState in both role
files plus the app-state handlers), so the macOS-scheme scan sees the
now-internal declaration with zero callers — the same class as the
baselined candidateCount. Verified 1-USR diff; the previously private
mangled variant was already baselined, which is why the pre-split scan
never flagged it.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix#1538: release stale bindings on rotation instead of leaving a ghost
With two live links to one phone, a panic rotation healed only the link
the verified announce arrived on. The second link kept its binding to
the retired identity, so that dead ID stayed in the peer list — and was
kept alive by the NEW identity's own traffic, since a bound link
attributes non-announce frames to its bound peer. It only healed when
the stale link physically dropped.
The issue proposed exempting the containment rule via retiredBy[X] = Y
so the second link could rebind. Two problems: the exemption's stated
precondition (X removed by retireRotatedPeer) can never hold in this
scenario — the retire is gated on X having no remaining links, which is
false precisely because the stale link exists — and it would loosen a
security rule to fix a liveness bug.
Instead the rotation now RELEASES every link still bound to the
rotated-away identity (unbind + retire that link's Noise proof) and
retires the identity. No containment rule changes: unbinding is
strictly less trusting than any binding, and it is correct under both
readings of a second link bound to the retired ID — same physical
device (the field case), or one link is a spoofer holding a forged
binding, since a peer ID is a Noise-key fingerprint and two devices
cannot both legitimately own it. Released links reconverge through the
ordinary unbound-link path: the next raw direct announce binds them to
whoever they actually carry.
Reproduced and fixed under the slice-4 simulator, which is why this
lands as tests rather than another two-phone session:
- duplicateLinkPanicRotationLeavesNoGhostAndHealsBothLinks fails
without the fix (ghost in both knownPeers and getConnectedPeers,
duplicate link still bound to the dead ID)
- replayedVerifiedAnnounceCannotStealALinkOrEvictTheVictim pins the
#1401 containment rule against exactly the attack this fix had to
avoid re-opening, with a positive control proving the refusal is the
containment check and not duplicate suppression
Harness gains connectDuplicateLinks (two links to one peer, modelled in
the central role — the links we cannot cancel, and the only role whose
bindings a CB-free harness can form), silence (range loss without a
link event, so a packet can be captured that the far side never saw),
and emittedPackets (the attacker's capture buffer).
Residual, documented at the fix: an attacker who binds their own link
to X by replaying X's raw announce can drive a rebind there and so
evict X's registry entry; X's next announce restores it, and the
per-link rebind cooldown bounds the rate. This is the same class of
capability the containment already accepts, not a new one.
1,983 tests green, Periphery clean, iOS simulator build clean.
Closes#1538
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>
* Cohere per-link Noise auth and rebind containment into BLELinkAuthState
The authenticated-link owners, the reconnect revalidation policy, and
the two rebind-containment cooldowns were four loose bleQueue-owned
maps whose invariants lived in call-site discipline: every teardown
path had to remember to retire the proof AND close the revalidation
epoch (the pair appeared seven times), and both cooldowns hand-rolled
the same prune-check-record dance. BLELinkAuthState owns them as whole
transitions — retireLink, retireLinks(ownedBy:), permitRebind,
permitRedundantRetirement — with the ownership question (bleQueue
today, engine after the option-B flip) answered in one place.
No behavior change; the one call-site reordering (redundant retirement
computes the survivor before the cooldown check instead of after) is
outcome-equivalent since the cooldown only ever recorded when a
survivor existed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Split identity-link bindings out of the physical link store
BLELinkStateStore owned two different kinds of truth: what physical
links exist (CB handles, connect lifecycles, characteristics, stream
assemblers) and who each link belongs to (peer bindings in both roles
plus the preferred-peripheral reverse map for directed sends and fanout
collapse). The bindings now live on BLELinkBindings — same bleQueue
ownership, whole-transition methods, direct tests for the rotation
reverse-map cleanup and the preferred-link survivor repair that were
previously only exercised end to end. Composed operations that need
both truths (remove-with-repair, direct link state, the subscribed-
central snapshot, bind-only-live-links) live on the transport as
explicitly bleQueue-confined helpers.
This is the structural half of the option-B boundary flip
(docs/BLE-ARCHITECTURE-V3.md): ownership of the bindings can now move
to the engine without touching what-links-exist. An audit of every
physical clear/remove found three sites (emergency clear, both
unauthorized branches) that needed explicit binding-clear pairing under
the split — each now clears both.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix iOS-gated constructors and preserve containment cooldowns on reset
CI caught what the macOS SwiftPM build cannot see: two #if os(iOS)
sites still passed the peerID field that slice B1 removed from
BLEPeripheralLinkState (willRestoreState in BLEService and
armPendingBackgroundConnects in BLERadioController). Both fixed and
verified with a local iOS simulator xcodebuild.
Codex also caught a real regression: BLELinkAuthState.removeAll()
cleared the rebind/retirement cooldown maps, which the original panic
and emergency reset paths deliberately left alive. A stable
CoreBluetooth UUID must not earn a fresh rebind allowance just because
the session state around it was wiped. removeAll() now clears only the
proofs and revalidation epochs, and BLELinkAuthStateTests pins the
survival invariant along with the other auth-state transitions.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Link layer slice 3: the option-B domain flip — bindings and link-auth move to the engine
The identity domain (BLELinkBindings + BLELinkAuthState) is now owned
by the engine queue, with a DEBUG dispatchPrecondition trapping any
access from another queue. bleQueue keeps only physical link state.
What changed shape:
- Receive path is sans-I/O: bleQueue decodes frames and hands
(packet, linkID) up through ingestDecodedPacket (panic lifecycle
captured at the handoff); attributeAndHandlePacket resolves the
sender binding, rejects spoofed senders, applies raw-announce
binding, and records ingress on the engine. Per-link frame order is
preserved end to end (both queues serial), which supersedes the old
batch-local TOCTOU binding in the notification path.
- The rotation rebind is one engine slot: containment checks, proof
retirement, binding flip, reconnect decision, and rotated-identity
retirement run straight-line; only CoreBluetooth cancels hop to
bleQueue. The engine->bleQueue->engine ping-pong is gone, along with
the _test_afterVerifiedDirectRebindEnqueued pause hook — the test
that used it now asserts the atomicity directly (a paused engine
wedged the old gate design into a three-queue deadlock).
- Authenticated-send eligibility (notifyOrEnqueueIfAccepted,
writeOrEnqueueIfAccepted) is checked on the engine, serialized
against rebinds by construction; only physical admission
(updateValue/write/backpressure) runs on bleQueue.
- Teardown splits into discardPeripheralLinkPhysical (bleQueue, inline
in the delegates) + retirePeripheralLinkIdentity (engine hop with
survivor repair reading liveness via readLinkState). A binding can
briefly outlive its physical link; liveness queries join against the
physical store and the queued retirement converges the two.
- Gossip delegate sends enter the engine via onEngine — safe because
mesh.sync sits above the engine in the sync order (production engine
code only async-dispatches into the manager).
- checkPeerConnectivity rides an engine slot from the bleQueue
maintenance tick.
No wire changes. 1,974 tests green (parallel and serial), iOS
simulator build clean, Periphery clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Link layer slice 4: deterministic multi-node mesh simulation — and the panic-announce bug it caught
SimulatedMesh wires real CoreBluetooth-free BLEService engines
edge-to-edge through the outbound packet tap and _test_ingestFrame
(the production attribution path the B2 flip created), with per-edge
synthetic link IDs and manual-scheduler time. Five multi-node tests
run in ~40ms with no wall-clock waits:
- announce exchange binds simulated links and connects peers
- Noise sessions establish end-to-end (real crypto, both directions)
- a public message relays across a line topology inside a TTL/frame
budget (storm bound asserted)
- an 8x duplicate flood delivers exactly once
- a panic rotation rebinds the survivor's link exactly once and stays
— the scenario that previously needed two phones and log archaeology
Fidelity boundary (documented in the harness): no physical links, so
fanout planning and backpressure are not exercised; attribution,
binding, dedup, TTL, relay decisions, and sessions are the real
engine code.
The simulator found a real bug on its first run: the forced-announce
throttle's lastSent survived a panic, so a rotation within
bleForceAnnounceMinIntervalSeconds of the last announce silently
swallowed the new identity's announce — leaving it invisible to the
mesh until the next maintenance cycle. Today's device test only
passed because the previous announce happened to be minutes old.
BLEAnnounceThrottle gains reset(), called from the panic slot so the
rotated identity owes no throttle debt; pinned by a unit test and the
mesh rotation test.
New DEBUG seams: _test_ingestFrame (production ingress attribution),
_test_forceAnnounce, _test_fenceEngine.
1,980 tests green, Periphery clean, iOS simulator build clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Link layer slice 5: name the port — BLELinkEvent, one engine entry, delegates in their own files
The upward half of the link-layer port is now a type. BLELinkEvent
enumerates everything the bleQueue link layer tells the engine:
frameDecoded plus the four physical lifecycle transitions
(peripheralLinkEnded, centralLinkEnded, allPeripheralLinksEnded,
allCentralLinksEnded). Every bleQueue→engine crossing goes through
emitLinkEvent into one engine consumer (handleLinkEvent) — the
scattered messageQueue.async identity hops in the delegates collapse
into event emission, and the engine-side retirement/bookkeeping logic
now lives in one switch.
The CoreBluetooth delegate extensions move to their own files as
physical bookkeeping plus event emission:
- BLEService+LinkLayerCentralRole.swift (CBCentralManagerDelegate +
CBPeripheralDelegate)
- BLEService+LinkLayerPeripheralRole.swift (CBPeripheralManagerDelegate
+ write accumulation)
BLEService.swift drops from 7,836 to ~7,100 lines. The physical-domain
members the role files share flip private→internal; the queue contract
is enforced by the existing DEBUG traps and grep guards, not access
control. (Two of the flips — isAppActive, logBluetoothStatus — only
surfaced on the iOS build; macOS SwiftPM cannot see #if os(iOS) code.
Verified with a local iOS simulator build.)
The simulated mesh now drives lifecycle events through the identical
enum a radio does: linkDropEventRetiresBindingAndReconnectHeals covers
drop → identity retirement → last-link peer bookkeeping → re-announce
heal, entirely through the port. New seam _test_resetAnnounceThrottle
models elapsed wall-clock for the throttle (deliberately separate from
_test_forceAnnounce so the panic-rotation test keeps its regression
value: the production panic path must do its own reset). The panic
test's containment re-announces reset throttles explicitly so those
assertions exercise real delivered announces instead of silently
throttled ones. noiseSessionEstablishesEndToEnd gains a bounded
scheduler-time settle loop after a one-in-many parallel-suite flake
(no wall-clock waits).
Deliberately not done (recorded in docs/BLE-ARCHITECTURE-V3.md): a
formal handle(event)->[Effect] system and further engine-domain file
splits — both would flip the engine's private state to internal for
cosmetic file counts; the effect formalization rides future feature-
module extractions instead.
1,981 tests green, Periphery clean, iOS simulator build clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Baseline logBluetoothStatus for the macOS Periphery scan
Its callers are all inside #if os(iOS) (willRestoreState in both role
files plus the app-state handlers), so the macOS-scheme scan sees the
now-internal declaration with zero callers — the same class as the
baselined candidateCount. Verified 1-USR diff; the previously private
mangled variant was already baselined, which is why the pre-split scan
never flagged 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>
* Cohere per-link Noise auth and rebind containment into BLELinkAuthState
The authenticated-link owners, the reconnect revalidation policy, and
the two rebind-containment cooldowns were four loose bleQueue-owned
maps whose invariants lived in call-site discipline: every teardown
path had to remember to retire the proof AND close the revalidation
epoch (the pair appeared seven times), and both cooldowns hand-rolled
the same prune-check-record dance. BLELinkAuthState owns them as whole
transitions — retireLink, retireLinks(ownedBy:), permitRebind,
permitRedundantRetirement — with the ownership question (bleQueue
today, engine after the option-B flip) answered in one place.
No behavior change; the one call-site reordering (redundant retirement
computes the survivor before the cooldown check instead of after) is
outcome-equivalent since the cooldown only ever recorded when a
survivor existed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Split identity-link bindings out of the physical link store
BLELinkStateStore owned two different kinds of truth: what physical
links exist (CB handles, connect lifecycles, characteristics, stream
assemblers) and who each link belongs to (peer bindings in both roles
plus the preferred-peripheral reverse map for directed sends and fanout
collapse). The bindings now live on BLELinkBindings — same bleQueue
ownership, whole-transition methods, direct tests for the rotation
reverse-map cleanup and the preferred-link survivor repair that were
previously only exercised end to end. Composed operations that need
both truths (remove-with-repair, direct link state, the subscribed-
central snapshot, bind-only-live-links) live on the transport as
explicitly bleQueue-confined helpers.
This is the structural half of the option-B boundary flip
(docs/BLE-ARCHITECTURE-V3.md): ownership of the bindings can now move
to the engine without touching what-links-exist. An audit of every
physical clear/remove found three sites (emergency clear, both
unauthorized branches) that needed explicit binding-clear pairing under
the split — each now clears both.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix iOS-gated constructors and preserve containment cooldowns on reset
CI caught what the macOS SwiftPM build cannot see: two #if os(iOS)
sites still passed the peerID field that slice B1 removed from
BLEPeripheralLinkState (willRestoreState in BLEService and
armPendingBackgroundConnects in BLERadioController). Both fixed and
verified with a local iOS simulator xcodebuild.
Codex also caught a real regression: BLELinkAuthState.removeAll()
cleared the rebind/retirement cooldown maps, which the original panic
and emergency reset paths deliberately left alive. A stable
CoreBluetooth UUID must not earn a fresh rebind allowance just because
the session state around it was wiped. removeAll() now clears only the
proofs and revalidation epochs, and BLELinkAuthStateTests pins the
survival invariant along with the other auth-state transitions.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Link layer slice 3: the option-B domain flip — bindings and link-auth move to the engine
The identity domain (BLELinkBindings + BLELinkAuthState) is now owned
by the engine queue, with a DEBUG dispatchPrecondition trapping any
access from another queue. bleQueue keeps only physical link state.
What changed shape:
- Receive path is sans-I/O: bleQueue decodes frames and hands
(packet, linkID) up through ingestDecodedPacket (panic lifecycle
captured at the handoff); attributeAndHandlePacket resolves the
sender binding, rejects spoofed senders, applies raw-announce
binding, and records ingress on the engine. Per-link frame order is
preserved end to end (both queues serial), which supersedes the old
batch-local TOCTOU binding in the notification path.
- The rotation rebind is one engine slot: containment checks, proof
retirement, binding flip, reconnect decision, and rotated-identity
retirement run straight-line; only CoreBluetooth cancels hop to
bleQueue. The engine->bleQueue->engine ping-pong is gone, along with
the _test_afterVerifiedDirectRebindEnqueued pause hook — the test
that used it now asserts the atomicity directly (a paused engine
wedged the old gate design into a three-queue deadlock).
- Authenticated-send eligibility (notifyOrEnqueueIfAccepted,
writeOrEnqueueIfAccepted) is checked on the engine, serialized
against rebinds by construction; only physical admission
(updateValue/write/backpressure) runs on bleQueue.
- Teardown splits into discardPeripheralLinkPhysical (bleQueue, inline
in the delegates) + retirePeripheralLinkIdentity (engine hop with
survivor repair reading liveness via readLinkState). A binding can
briefly outlive its physical link; liveness queries join against the
physical store and the queued retirement converges the two.
- Gossip delegate sends enter the engine via onEngine — safe because
mesh.sync sits above the engine in the sync order (production engine
code only async-dispatches into the manager).
- checkPeerConnectivity rides an engine slot from the bleQueue
maintenance tick.
No wire changes. 1,974 tests green (parallel and serial), iOS
simulator build clean, Periphery clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Link layer slice 4: deterministic multi-node mesh simulation — and the panic-announce bug it caught
SimulatedMesh wires real CoreBluetooth-free BLEService engines
edge-to-edge through the outbound packet tap and _test_ingestFrame
(the production attribution path the B2 flip created), with per-edge
synthetic link IDs and manual-scheduler time. Five multi-node tests
run in ~40ms with no wall-clock waits:
- announce exchange binds simulated links and connects peers
- Noise sessions establish end-to-end (real crypto, both directions)
- a public message relays across a line topology inside a TTL/frame
budget (storm bound asserted)
- an 8x duplicate flood delivers exactly once
- a panic rotation rebinds the survivor's link exactly once and stays
— the scenario that previously needed two phones and log archaeology
Fidelity boundary (documented in the harness): no physical links, so
fanout planning and backpressure are not exercised; attribution,
binding, dedup, TTL, relay decisions, and sessions are the real
engine code.
The simulator found a real bug on its first run: the forced-announce
throttle's lastSent survived a panic, so a rotation within
bleForceAnnounceMinIntervalSeconds of the last announce silently
swallowed the new identity's announce — leaving it invisible to the
mesh until the next maintenance cycle. Today's device test only
passed because the previous announce happened to be minutes old.
BLEAnnounceThrottle gains reset(), called from the panic slot so the
rotated identity owes no throttle debt; pinned by a unit test and the
mesh rotation test.
New DEBUG seams: _test_ingestFrame (production ingress attribution),
_test_forceAnnounce, _test_fenceEngine.
1,980 tests green, Periphery clean, iOS simulator build clean.
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>
* Cohere per-link Noise auth and rebind containment into BLELinkAuthState
The authenticated-link owners, the reconnect revalidation policy, and
the two rebind-containment cooldowns were four loose bleQueue-owned
maps whose invariants lived in call-site discipline: every teardown
path had to remember to retire the proof AND close the revalidation
epoch (the pair appeared seven times), and both cooldowns hand-rolled
the same prune-check-record dance. BLELinkAuthState owns them as whole
transitions — retireLink, retireLinks(ownedBy:), permitRebind,
permitRedundantRetirement — with the ownership question (bleQueue
today, engine after the option-B flip) answered in one place.
No behavior change; the one call-site reordering (redundant retirement
computes the survivor before the cooldown check instead of after) is
outcome-equivalent since the cooldown only ever recorded when a
survivor existed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Split identity-link bindings out of the physical link store
BLELinkStateStore owned two different kinds of truth: what physical
links exist (CB handles, connect lifecycles, characteristics, stream
assemblers) and who each link belongs to (peer bindings in both roles
plus the preferred-peripheral reverse map for directed sends and fanout
collapse). The bindings now live on BLELinkBindings — same bleQueue
ownership, whole-transition methods, direct tests for the rotation
reverse-map cleanup and the preferred-link survivor repair that were
previously only exercised end to end. Composed operations that need
both truths (remove-with-repair, direct link state, the subscribed-
central snapshot, bind-only-live-links) live on the transport as
explicitly bleQueue-confined helpers.
This is the structural half of the option-B boundary flip
(docs/BLE-ARCHITECTURE-V3.md): ownership of the bindings can now move
to the engine without touching what-links-exist. An audit of every
physical clear/remove found three sites (emergency clear, both
unauthorized branches) that needed explicit binding-clear pairing under
the split — each now clears both.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix iOS-gated constructors and preserve containment cooldowns on reset
CI caught what the macOS SwiftPM build cannot see: two #if os(iOS)
sites still passed the peerID field that slice B1 removed from
BLEPeripheralLinkState (willRestoreState in BLEService and
armPendingBackgroundConnects in BLERadioController). Both fixed and
verified with a local iOS simulator xcodebuild.
Codex also caught a real regression: BLELinkAuthState.removeAll()
cleared the rebind/retirement cooldown maps, which the original panic
and emergency reset paths deliberately left alive. A stable
CoreBluetooth UUID must not earn a fresh rebind allowance just because
the session state around it was wiped. removeAll() now clears only the
proofs and revalidation epochs, and BLELinkAuthStateTests pins the
survival invariant along with the other auth-state transitions.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Link layer slice 3: the option-B domain flip — bindings and link-auth move to the engine
The identity domain (BLELinkBindings + BLELinkAuthState) is now owned
by the engine queue, with a DEBUG dispatchPrecondition trapping any
access from another queue. bleQueue keeps only physical link state.
What changed shape:
- Receive path is sans-I/O: bleQueue decodes frames and hands
(packet, linkID) up through ingestDecodedPacket (panic lifecycle
captured at the handoff); attributeAndHandlePacket resolves the
sender binding, rejects spoofed senders, applies raw-announce
binding, and records ingress on the engine. Per-link frame order is
preserved end to end (both queues serial), which supersedes the old
batch-local TOCTOU binding in the notification path.
- The rotation rebind is one engine slot: containment checks, proof
retirement, binding flip, reconnect decision, and rotated-identity
retirement run straight-line; only CoreBluetooth cancels hop to
bleQueue. The engine->bleQueue->engine ping-pong is gone, along with
the _test_afterVerifiedDirectRebindEnqueued pause hook — the test
that used it now asserts the atomicity directly (a paused engine
wedged the old gate design into a three-queue deadlock).
- Authenticated-send eligibility (notifyOrEnqueueIfAccepted,
writeOrEnqueueIfAccepted) is checked on the engine, serialized
against rebinds by construction; only physical admission
(updateValue/write/backpressure) runs on bleQueue.
- Teardown splits into discardPeripheralLinkPhysical (bleQueue, inline
in the delegates) + retirePeripheralLinkIdentity (engine hop with
survivor repair reading liveness via readLinkState). A binding can
briefly outlive its physical link; liveness queries join against the
physical store and the queued retirement converges the two.
- Gossip delegate sends enter the engine via onEngine — safe because
mesh.sync sits above the engine in the sync order (production engine
code only async-dispatches into the manager).
- checkPeerConnectivity rides an engine slot from the bleQueue
maintenance tick.
No wire changes. 1,974 tests green (parallel and serial), iOS
simulator build clean, Periphery clean.
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>
* Cohere per-link Noise auth and rebind containment into BLELinkAuthState
The authenticated-link owners, the reconnect revalidation policy, and
the two rebind-containment cooldowns were four loose bleQueue-owned
maps whose invariants lived in call-site discipline: every teardown
path had to remember to retire the proof AND close the revalidation
epoch (the pair appeared seven times), and both cooldowns hand-rolled
the same prune-check-record dance. BLELinkAuthState owns them as whole
transitions — retireLink, retireLinks(ownedBy:), permitRebind,
permitRedundantRetirement — with the ownership question (bleQueue
today, engine after the option-B flip) answered in one place.
No behavior change; the one call-site reordering (redundant retirement
computes the survivor before the cooldown check instead of after) is
outcome-equivalent since the cooldown only ever recorded when a
survivor existed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Split identity-link bindings out of the physical link store
BLELinkStateStore owned two different kinds of truth: what physical
links exist (CB handles, connect lifecycles, characteristics, stream
assemblers) and who each link belongs to (peer bindings in both roles
plus the preferred-peripheral reverse map for directed sends and fanout
collapse). The bindings now live on BLELinkBindings — same bleQueue
ownership, whole-transition methods, direct tests for the rotation
reverse-map cleanup and the preferred-link survivor repair that were
previously only exercised end to end. Composed operations that need
both truths (remove-with-repair, direct link state, the subscribed-
central snapshot, bind-only-live-links) live on the transport as
explicitly bleQueue-confined helpers.
This is the structural half of the option-B boundary flip
(docs/BLE-ARCHITECTURE-V3.md): ownership of the bindings can now move
to the engine without touching what-links-exist. An audit of every
physical clear/remove found three sites (emergency clear, both
unauthorized branches) that needed explicit binding-clear pairing under
the split — each now clears both.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix iOS-gated constructors and preserve containment cooldowns on reset
CI caught what the macOS SwiftPM build cannot see: two #if os(iOS)
sites still passed the peerID field that slice B1 removed from
BLEPeripheralLinkState (willRestoreState in BLEService and
armPendingBackgroundConnects in BLERadioController). Both fixed and
verified with a local iOS simulator xcodebuild.
Codex also caught a real regression: BLELinkAuthState.removeAll()
cleared the rebind/retirement cooldown maps, which the original panic
and emergency reset paths deliberately left alive. A stable
CoreBluetooth UUID must not earn a fresh rebind allowance just because
the session state around it was wiped. removeAll() now clears only the
proofs and revalidation epochs, and BLELinkAuthStateTests pins the
survival invariant along with the other auth-state transitions.
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>
First slice of the link layer: discovery admission, the connection
budget and queue, connect timeouts, wake-on-proximity background
connects, scan duty-cycling, RSSI adaptation, and the advertising
payload move out of BLEService into a bleQueue-confined controller
(~400 lines). It makes no peer decisions and owns no bindings or
security state: it shares the bleQueue-confined link-state store for
admission reads, and when a connect attempt dies it asks its delegate
to retire the transport bookkeeping — which also factors the
four-times-repeated teardown sequence (write backpressure, link-auth
proof, reconnect epoch, link-state entry) into one
tearDownPeripheralLink helper.
The three-method delegate (panic suspended, app active, tear down) is
the radio's entire dependency on the transport; the CoreBluetooth
delegate methods in BLEService shrink toward pure event forwarding
ahead of the LinkEvent/LinkCommand port.
candidateCount joins the Periphery baseline like the rest of the
status-capture path: its only callers are iOS-gated, invisible to the
macOS scheme scan.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
SwiftUI invokes an alert Binding's setter inside the current view
update when the alert dismisses because its get re-evaluated (a
scenePhase change while the Bluetooth-off or voice-error alert is up).
Both root alert bindings wrote their @Published backing state
synchronously from that setter — the 'Publishing changes from within
view updates is not allowed' undefined-behavior warning, reproduced on
device by launching with Bluetooth off and backgrounding. Defer the
write one main-actor hop.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Make peer registry and local announce state lock-backed
The main actor answered isPeerConnected/peerNickname/currentPeerSnapshots
and flipped runtime capability bits by blocking on collectionsQueue behind
whatever transport work was in flight. Peer state now lives in a
lock-backed BLEPeerRegistryStore (every registry mutation is a single
whole-transition method, so readers never observe a torn state), and the
runtime capability bits move into BLELocalIdentityStateStore next to the
identity they ride announces with. No transport entry point called from
the main actor blocks on a transport queue for peer state anymore.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Move BLE link egress/ingress buffers to bleQueue ownership
pendingPeripheralWrites, pendingNotifications, and pendingWriteBuffers
were collectionsQueue-guarded, but every producer and drain already runs
on bleQueue next to the CoreBluetooth objects they feed — each access
paid a cross-queue barrier for state that never leaves the radio thread,
and the notification drain even invoked peripheralManager.updateValue
from the collections queue. They are now bleQueue-confined like the link
state store: CB delegate callbacks and drains touch them directly, and
the few engine-side entry points hop to bleQueue (the direction the
transport's sync-edge order already allows). This clears most
bleQueue-to-collectionsQueue sync edges ahead of merging the collections
queue into the message queue.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Stop bleQueue maintenance and status paths from blocking on collectionsQueue
The traffic-burst tracker becomes a lock-backed monitor (written by the
receive pipeline, read by scan-duty adaptation and announce pacing on
bleQueue), the status-log peer summary and topology refresh read the
already lock-backed registry directly, and the stalled-fragment reap
moves to an async collections hop with the gossip resync request inside
it. bleQueue no longer sync-waits on the collections queue anywhere.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Unify the message and collections queues into one serial engine queue
The old model ran a concurrent message queue over a second concurrent
collections queue whose barrier flags served as the real mutual
exclusion — every field carried an ownership comment, and correctness
lived in per-site discipline. The message queue is now a single serial
engine queue that owns all mesh protocol state; the collections queue,
its 98 sync/async hops, and every barrier flag are gone. Cross-thread
callers go through onEngine, which documents and (in debug) enforces
the transport's sync-edge order: main and test threads may block on the
engine, the engine may block on bleQueue and the crypto/identity
queues, and nothing may block the other way.
The debug trap caught two latent inversions the leaf-lock structure had
been masking: the verified-announce rebind path re-resolved the ingress
link through the engine from inside its bleQueue critical section (it
now receives the already-resolved link), and the noise
session-generation closures sync-re-entered the engine from the noise
manager's queue while their own engine slot was blocked on it (they now
touch engine state directly, which the held slot makes exclusive).
BLE throughput is orders of magnitude below what one serial queue
sustains; the full suite runs at identical speed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Wire gateway/bridge/panic features to capability ports, not BLEService
App wiring discovered mesh-only features by casting the Transport to
the concrete BLEService class in nine places. Those surfaces are now
three capability protocols — BluetoothStateReporting,
PanicResettingTransport, and MeshBridgingTransport — discovered with
as? like any optional capability, so the bootstrapper, panic flow, and
lifecycle coordinator no longer name the concrete transport at all. A
future second mesh transport picks up gateway/bridge wiring and the
panic lifecycle by conforming, and the remaining Transport god-protocol
requirements can migrate to the same pattern.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Extract mesh-ping diagnostics state into a pure engine-confined tracker
First slice of the feature-module direction: BLEMeshPingTracker owns the
outstanding-probe map and the per-link inbound response budget as pure
state (register/resolve/expire/reset), so the security invariants — a
pong only resolves against the probed peer, the budget keys on the
ingress link because claimed senders are forgeable, panic reset drops
probes and budget together — are now unit-tested without queues or
radios. The transport keeps only packet I/O, timers, and main-actor
delivery around it.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Document the V3 transport architecture and remaining roadmap
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Resolve the pass-6 review findings and the proof-timeout drain defect
Periphery: the registry store's unused forwarders are gone (the struct
method stays — it has direct tests). F1: refreshPeerIdentity,
deliverBridgedEnvelope, and the three panic fences route through
onEngine, so every sync entry onto the engine now carries the bleQueue
trap. F2: the registry-store ownership comments state the real writer
set (engine plus the two bleQueue link-drop paths). F7:
BLEQueueContractTests pins the contract — only onEngine may sync-enter
the engine, transport code never sync-dispatches to main, and the
collections queue stays deleted — with a queue-contract-ok waiver for
the two sanctioned lines.
The real defect behind the timeoutRestoredSession CI flake: a
timeout-restore parks the outbound queues until the convergence retry,
but the capability-proof watchdog armed at the original authentication
kept draining them when it fired — encrypting the parked traffic under
restored keys the counterpart may have discarded, the exact silent loss
the defer path exists to prevent. Deferred peers are now tracked and
the watchdog drain respects the same rule; the test fires the watchdog
deterministically inside the deferred window instead of losing that
race only on stalled runners.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Extract private-media session state into a lock-backed store
The six generation-keyed maps plus the convergence-deferral set move
out of BLEService into BLEPrivateMediaSessionStore, each transition one
whole method under a leaf lock with direct unit tests (generation
rotation rejects mismatched waiters, stale proofs cannot classify a
replacement session, expiry requires the live deadline identity, clears
rebase waiters onto a nil-generation deadline, peer-state sends are
once per generation per kind).
Being a leaf lock also simplifies two contracts: the send policy is now
answered entirely from locks (the main actor no longer sync-enters the
engine for it), and the noise-manager critical sections call ordinary
store methods instead of relying on the held-engine-slot direct-access
subtlety.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Split the mesh-only Transport surface into capability protocols
Transport kept ~50 requirements that only the BLE mesh implements —
files/private media, voice, courier, groups, board, diagnostics,
verification, archive — held together by an extension of inert
defaults, so every call site compiled against a surface most transports
faked. Those are now eight capability protocols (MeshFileTransferring,
MeshVoiceStreaming, MeshCourierTransporting, MeshGroupMessaging,
MeshBoardBroadcasting, MeshDiagnosing, MeshVerifying,
MeshPublicArchiving) discovered with as?, joining the bridging/panic
ports from the previous pass. Consumers resolve the capability they
need; where the old defaults encoded a safe floor the caller keeps it
explicitly (private-media policy degrades to blockedDowngrade). The
inert-defaults extension is deleted, along with the never-implemented
acceptPendingFile/declinePendingFile pair. NostrTransport is untouched
— it only ever implemented the core.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Update the V3 doc for the completed feature-peeling and Transport split
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Drop the dead three-argument sendFilePrivate overload
Every production caller goes through the allowLegacyFallback variant;
the short form only existed as a Transport-era forwarding default.
Tests that used it on the concrete service now state the fallback
decision explicitly, which is the point of the parameter.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Decide the link-auth boundary: bindings become engine-owned
The atomicity that keeps link-auth on bleQueue exists to stop a binding
from changing between a security check and its action; once every
rebind is an engine operation, the engine's serial slot gives the same
guarantee, the stolen-link residual is unchanged (directed payloads are
Noise ciphertext), and the receive path lands in its sans-I/O shape —
the link layer reports bytes-plus-linkID and the engine resolves the
sender. Records the extraction order too: the binding-free radio half
first (after #1521 lands — it collides in the scanPlan region), then
bindings, then the delegates behind the port.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix two bleQueue-to-engine sync edges the queue merge created
The collections-to-engine conversion turned two formerly leaf-lock
sync calls into onEngine calls reachable from bleQueue, where the
debug trap (correctly) aborts: flushDirectedSpool runs from bleQueue
maintenance and now hops to the engine asynchronously, and ingress
recording — which must answer the duplicate gate on bleQueue the
moment a frame decodes — moves to a lock-backed BLEIngressLinkStore
read by the engine's relay and routing decisions.
Unit suites never hit either path (no CoreBluetooth managers means no
maintenance timer and no live receive path); the iOS simulator job
boots the real app as its test host, which is exactly where the
maintenance trap fired. The ingress one would have trapped a real
device on its first received packet — worth a device pass before
release.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Route all deferred engine work through an injectable scheduler
Relay jitter, announce delays, the ping and capability-proof deadlines,
notification retry backoff, and fragment pacing all reached the engine
through raw messageQueue.asyncAfter with product constants as deadlines
— the hidden-elapsed-deadline flake class that the test-timing hygiene
rules exist to contain, testable only by racing the wall clock.
BLEEngineScheduling is now the transport's single source of engine
delay: production is a thin veneer over the engine queue, tests inject
a manually advanced clock whose advance() returns only after the
released work has finished on the engine. The queue-contract test pins
the seam (no raw messageQueue.asyncAfter), and the ping deadline gets
the pattern's proof: the real 10s constant asserted in milliseconds —
must not fire early, fires exactly once at the deadline, stays consumed
after.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Assert the armed deadline count in the injected-clock ping test
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>
* Deflake two iOS-sim CI tests with unbounded timing assumptions
Both failed on main-adjacent CI runs during this session's PRs. Neither
was a product bug; both asserted things about real time that a loaded
runner is under no obligation to honour.
**NetworkReachabilityGateTests: a wall-clock upper bound.**
test_monitor_duplicateUpdatesDoNotPostponeOfflineCommit slept 500ms for
real, then asserted total elapsed time was under 1.4s to prove a duplicate
mid-window had not restarted the 1.0s debounce. One CI run took 3.75s. No
wall-clock bound can separate "deadline preserved" from "runner is slow",
because Task.sleep and the asyncAfter flush are both real time and neither
is bounded above.
The deadline property was already covered deterministically one level
down: test_debounce_duplicateObservationsPreservePendingDeadline drives
ReachabilityDebounce with injected timestamps and checks pendingRemaining
directly. So the monitor test now asserts only what needs a real monitor —
that a duplicate still yields exactly one committed false through the
debounce — with an injected clock for the arithmetic and a generous
liveness budget. Renamed to say what it actually checks. No coverage lost,
and it runs in 0.14s instead of ~3.8s because the real sleep is gone.
**NoiseEncryptionServiceTests: injected timeouts that also arm during
setup.** #1483 diagnosed and fixed exactly this in the quarantine-restore
test, but two sibling tests kept the shape. Their injected
ordinaryResponderHandshakeTimeout (0.04 and 0.06) also arms during the
establishSessions setup handshake, where bob is the responder — so a
preempted runner fires it mid-setup, tears down the half-open responder,
and message 3 gets answered as a fresh initiation. The CI failure named
setup's own `#expect(finalMessage == nil)` seeing a 96-byte message 2,
which is precisely the signature #1483 recorded.
Raised both to 1.0s, matching #1483's remedy: the scenarios still need the
responder timeout to fire, and it still does, just with room for setup to
complete first. Thin 1-second waitUntil budgets in the file now use the
shared TestConstants.longTimeout; every one of them backs a positive
assertion, so waitUntil still returns the moment the condition holds and
nothing gets slower in the passing case.
No assertion weakened in either file. Verified 3x sequentially and 3x with
all 18 cores saturated.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* Raise two more starvation-prone test deadlines
Both surfaced on the CI runs for this PR and #1487, both in tests neither
PR touches, both the same shape as the two already fixed here: a deadline
sized for the work rather than for a runner executing many suites at once.
VoiceNotePlaybackControllerTests waited 5s for a @MainActor Task that
playback schedules for the session acquire and its failure path. When that
Task is not scheduled in time the helper reports *two* failures — the wait,
and the `!isPlaying` the un-run failure path has not reset yet — which
reads like a playback bug rather than a starved scheduler. That is exactly
what CI showed.
GeoRelayDirectoryTests waited 10s for work the directory runs in
Task.detached(priority: .utility); utility priority competes with every
other suite. The retry-scheduling case timed out at exactly 10.06s with the
retry never scheduled, reading like a missing retry rather than a starved
background task.
Raised to 30s each with the reasoning recorded at the helper. Both helpers
return as soon as their condition holds, so nothing slows down when tests
pass — only the genuine-failure case takes longer to report.
Verified 3x with all cores saturated: both suites clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* Make the flake class unrepeatable, not just fixed
Raising four deadlines fixed the four tests that happened to fire. The
class was still there: fourteen separate waitUntil helpers, most defaulting
to 1.0s, plus wait call sites with literal budgets. The fifth instance
would have landed the same way, on someone else's unrelated PR.
The rule, now written down in TestConstants.settleTimeout: **a wait
deadline is not a latency budget.** It exists so a genuine hang eventually
fails the suite, so size it for the worst-case scheduler, never for how
long the operation should take. Waits return as soon as their condition
holds, so a generous deadline is free in the passing case and only extends
genuine failures.
- Every wait helper now defaults to TestConstants.settleTimeout (30s), and
the literal wait call sites below the floor were converted too — sixteen
sites across ten files.
- TestTimingHygieneTests enforces it by scanning the test sources: wait
defaults and wait call sites must be at least minimumSettleTimeout, and
no test may assert an upper bound on elapsed wall-clock time (the
assertion that started this, which cannot separate correct behaviour from
a slow machine).
- Both rules waive per line with "test-timing-ok: <reason>", accepted on
the line or in the comment block above it so the reason has room to be a
sentence. One legitimate use so far: a NEGATIVE wait in NoiseCoverageTests
asserting a promotion has *not* completed within 50ms, where a long
deadline would only make the suite slow while still passing.
Injected production timeouts are deliberately not matched — the Noise
handshake timeouts are the behaviour under test, and short values are
correct there.
Verified the guard actually fails: a canary file with both banned shapes
was flagged with file and line, and the suite went green again once it was
removed. Full suite passes with all 18 cores saturated.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* Close the guard's blind spot: named short timeouts
A fifth flake landed on CI while the first guard was in review —
GossipSyncBoardTests timing out at 1.03s — and the guard did not catch it,
because the deadline was `TestConstants.shortTimeout` rather than a
literal. A literals-only scan cannot see a short value behind a symbol,
which is the more common way it is written: 81 wait sites used
shortTimeout (1s) or defaultTimeout (5s), every one of them below the
floor.
Rather than guess which of those were safe to raise, all 81 were converted
and the suite timed. Runtime went 15s -> 72s, which located the genuine
negative waits precisely: ten tests that assert something does *not*
happen and therefore always run their deadline out. Measurement instead of
a heuristic, since a mis-guess in either direction is invisible — too
short reintroduces the flake, too long silently costs a minute a run.
Those 28 sites now use `TestConstants.negativeWaitWindow`, a named
constant whose doc explains the inverted reasoning: for a negative wait,
starvation can only make the assertion *more* likely to hold, so short is
correct, and the name states the polarity instead of leaving a bare
literal that reads like the mistake. Suite is back to 15.3s.
The guard now also rejects `timeout: TestConstants.shortTimeout` and
`defaultTimeout`, while accepting `negativeWaitWindow` by name.
Re-verified with a canary carrying every banned shape — literal default,
both named constants, and an elapsed-time upper bound. All four were
flagged with file and line; the suite went green again on removal.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* Delete shortTimeout now that nothing may use it
The hygiene guard bans `TestConstants.shortTimeout` at every wait site
and the last users were converted, so Periphery correctly flagged the
constant itself as dead and failed CI. Remove it from both TestConstants
copies; the banned-name entry stays so the symbol cannot quietly return.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* Add a real security policy
Two drive-by template PRs (#1118, #1482) tried to fill this gap with
unedited boilerplate. This is the actual policy: private vulnerability
reporting (now enabled on the repo) as the channel, honest expectations
for a volunteer project, and a scope section that separates the
properties the app promises from the documented design behaviors that
keep getting reported as vulnerabilities.
Closes#1081
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Address Codex review: name the Nostr envelope format precisely
'Gift-wrapped' reads as NIP-59, and the scope section is exactly where
a researcher calibrates expectations. Say what it is: bitchat's own
private-envelope scheme, explicitly not NIP-17/44/59.
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>
* Keep the composer focused after sending with the return key
On iOS, return sends and then drops the keyboard, so every message in a
back-and-forth costs an extra tap to reopen it. sendMessage() is the
onSubmit handler; reasserting the FocusState there keeps the keyboard up
between messages. macOS already refocuses on appear and is unaffected.
Fixes#457
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Address Codex review: refocus only on return-key submission
The reassert moves from sendMessage() into the TextField's onSubmit, so
the send button no longer reopens a deliberately dismissed keyboard on
iOS and never moves focus on macOS.
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 the three follow-ups from the #1486 review
Three defects shipped with the censorship-resilience merge, all
confirmed against main:
1. Source-manifest verification silently accepted added files.
shasum -c checks only the files the manifest lists, and the Xcode
project compiles every source file present in the tree — so a
hostile mirror could pass verification by adding a file rather than
modifying one. The manifest header and VERIFYING-A-BUILD.md now
require the completeness check (git status --porcelain, or a path
diff for tarballs) alongside the hash check.
2. A relay removed while Tor was bootstrapping reconnected anyway.
dropRelays never subtracted from pendingTorConnectionURLs, and a
custom relay passes the allow-list filter, so draining the pending
queue resurrected a relay someone had explicitly deleted.
3. Turning Tor off mid-bootstrap read as 'network may be blocking tor'.
shutdownCompletely left the detached 75s poll loop running, which
then stamped bootstrapDidStall over the clean shutdown state; and
the stall handler guarded on torEnforced, which is compile-time true
in release, instead of the runtime preference. The poll loop is now
generation-fenced (shutdown, dormancy, and restart each invalidate
it) and the handler consults persistedTorPreference().
Both app-side fixes carry regression tests proven to fail pre-fix.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Address Codex review: ignored files and manifest placement
git status --porcelain omits ignored paths, and .gitignore covers
build/ — a planted bitchat/build/Evil.swift would compile via the
synchronized group while the documented check stayed silent. The
checkout check now uses --ignored.
The downloaded manifest also has to live outside the tree, or it trips
the completeness checks itself; the doc now says so and references it
at /tmp throughout.
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>
Tier 3 of a protest-hardening review. The BLE mesh is already properly
fenced off from network reachability and needs nothing here; every gap is
on the internet side, or in how someone gets a build they can trust.
Say when Tor is blocked. The bootstrap poll loop simply ended at its
75-second deadline, leaving isStarting true with no further state, so a
network that blocks Tor was indistinguishable from a slow one and the UI
said "starting tor…" indefinitely. TorManager now exposes
bootstrapDidStall and posts .TorBootstrapDidStall, and the app reports
that mesh messaging still works while internet delivery is paused. It is
cleared on each new start or restart, so a later attempt can report again.
Let relays be added by hand. The four built-in relays are well-known
clearnet hostnames, which is four names for a censor to block and no
recourse short of a new build. NostrRelaySettings persists up to eight
additional relays, normalized, .onion accepted, with a settings editor.
They join the same target set as the built-ins and are subject to the
same activation policy. Removal reconciles against the previous set:
the teardown path iterates the current targets, so without that a removed
relay's socket and queued sends would linger — covered by a test that
fails without it. The merged list is cached rather than recomputed,
because allowedRelayList consults it once per candidate URL and would
otherwise read UserDefaults inside that loop.
Stop stranding people who denied location. The activation gate required
location permission or a mutual favorite, but teleporting into a geohash
requires neither, so someone with no permission and no favorites could
sit in a channel that never connected while Tor and the relays stayed
suppressed and nothing said why. Being in a location channel is now a
third arm of the gate, in both the activation service and the relay
manager's copy of the policy, and leaving the channel closes it again.
Stop burning the Tor timeout when Tor is off. GeoRelayDirectory awaited
Tor readiness unconditionally, but with the preference off TorManager has
been shut down, so every refresh spent the full bootstrap deadline and the
directory froze on its cached copy. It now keys on the preference, not on
live readiness: Tor wanted but unavailable must still skip the fetch
rather than fall back to clearnet.
Say what turning Tor off costs. The toggle's copy described it as
hiding your IP "for location channels", understating both scope and
consequence. It now names private messages too, and while the toggle is
off the settings screen states that every relay can see the device IP.
Make builds verifiable. There was no release verification of any kind:
no signatures, no checksums, no documented procedure. Post-takedown that
is the acute gap, because mirrors appear and people install whatever they
can find during a shutdown. source-manifest.yml publishes a per-tag
SHA-256 manifest with a provenance attestation, self-checking before it
publishes, and docs/VERIFYING-A-BUILD.md explains how to verify source and
states plainly that compiled builds from anywhere but the App Store cannot
be verified. It also records the gaps honestly: no published signing key,
no reproducible build, no non-GitHub mirror.
docs/TOR-INTEGRATION.md was substantially stale — it documented a
torrc, SOCKSPort and ControlPort that the in-process Arti client does not
use, and claimed there are no user-visible settings — so it is rewritten,
including the deferred gap below.
Deferred: no Tor bridges or pluggable transports. arti-client is built
without pt-client or bridge-client and bootstraps from stock config, so
in a country that blocks Tor outright there is still no circumvention
path — only a clear report that there isn't. Closing it needs the Rust
features, bridge config through the FFI, and an xcframework rebuild under
the pinned toolchain with a provenance update, which is its own change.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* Harden what a locked or seized device gives away
The realistic compromise for many of the people this app is built for is
not interception but a phone taken, and often unlocked under coercion.
Content encryption is in good shape; these are the gaps around it.
Hide notification previews, by default. Notification content is rendered
by the system on the lock screen, so it was readable without unlocking:
DM alerts carried the sender's nickname and the full message body, and
geohash alerts put the geohash in the title. Alerts now state that a DM,
mention, or location-channel activity arrived and withhold the rest until
the app is opened. userInfo still carries the routing peer ID and deep
link, neither of which the system displays, so taps land where they did.
A settings toggle restores full previews for anyone who wants them.
Default-on is the deliberate part: a phone face-up on a table should not
narrate conversations, and someone who wants previews can say so.
Cover the window on willResignActive, so the snapshot iOS stores for the
app switcher shows a placeholder rather than an open conversation. Opaque
rather than blurred, because blurred large text stays partly legible and
the snapshot goes to disk. Added synchronously from a UIKit notification
with queue: nil, since the capture follows shortly after and an
OperationQueue hop or a SwiftUI state change can lose that race. Panic
wipe already deleted snapshots already on disk; this stops new ones from
being worth deleting.
Bound media by age as well as size. The 100 MB quota only ever considered
incoming files, so outgoing media had no lifetime at all and a received
photo could outlive its conversation indefinitely. A launch-time sweep now
deletes managed media older than seven days, incoming and outgoing, with
the same exemptions quota eviction honors: in-flight live captures and
files reserved by a delivery or deletion in progress.
Make /clear tell the truth on the mesh timeline. It recorded an echo
watermark and left the gossip archive on disk for up to 6 hours, so
someone who cleared before a police stop had deleted nothing. Clearing now
erases the archive too. The watermark still matters: it suppresses
pre-clear messages this device hears again from peers. The cost is that
the device stops serving recent public backlog until it hears fresh
traffic, which is a fair reading of what clearing a timeline means.
Documented in PRIVACY_POLICY.md and the privacy assessment, including a
new section on what is deliberately NOT addressed: there is still no
duress mechanism of any kind (no decoy passphrase, no wipe-on-failed-auth,
no app lock), macOS gets no file-protection classes, and media is not
sealed at the app layer. The duress question is a product decision as much
as an engineering one, since in some jurisdictions destroying data on
demand is itself an offence and hiding may protect someone better than
destroying, so it is called out rather than guessed at.
Three findings from the audit that prompted this work turned out to be
already fixed on main and are not included: keychain accessibility is
AfterFirstUnlockThisDeviceOnly with a retrying migration, the panic media
wipe uses a two-location durable marker transaction, and panic already
discards staged share-extension content.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* Inject the previews preference instead of reading shared defaults
CI caught a real problem this introduced. `NotificationServiceTests`
already asserted the full-preview title and body, and both it and the new
redaction tests read `NotificationPrivacySettings` from
`UserDefaults.standard` in the same process. Whichever ran second
depended on the other's cleanup, so it passed locally and failed in CI:
XCTAssertEqual failed: ("🔒 new dm") is not equal to ("🔒 DM from Alice")
Fixed at the source rather than by ordering or serialization.
`NotificationService` now takes a `hidePreviewsProvider`, defaulting to
the real preference, so each test states which behavior it asserts. The
pre-existing test asks for previews shown and gains a redacted
counterpart; the redaction tests no longer touch the shared store.
`NotificationPrivacySettings` also gained store-injecting accessors so
the default-value and round-trip assertions can use an isolated suite
rather than mutating preferences other tests read.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* docs: correct inaccurate privacy and metadata claims
Several documented guarantees did not match the implementation. These
matter more than ordinary doc drift: someone deciding whether to carry
this phone to a protest reads these sentences as the threat model.
- Peer IDs were described as "short ephemeral IDs derived per session"
that "rotate periodically" and "prevent tracking". They are the first
8 bytes of the Noise static key fingerprint, stable across sessions
and reboots, and replaced only by a panic wipe. Corrected in the
whitepaper (§3, §8), IdentityModels, and BitchatProtocol, whose
header notes claimed "no persistent identifiers in protocol headers"
while every header carries exactly one.
- "No plaintext message content is ever written to disk" was false for
accepted media, which is stored unsealed under the platform's
data-protection class. Narrowed to what actually holds.
- Padding was described as applying to all packets but fragments. Only
noiseEncrypted and noiseHandshake frames are padded; the pad bytes
equal the pad length rather than being random; and because that
length must fit one byte, a frame needing over 255 bytes of padding
is emitted unpadded. Documented in the whitepaper (§4.1) and
MessagePadding.
- The gossip archive window is 6 hours in production, not the
15 minutes claimed in PRIVACY_POLICY.md and the privacy assessment.
The 15-minute figure is the struct default that BLEService overrides.
- The privacy assessment credited iOS BLE address randomization without
noting that stable app-layer identifiers defeat it.
The whitepaper's future-work list now names the changes these
corrections imply: rotating on-air identity, padding for non-Noise
types, and making the announce neighbor list optional.
No behavior change; comments and documentation only.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs: correct the same claims in the README
The README repeats two of the claims corrected elsewhere in this PR, and
it is the document people actually read before deciding to trust the app.
- "no persistent identifiers" is the inverse of what the mesh does; it
now points at the whitepaper's identity and metadata sections.
- "end-to-end encryption with forward secrecy" holds for live Noise
sessions but not for sealed store-and-forward mail, which the
whitepaper already flags as its main cryptographic trade-off.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Two CI-robustness fixes for the iOS-simulator job seen on main:
1. The destination picker no longer dies on runner images with placeholder/unavailable simulator lists (macos-26-arm64 20260720.0258): it filters error/unavailable rows, falls back to xcrun simctl's available-device list, and as a last resort creates a simulator from the newest installed iOS runtime's own supported iPhone device types. Each path logs which route was taken.
2. Deflakes NoiseEncryptionServiceTests' quarantine-restore test: the injected 20ms responder timeout also armed during the SETUP handshake, so a loaded runner tore down the half-open responder session before the scenario began (production quarantine/restore verified correct — the failure signature was a fresh msg2 to a session-less peer). Timeout raised to 1s and the fixed 100ms sleep replaced with a bounded waitUntil on the restore condition. No assertion weakened; 10/10 sequential + 3/3 under full-core CPU load.
DMs sent through an established Noise session are retained in the durable MessageRouter outbox until an authenticated delivery/read ack, and retried under the same message ID when the peer's replacement handshake authenticates — fixing DMs silently lost into stale local sessions after a remote app restart. Mesh ack handling is peer-scoped end-to-end (alias-scoped delivery status, peer-bound markDelivered, PeerMessageKey retry state), so a colliding message ID from another conversation can no longer clear or promote foreign state; bridge-drop dedup keys are recipient-scoped with hashed persistence.
Includes review fix: acks arriving after a relaunch (durable outbox restored, conversation not) now clear the peer-scoped router entry unconditionally — only the UI status transition is gated on conversation presence — so a delivered message can no longer re-send to the attempt cap and be marked failed despite delivery. Regression test simulates the relaunch through real store persistence; the dead allowedPeerIDs parameter (unscoped-tombstone trap) is removed.
Joins the two authenticated aliases of one account — the full noise-key conversation ID used by the Nostr path and its derived 16-hex mesh short ID — into one canonical conversation, migrating messages and handing off an open DM sheet (short ID while connected, stable ID offline). Delivery/read-ack outbox removal is scoped to the authenticated peer's aliases with per-peer tombstones, so a colliding message ID queued for a different peer survives, including across protected-data cold-load recovery. Geohash DMs never enter the alias path (their conversation keys carry no noise key).
Presenting the root Bluetooth alert while the people/DM sheet was up forced SwiftUI to dismiss the sheet, whose binding setter called endConversation() — destroying the open DM. The root alert is now gated behind a modal-presentation guard (scene active, no competing modal), a second copy presents from inside the sheet, and the sheet-dismissal setter only ends the conversation when the dismissal is genuinely explicit.
Includes review fix: the voice-recording error alert (mic permission denied inside an open DM) destroyed the DM through the exact same path — it now participates in the same guard and gating pattern at both root and sheet level.
Receiver-side private-media deletion (per-bubble delete and /clear) becomes a write-ahead transaction: a deletion journal in BLEPrivateMediaReceiptStore is the atomic commit point, materialization (tombstones + payload unlinks) is idempotent and retried on recovery, path reservations in BLEIncomingFileStore prevent delete racing an in-flight arrival, and overlapping /clear operations are serialized with panic-generation invalidation. Integrates with the receipt quarantine (a pending journal entry outranks quarantine; materialization never resurrects a quarantined ID).
Review fixes included: (1) /clear no longer deletes outgoing media mirrored into another conversation (alias protection now mirrors the incoming path, with a regression test that fails pre-fix); (2) explicit delete of legacy incoming media actually unlinks the decrypted payload when unreferenced — gated on pending-delivery/reservation state, restoring main's delete semantics safely instead of leaving plaintext for quota cleanup; (3) refused deletions surface a localized system message in the affected chat instead of failing silently (30-locale key). Full local suite 1876 green.
Sender-side retry of private media whose local BLE fragment completion never received a remote delivery receipt: the encrypted file packet is retained in memory (bounded: 8 packets / 4MB / 120s / 2 retries per message / 2 per reconnect) and re-sent on peer reconnect or re-authentication, gated at four boundaries on capability bit 9 plus the exact Noise session generation, so legacy or bit-8-only peers can never receive a retry and the receiver's stable-ID ledger dedups anything re-sent. Remote delivery/read receipts release retention; limits and expiry end in a visible failed status.
Includes review fix: a dropped policy-resolution callback can no longer wedge retries for a peer — the pending resolution is cleared on peer disconnect (with a regression test proving recovery).
Adds a durable receiver-side ledger (BLEPrivateMediaReceiptStore) mapping a deterministic private-media message ID — hash-bound to sender, recipient, and entropy-bearing filename — to the stored file before UI delivery and before the Noise-encrypted delivery ACK, so sender retries and relaunches cannot create duplicate bubbles or files. Receipts are unforgeable without the Noise session; capability bit 9 rides the existing announce bitfield (no wire-format change; rolling upgrade safe both directions).
Includes review fixes: corrupt receipt records are quarantined per-record (bytes preserved at <id>.json.corrupt, only that ID fail-closed — previously one bad record silently disabled ALL inbound private media forever); the panic reset now reaches BLEService's own store instance via completePanicReset with a production-wiring test; and both content.delivery.reason.* strings ship with full 30-locale coverage.
Removes the nested-Task deferral when typed transport events reach ChatViewModel: didReceiveTransportEvent now dispatches to @MainActor *Synchronously coordinator methods inline within the single notifyUI main-actor hop, fixing a real ordering race where a delivery-status update emitted right after a message could apply before the message existed in the ConversationStore and be dropped. Adds SynchronousMessageTransportEventDelegate so BLEService.deliverTransportEvent returns a documented accepted/unconfirmed verdict for .messageReceived (consumed by the private-media receipt layer above). Intra-main-actor only — no cross-queue sync added; the bleQueue-never-blocks-on-main invariant is preserved.
Companion to #1463 (they were built as a unit): adds a bounded deferral buffer (4/peer, 32 global, byte-budgeted, responder-timeout lifetime) for ciphertext that arrives before XX message 3 or before BLE installs generation-bound transport state, retried exactly once after the serialized authentication/restore callback. Reclassifies malformed/forged/replayed/oversized/rate-limited ciphertext as drop-only, so attacker bytes can no longer evict an established session (on main, a 1-byte forgery evicts the session via the old clearSession + re-handshake path). Serializes Noise packet reception as messageQueue barriers.
Honors #1463's timeout-restore deferral through the same-generation ready path (verified by negative test: without the gate, parked DMs drain under discarded keys). Full local suite 1789 tests green.
Replaces destroy-then-rebuild Noise re-handshakes with an atomic reconnect protocol: prepared XX message-1 handoff tokens (claim-once, invalidated by crossed inbound initiations), receive-only quarantine of the established transport while an inbound replacement proves identity (promote on success, rollback+cooldown on failure/timeout), deterministic lower-peerID-wins crossed-initiator resolution, and a per-link-epoch BLE revalidation policy that re-proves cached sessions inside the same bleQueue critical section as the link rebind. On main, a fresh msg1 simply destroys an established session and rekey spans two non-atomic barriers.
Includes the review fix: timeout-restores defer outbound queue draining until the convergence retry completes (restore reason plumbed end-to-end), so DMs are never drained under keys a restarted peer already discarded — with a deterministic interleaving test. Identity-mismatch restores drain immediately. Full local suite 1768 tests green.
Split-out safe half of #1437 (the kind-1402 wire migration stays held for Android coordination). Docs (README/WHITEPAPER/PRIVACY_POLICY/privacy-assessment) now describe the actual proprietary DM construction — kind 1059 gift wrap carrying XChaCha20-Poly1305 with a 24-byte nonce, base64url v2: framing, and an HKDF that borrows the nip44-v2 info label but is not the NIP-44 key schedule — instead of claiming NIP-17/44/59.
Hardens the existing legacy inbound path: 64 KiB ciphertext cap before decode (~46x the largest producible legacy envelope), outer kind/recipient-tag/signature binding, tagless kind-13 seal binding, unsigned kind-14 inner binding, inner tags restricted to the two shapes deployed clients emit (verified against every historical iOS release and a fixture frozen from Android production), SecRandomCopyBytes failure now throws, non-UTF-8 plaintext now throws instead of returning empty. Adds frozen cross-platform fixtures with hash-pinned generators; interop-reviewed with no rejection surface for deployed clients.
Injects the location-notes enabled getter and settings-change publisher into NearbyNotesCounter (defaults reproduce the prior wiring exactly), so tests no longer mutate the persistent UserDefaults key shared across parallel test worker processes. No production behavior change.
Un-stacked from the Codex chain (both files were byte-identical between main and the parent branch) and rebased onto the post-#1479 deflaked test suite.
Closes the last cleartext private-content path over BLE: private DM images/voice were sent as plaintext signed fileTransfer packets, TTL-relayed across the mesh, so every relay saw the full bytes. Now the complete BitchatFilePacket is encrypted as a single Noise AEAD message (inner type 0x20, matching Android) and the opaque ciphertext is fragmented. Adds an authenticated in-session capability proof (0x21 TLV: capabilities + Ed25519 key), TOFU-style downgrade pinning, a per-send consent dialog for the signed-cleartext fallback to legacy peers, and a cancellation/admission registry so cancel/delete cannot race a deferred cleartext send.
Android wire constants (0x20 / 0x21 / capability bit 8) confirmed shipping. The 256-fragment preflight cap applies only to the directed fileTransfer migration fallback; encrypted media to capable peers uses the full receiver ceiling.
Rebased over #1428/#1349: identity reads go through BLELocalIdentityStateStore; the session-bound authenticated signing-key check and the announce-path TOFU pin are kept as complementary checks. Full local suite green (1744+197 tests).
Raises the file-local waitUntil default from 1s to 10s (returns early on success, so zero cost on healthy runs) and fixes a latent race in the observers test: it waited on the fetch-probe request count, which increments before handleFetchSuccess settles isFetching/lastFetchAt on the MainActor, so the next trigger notification posted into that gap was silently swallowed by the guard. Now waits on the .geoRelayDirectoryDidRefresh notification posted at the end of the synchronous success handler. Negative checks assert against captured baselines. No assertion weakened; 15/15 x 9 local runs including under 2x-ncpu CPU load.
Replaces the share-extension handoff that auto-sent shared text/URLs into the current channel with a validated, single-slot 24h envelope that shows the destination and a bounded preview and requires an explicit tap to copy into the composer — it never sends. Rejects malformed/oversized/control-character/non-HTTP(S)/expired payloads (including bidi-override U+202E), and clears on consume/cancel/expiry/panic.
Rebased onto main with Persian strings added for all new keys (30-locale coverage verified), plus a panic-recovery clear so an envelope staged during an interrupted wipe cannot survive relaunch.
TOFU-pins the Ed25519 signing key per noise key so a self-consistent announce that reuses a victim's peerID+noise key with the attacker's signing key/nickname is rejected instead of overwriting the registry and persisted identity. Complements #1432: that PR's signed-LEAVE verification reads the stored signing key this PR protects from announce-path poisoning.
Rebased onto main as a single commit; swift build --build-tests green, 40/40 targeted tests incl. the spoofing e2e cases, and #1432's suites 50/50 unaffected.
Converts BLEAnnounceThrottle to a lock-backed class and moves myPeerID/myPeerIDData/myNickname into a lock-backed BLELocalIdentityStateStore snapshot, so announces can never observe a split peer-ID/wire-ID during panic rotation. Serializes sendAnnounce onto the messageQueue barrier and moves the panic-reset pendingNoiseSessionQueues clear onto collectionsQueue (the queue every other mutation site uses).
Rebased onto main after #1431/#1432; integrates with #1431's panic-suspend structure (guard retained in both the outer sendAnnounce and the deferred worker).
Moves inbound Nostr Schnorr verification and NIP-17 gift-wrap decryption off the main actor into per-relay bounded AsyncStream pipelines (parallel across relays, ordered per relay), dedups before crypto, and removes the redundant second re-verify in NostrInboundPipeline/GeoPresenceTracker. Adds a panic-wipe generation counter so in-flight decrypts are discarded after a wipe.
Rebased onto main; #1451's 256 KiB pre-parse byte cap and tag limits are preserved and still enforced before any crypto/allocation.
Replaces the scheduled workflow that pushed upstream georelay CSV directly to main unreviewed with a validator-backed automation that resolves an immutable upstream commit, validates against the reviewed baseline, and opens a non-auto-merged PR (or tracking issue) instead of writing to main. Adds a mirrored strict client-side validator in GeoRelayDirectory (all-or-nothing, size/row/host/coord caps, streamed 512KiB cap, >=50% baseline overlap) that fails safe to last-known-good, and retargets runtime refresh to bitchat's reviewed copy.
Replaces ConversationStore's message-ID->physical-index map with logical indexes plus a head indexOffset, so cap-eviction advances the offset instead of rebuilding the whole dictionary on every steady-state append (~23.7x measured ingest throughput at cap). Adds a steady-state benchmark floor and a 1,200-op differential stress test against an O(n) reference model.
Rewrites just clean/nuke to remove only ignored build artifacts (.DerivedData/.build), never git-checkout or rm tracked project files (previously could destroy uncommitted work). Adds a CI guard (check-just-clean-safety.sh) against reintroducing source-mutating cleanup, plus README/Local.xcconfig modernization.
Adds an ios-tests CI job that runs the UIKit/CoreBluetooth-conditional suite on the first available iPhone simulator (serial), and fixes the coverage-summary step ordering so the profile isn't invalidated by the serial benchmark rebuild.
Adds remote-static-key->peerID binding at Noise handshake completion (closes a mesh impersonation/MITM hole where a peer could complete a handshake under another peer's ID). Also hardens LEAVE handling to require a verified signature and suppresses relay of unverifiable leaves.
* Make panic wipe deterministic and device-bound
* Scope install markers to iOS
* Harden panic recovery and service shutdown
* Invalidate queued BLE ingress during panic
* Harden panic keychain and media cleanup
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: jack <jack@deck.local>
* Add Persian (fa) localization and an in-app language picker
Persian was the one notable gap in the 29-language catalog. Translate all
381 strings (plus the share extension) with proper plural substitutions,
and register fa in knownRegions.
Settings gains a LANGUAGE section: a picker over every language the bundle
ships (native names via Locale), backed by an AppleLanguages override so
users can run bitchat in a language different from the device's. Localization
resolves at process start, so the picker surfaces a restart note.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Remove unused AppLanguageSettings.currentOverride (Periphery)
AppInfoView reads the override via @AppStorage, so the accessor was dead
code and failed the Periphery CI scan.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: jack <212554440+jackjackbits@users.noreply.github.com>
* Bound public rate-limit buckets against attacker-keyed growth.
Keep the NIP-13 PoW sender bypass, skip content-bucket minting on
sender reject, and evict idle/oldest entries at a hard cap.
Co-authored-by: Cursor <cursoragent@cursor.com>
* Stop Cashu-looking text from skipping long-message guards.
Oversized public content always collapses and takes the plain
formatting path so remote tokens cannot force layout/regex DoS.
Co-authored-by: Cursor <cursoragent@cursor.com>
* Cap teleported geohash participant markers.
Bound the set with FIFO eviction, clear it on channel switch, and
prune markers that leave the visible participant list.
Co-authored-by: Cursor <cursoragent@cursor.com>
* Bound untrusted Nostr relay frames and event tags.
Reject oversized inbound messages before JSON parse, cap tag
arrays/values at decode, and stop logging raw tag contents.
Co-authored-by: Cursor <cursoragent@cursor.com>
* Fail soft when Noise handshake state is unexpectedly missing.
Replace the initiator startHandshake force unwrap with a guard
that throws invalidState instead of crashing.
Co-authored-by: Cursor <cursoragent@cursor.com>
* Cap geohash nickname cache from remote Nostr events.
FIFO-evict at capacity, clear on channel switch, and prune
nicknames that leave the visible participant list.
Co-authored-by: Cursor <cursoragent@cursor.com>
* Avoid overlapping exclusive access in the rate limiter.
Make bucket helpers static so inout dictionary updates do not
conflict with a mutating call on self.
Co-authored-by: Cursor <cursoragent@cursor.com>
* Fix rate-limiter tests for mutating allow under #expect.
Call allow outside the macro so Swift Testing does not capture an
immutable copy of the struct.
Co-authored-by: Cursor <cursoragent@cursor.com>
* Drop unused WebSocket data helper; reset rate limiter on panic wipe.
dataWithinInboundLimit replaced the unbounded path, and panic clear
should not leave public intake buckets behind.
Co-authored-by: Cursor <cursoragent@cursor.com>
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix: use country-level resolution for low-precision geohashes (#887)
* fix: skip admin fallback when country exists but is duplicate
Prevents mixed labels like "United Kingdom and Scotland" for
single-country geohashes. Admin fallback now only triggers when
no country is available from the placemark.
* fix: migrate stale low-precision bookmark names so country-first logic applies
Users who bookmarked a <=2-char geohash before the country-first resolver
kept the old administrativeArea cache (e.g. "England" for `gc`) because
resolveBookmarkNameIfNeeded bails when bookmarkNames[gh] is non-nil. Add a
one-shot, versioned migration that drops cached names for <=2-char geohashes
on load; the next LocationChannelsSheet .onAppear re-resolves them via the
fixed logic. Higher-precision entries are untouched.
* Fix low-precision geohash country names
---------
Co-authored-by: jack <212554440+jackjackbits@users.noreply.github.com>
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Centralize PTT and voice audio-session ownership, harden courier/bridge/outbox delivery and recovery, correct location and delivery-state races, add privacy/release metadata, and ship reproducible universal Arti slices with Release CI coverage.
Validated by the full iOS suite, repeated audio/fragment/performance regressions, BitFoundation tests, strict lint and dead-code analysis, universal iOS Release builds, and iOS/macOS archives.
* Consolidate duplicate BLE links after restore; suppress duplicate fragment streams; onChange coalescing
Field evidence (two-phone test after BLE state-restoration relaunches):
both phones held 2-3 simultaneous same-role connections to each other —
one side received every packet from three distinct centrals all bound to
the same peer — so every PTT voice frame arrived 3x, and a 41KB voice
file went out as TWO complete independent 89-fragment streams (different
assembly ids), both fully reassembled and the duplicate only dropped at
the very end by messageID dedup. 2-3x airtime/battery on all traffic
plus doubled reassembly memory.
Root causes and fixes:
- Duplicate links stayed unbound forever: announces (the only packet
that binds a link to a peer) went through the per-peer duplicate-link
collapse, so a peer's second/third link never received the announce it
needed to become bound — and unbound links pass the collapse untouched,
so every broadcast sprayed down all of them. Direct announces now
bypass the collapse and reach every live link (relayed announces keep
it); once bound, the existing collapse dedups all traffic.
- Same-role link retirement: a verified direct announce now consolidates
our central-role connections to that peer — keep the link the announce
arrived on (or the most recently bound one), cancel other connected
links bound to the same peer. One connection per role per peer is the
normal dual-role topology; only same-role duplicates are touched, only
links already announce-bound are retired (never pre-announce links),
at most one retirement per peer per rebind-cooldown window, and the
peer keeps a live link either way. Directness stays forgeable (TTL is
unsigned), so a replay could nominate the survivor — bounded by the
cooldown and by DM routing's existing canDeliverSecurely gate. A
rotation rebind now also cancels other stale links still bound to the
rotated-away ID, so the ghost identity retires promptly.
- Deterministic preferred-link collapse: when several bound links to one
peer are candidates, collapse now keeps the peer's most recently bound
link (the reverse-mapped one) instead of dictionary order; links
without a discovered characteristic are excluded from fanout (they
cannot be written to, and could silently eat a peer's collapsed copy).
links(to:) now reports all bound peripheral links, and removing one
duplicate no longer clobbers the reverse map of the survivor.
- Duplicate fragment streams: a transferId-less resend (gossip-sync
replay, spool) of file content already being fragmented out to a
covering audience is dropped at the outbound scheduler (broadcast
covers everyone; directed covers its recipient). App-initiated sends
carry an explicit transferId the progress UI tracks and always run.
A peer that asks after the stream completes still gets a resend.
- didUnsubscribeFrom no longer flaps a peer that is still live on other
links (the far side retiring its duplicate arrives as an unsubscribe);
didDisconnectPeripheral bookkeeping is skipped for self-retired links
by removing the store entry before cancelling.
Also: guard the DeliveryStatus onChange state write in TextMessageView/
MediaMessageView (unconditional per-row writes under a message storm
tripped SwiftUI's "tried to update multiple times per frame" warning).
The restore-path bgRemaining=∞ log was already fixed on main (#1425
review follow-up 07b5ac31: init-time seed + sampler-routed restore
captures); verified, no change needed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Review fixes: multi-link disconnect guard, characteristic-aware retirement
Adversarial review of the duplicate-link PR (merge-with-nits):
- didDisconnectPeripheral gets the same multi-link guard as the
unsubscribe path: when a duplicate link drops naturally while the peer
stays live on another (dual-role central link, or a second bound link
during the post-restore consolidation window), peer-disconnect
bookkeeping (markDisconnected + disconnect notify) no longer runs — a
UI blip until the next announce re-marked the peer connected. The
reverse map was just repaired onto a connected survivor, so
directLinkState is the accurate probe. Scan restart and connect-slot
refill stay unguarded: they respond to the physical drop regardless of
remaining logical links. (No unit test: driving the CBCentralManager
delegate requires CBPeripheral instances, which cannot be constructed
in tests; the policy pieces backing the guard are covered.)
- Retirement is now characteristic-aware: the policy snapshot carries
characteristic presence, and keptPeripheralUUID selects anchors only
among writable links while any exist — consolidation must not keep a
link mid-service-rediscovery (didModifyServices cleared its
characteristic) and cancel the writable duplicate, stranding outbound
traffic on the central link until rediscovery finishes. When neither
anchor is writable but a writable duplicate exists, consolidation
defers to a later announce instead of guessing. The reverse-map
survivor repair in removePeripheral prefers writable links for the
same reason. Three new policy tests cover charless-vs-writable.
Deferred with code comments per review: central-side collapse keeps the
oldest subscription (no recency signal; remote consolidates within its
cooldown), and the extra preferred-bindings bleQueue hop in
sendOnAllLinks (fold into a combined snapshot if profiling flags 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>
* Fix restore-path main↔bleQueue deadlock and courier drop amplification
A device froze permanently in a two-phone test. Debugger stacks showed an
ABBA deadlock: the main actor was in bleQueue.sync (delivery-ack send →
broadcastPacket → readLinkState) while bleQueue was in main.sync
(captureBluetoothStatus reading backgroundTimeRemaining). The load that
lined the two edges up came from a courier-drop amplification storm:
drop dedup was in-memory only while the outbox driving 120s re-deposits
is persisted, so every relaunch republished the same undelivered DM as a
fresh 24h relay drop and every gateway relaunch re-fetched the whole
backlog — ~20 copies of one DM delivered in 40ms, each triggering
decrypt + delivery + ack + handshake work.
Fixes, in rank order:
- Edge B (P0): captureBluetoothStatus no longer main.syncs from bleQueue;
backgroundTimeRemaining is sampled on main and cached behind a lock.
Invariant documented: bleQueue must NEVER sync-dispatch to main.
- Edge A (P0, defense in depth): sendDeliveryAck / sendReadReceipt /
sendPrivateMessage / sendNoisePayload / triggerHandshake hop to
messageQueue like sendMessage, so no main-actor call path reaches
readLinkState's bleQueue.sync.
- Drop dedup (P1): publishedDropKeys and seenDropEventIDs persist across
relaunches (new BridgeDropDedupStore, entries expire with the 24h
NIP-40 drop window; wiped on panic) — one drop per message ID per 24h
regardless of relaunch count.
- Receiver dedup (P1): openCourierEnvelope dedups on the inner private
message ID before delivery, so a duplicate copy costs one decrypt and
never re-delivers, re-acks, or re-triggers a handshake.
- Handshake gating (P2): queued acks initiate a Noise handshake only for
reachable peers; mail from absent/rotated identities no longer turns
each copy into a mesh-wide handshake flood (the ack stays queued and
flushes when a session eventually establishes).
- Outbox (P3): re-enqueueing a queued message ID carries over its
depositedCourierKeys so resends stop re-burning the same courier slots.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Review fixes: offline-drop durability, gateway handoff retry, restore-log freshness, coalesced persist
Adversarial review of the storm/deadlock PR surfaced four issues:
- Offline blackhole (must-fix): a deposit made while relays were down
persisted its dedup key even though the drop only sat in the in-memory
pending queue — app killed before reconnect meant the relaunch lost the
drop but the persisted key blocked every re-deposit for 24h. The
persisted snapshot now excludes keys still pending; they become durable
only when flushPendingDrops actually publishes them.
- Gateway handoff: seen-event IDs were consumed before the deliverToPeer
handoff; a failed handoff (peer walked away) permanently dropped the
event for a single-gateway island. deliverToPeer now reports whether
the handoff was attempted, and a failure releases the seen slot so a
relaunch or backlog redelivery retries.
- Restore-path logs: central/peripheral-restore captures logged the init
sentinel bgRemaining=∞. The cache is now seeded in init's main-thread
branch and restore captures route through the sampler, which refreshes
the cached budget before logging.
- Persist cost: the dedup record was a full JSON encode + atomic write on
the main actor per mutation (once per event during a backlog re-fetch).
Writes now coalesce behind a 1s window, flushed immediately on
background/terminate; panic wipe stays immediate.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Remove BoundedIDSet.remove, orphaned by the ExpiringIDSet migration
The drop-dedup sets that needed slot release moved to ExpiringIDSet;
remaining BoundedIDSet users only insert and check. Periphery caught 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>
* Nearby notes: tap-to-reveal before any relay REQ, plus shared subscription pool
The nearby-notes counter used to open a live building-precision (precision-8)
geohash REQ to the closest geo relays whenever the mesh public timeline was
visible — a passive location side-channel with no opt-in. Now nothing
subscribes until one explicit act reveals the counter for the session: tapping
the new "check for notes left here" line on the empty mesh timeline (static,
no network), opening the notices sheet's geo tab, or a successful /drop. The
app-info setting stays the default-ON kill switch and still gates /drop.
Subscription hygiene alongside:
- LocationNotesManager.deinit now unsubscribes its live REQ (hopping to the
main actor like the timer teardown) instead of only invalidating timers.
- New refcounted LocationNotesPool dedupes the counter's and the notices
sheet's identical 9-cell kind-1 REQs into one shared manager per geohash;
both callers release-and-reacquire instead of retargeting in place, and the
sheet releases its ref on dismissal.
The reveal affordance is localized across all 29 catalog locales, and new
NearbyNotesCounterTests cover the no-REQ-before-reveal contract, the 9-cell
filter, NIP-40 expiry handling, single unsubscribe on deactivate, and pool
refcounting.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Review fixes: permission-gate the hint, exclude building cell from pre-reveal sampling, explicit-act reveal only
Fixes the verified review findings on the tap-to-reveal PR:
- Permission dead-end: the "check for notes left here" hint now renders
only when location permission is already authorized (it never prompts).
Previously a location-denied install could tap it, flip the sticky
revealed flag, and get nothing for the rest of the session because
retarget() guards on authorization. Predicate lives on
NearbyNotesCounter.offersRevealHint(permissionState:) and is reactive
to the published permission state.
- Building-cell sampling: background geohash sampling subscribed
geo-sample-<gh> for every regional level including the precision-8
building cell, pre-reveal — contradicting the claim that nothing
building-precision hits a relay before the explicit act.
GeoChannelCoordinator now excludes the building level until
NearbyNotesCounter.revealed (injectable publisher for tests); coarser
levels keep the nearby-conversation hint and participant counts
working, and bookmarks stay exempt (bookmarking is explicit).
- Implicit reveal: opening the notices sheet no longer reveals — the
sheet auto-lands on the geo tab whenever a location channel is
selected, so browsing a remote geohash and opening notices revealed
the LOCAL building subscription. reveal() now fires only on the
person actively picking the geo segment, and only when the sheet has
a geo scope (the empty-mesh hint tap and /drop stay as before).
- Subscription hygiene: switching the sheet geo → mesh releases the
pooled notes manager (the REQ was left streaming behind the mesh
board); switching back re-acquires from the pool. The dismissal
release stays balanced — liveGeoManager is nil after the tab-switch
release.
- VoiceOver: the hint button exposes the plain localized action text
instead of the decorated "* 📍 … *" label.
- Removed LocationNotesManager.setGeohash: zero callers, and calling it
on a pooled instance would corrupt the pool's keying and refcounts.
New tests: hint permission gate, explicit-geo-tab reveal contract,
building-cell sampling exclusion before/after reveal, pool
release/re-acquire round trip. Full suite (1467) green; iOS simulator
build green.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Deflake peer-snapshot binding waits: longTimeout for the multi-hop pipeline
CI failed once on initialization_bindsPeerSnapshotsIntoAllPeers: the
snapshot -> allPeers binding crosses the mock transport's unstructured
Task, UnifiedPeerService.updatePeers, a receive(on: main), and another
Task { @MainActor } in bindPeerService — all contending with every
parallel worker. On the failing runner the whole suite took 10.1s
(usually ~4.4s locally), so the positive 5s defaultTimeout wait lost
the race. That's exactly the case TestConstants.longTimeout documents;
passing runs return as soon as the condition holds and never pay it.
Not caused by the tap-to-reveal changes: nothing on that pipeline was
touched, and 20 full parallel-suite loops each on the branch and on
origin/main reproduce zero failures locally. The two sibling waits on
the same pipeline in this file get the same timeout.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* Gate connected-link trust on a secure session; deny forged direct announces the connected shortcut
Residual gap after the rotation-heal containment (#1401): "verified
direct" announces prove the signature but not directness — TTL is
unsigned — so a malicious connected peer can replay a victim's fresh
announce with its TTL restored. When the victim has no live link, the
replayer's link rebinds to the victim's ID and reads as "connected",
and MessageRouter's connected fast-path then trusts it outright: every
DM stalls on a Noise handshake the replayer can never complete and is
silently lost while showing "sent".
Router-level trust gate (no wire change):
- Transport gains canDeliverSecurely(to:) — BLE answers with an
established Noise session; Nostr keeps its prompt-delivery predicate;
the protocol default forwards to canDeliverPromptly for transports
without a forgeable link layer.
- MessageRouter.sendPrivate only trusts a connected link outright when
it can deliver securely; otherwise it still sends (kicking the
handshake on a genuine link) but retains a copy and hands a sealed
copy to couriers, like the reachable path. flushOutbox gets the same
gate so a flush over an insecure link resends instead of dropping the
retained copy.
Presence hardening (defense in depth): a "direct" announce arriving on
a link already bound to a different peer no longer shortcuts the
claimed peer into "connected" — only real link state does. Genuine
first-contact and direct announces are unaffected; only the ambiguous
heal path loses the forgeable shortcut.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Harden the insecure-link outbox bound; document the second-replay presence gap and the courier metadata tradeoff
Review follow-ups on the canDeliverSecurely gate:
- flushOutbox no longer counts connected-but-insecure flushes toward the
maxSendAttempts drop: the message was actually transmitted over a live
link, so a peer whose Noise handshake stalls across reconnect flapping
must not burn through the cap and lose the store-and-forward copy the
gate exists to preserve. Retention stays bounded by the 24h outbox TTL
and the per-peer FIFO cap; acks still clear it. Attempt-counting stays
for reachable-only (heuristic) sends. Regression test: >8 connected-
insecure flushes keep the retained copy, drop callback never fires.
- Document the known second-replay presence gap: linkBoundToOtherPeer
reads the binding before rebindLinkAfterVerifiedDirectAnnounce steals
the link, so once a first replay has rebound a link to an absent
victim's ID, a second replay marks the victim connected. Presence
display only — DMs stay on the retain+courier path via the router
gate. Not closed at the announce layer because the post-rebind state
is indistinguishable from a legitimate rotation/reconnect heal (a
supported, field-verified flow). Covered by a two-announce test.
- Note the accepted courier-spray metadata tradeoff at the connected-
insecure send: nearby verified peers receive a sealed copy (they learn
a DM exists, never its content), cleared on ack.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Promote a healed rotation to connected; normalize the secure-delivery probe; retain Codable properties in Periphery
Codex review follow-ups on 5017c232:
- P1: a legitimate rotation announce necessarily arrives on a link still
bound to the OLD peer ID, so the linkBoundToOtherPeer denial stored the
new identity as disconnected — and the rebind only fixed link state,
never the registry. A healed rotation then read as disconnected until
the peer happened to announce again. rebindLinkAfterVerifiedDirect-
Announce now promotes the rebound identity to connected after the
containment checks pass (registry markConnected + topology/snapshot/
peer-list refresh; the .peerConnected UI event already fired from the
announce path). This consciously moves the forged-presence residue
from second-replay to first-successful-rebind — bounded by the rebind
containment (never steals a live identity, one rebind per link per
cooldown) and still display-only: DMs stay gated on canDeliverSecurely.
Comments and the pinned tests updated; new regression test covers
rotate-on-open-link -> rebind -> isPeerConnected(new) == true.
- P2: BLEService.canDeliverSecurely probed the Noise session with the
peer ID as given, but sessions are keyed by the short wire ID — a send
keyed by the full 64-hex Noise key (favorites resolution) misread an
established session as insecure and needlessly retained + couriered
every DM until ack. Normalize with toShort() like isPeerConnected.
Test drives a real XX handshake and asserts both ID forms pass.
- Periphery: the PrekeyBundleStore.StoredBundle.noiseKey "assign-only"
flake fired again and slipped past its baselined USR (read exists in
loadFromDisk; the indexer intermittently misses it). Replace the
baseline entry with retain_codable_properties: true — deterministic,
and a truly-dead Codable field is a persisted-format change anyway.
Local periphery scan --strict: no unused code detected.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* PTT hardening: burst-ID collision hijack + live-capture quota bypass
Fix C — burst-ID collision hijack: inbound live-voice assemblies and the
finished-burst registry were keyed by the sender-chosen burst ID alone, so
an attacker who observed a public burst ID could race a START and capture
the real talker's frames (packets from the true sender were dropped as
"collisions"). Assemblies now key on (peerID, scope, burstID): a colliding
START from another peer opens its own capped assembly and can never divert
the victim's frames; finalized-note absorption matches on the same triple,
preserving the sender/scope binding. Live capture files also gain the peer
ID in their name so colliding bursts land on distinct paths (still rejected
by burstID(fromVoiceFileName:), so live names remain unabsorbable).
Fix B — live-burst files bypassed the incoming-media quota: progressive
voice_live_*.aac captures were written via raw FileHandle without ever
touching BLEIncomingFileStore.enforceQuota, growing disk unbounded outside
the 100 MB LRU accounting. The coordinator now takes an injected
BLEIncomingFileStore, reserves pttMaxBurstBytes before opening a capture,
and sweeps orphaned voice_live_* partials from previous sessions at
startup. enforceQuota gains an `excluding:` set so in-flight partials are
never LRU-evicted mid-stream; existing callers are unaffected.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Review fixes: pattern-guard live captures in quota, scope in capture names
Quota-eviction gap: BLEFileTransferHandler enforces the quota for every
finalized arrival via enforceQuota(reservingBytes:) with no exclusion set,
so a file landing at quota could LRU-evict an in-flight live capture —
unlinking the inode under the coordinator's open FileHandle and leaving a
dead bubble. Protection is now layer-independent: enforceQuota itself skips
voice_live_* names (they still count toward usage), and the excluding:
parameter is gone since the pattern guard covers its only caller. Orphaned
partials are still reclaimed by the coordinator's startup sweep, which the
quota deliberately never touches.
Same-peer cross-scope truncation: makeIncomingURL omitted the scope, so one
peer running a DM burst and a public burst with the same burst ID mapped
both assemblies onto one path — and FileManager.createFile truncates, so
each START corrupted the other capture. Names now mirror the assembly key:
voice_live_<burstHex>_<peerID>_<dm|mesh>.aac. The sweep and quota guard
match on the voice_live_ prefix and burstID(fromVoiceFileName:) still
rejects every live name, so live captures remain unabsorbable;
sameBurstIDCoexistsAcrossScopes now asserts both files survive with intact
contents.
Nits: the coordinator's file operations route through the store's
injectable FileManager instead of FileManager.default, and the
TestEnvironment.isRunningTests branch in init is replaced by a
sweepsOnInit parameter (tests sharing the real application-support
directory pass false for hermeticity).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Promote kept live captures off the voice_live_ name at finalize
Codex P1 follow-up: when a burst finalizes with frames but its .m4a note
never arrives, the voice_live_*.aac capture stays behind as the bubble's
replayable audio — yet the startup sweep deletes every voice_live_* file
and the quota guard skips them forever, so a kept fallback was both
quota-immune for the rest of the session and doomed at the next launch.
finalize now promotes the capture to a plain voice_ name (same suffix) and
republishes the row pointing at it; the finished-burst registry tracks the
promoted URL so a late note still absorbs and deletes it. voice_live_ is
thereby scoped to genuinely in-flight captures: the sweep never touches a
referenced fallback, and promoted files age out of the quota like any
finalized media. If the move fails the live name is kept — exactly the
pre-promotion behavior.
Premise correction, verified while tracing the reference model: chat rows
are NOT persisted across restarts (ConversationStore is in-memory; the
gossip archive replays MessageType.message packets only), so today's sweep
never orphaned a persisted row — the fix removes the in-session quota
immunity and makes the invariant hold if row persistence ever lands. Crash
case stays deliberate and documented: a mid-burst partial from a dead
process is swept because no surviving row can reference it.
Tests: finalize-as-fallback promotes the file, repoints the row, and
survives a later coordinator's startup sweep; promoted fallbacks are
LRU-evictable by the quota; the sweep still removes true orphans while
sparing promoted names; existing burst tests updated for the promoted
paths.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* Bridge dedup keys on a content-derived stable mesh message ID
Public mesh messages carry no message ID on the BLE wire, so every
non-origin device minted a fresh UUID and the bridge's m-tag dedup only
matched on the origin device: duplicate bridged rows, misattributed
"across the bridge" counts, redundant downlink rebroadcasts, and an
m-tag spoof vector (an attacker could claim a victim's message ID).
Every device now derives the same stable ID from the signed wire fields
(sender ID + ms timestamp + trimmed content, SHA256/32 hex) via the new
MeshMessageIdentity — zero BLE wire change. The bridge event's m tag
carries the origin coordinates ["m", senderIDHex, timestampMs] and
receivers recompute the key from those plus the event's own content
instead of trusting a claimed ID; old-format/absent tags fall back to
the event ID as before.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Fix mixed-version message loss: m tag leads with the derived stable ID
The previous layout (["m", senderIDHex, timestampMs]) broke v1.7.0
receivers: their parser takes m[1] unconditionally as the timeline
dedup key whenever the tag has >= 2 elements, so every bridged message
from a new-version sender keyed on the CONSTANT sender hex and
inject-dedup dropped all but the first. The tag is now
["m", <derived stable ID>, senderIDHex, timestampMs]: old parsers get a
per-message-unique m[1] (exactly today's semantics), while the new
parser recomputes the ID from elements 2-3 plus the event's own content
and never trusts element 1, keeping the recompute-don't-trust property.
Also:
- Soften the overstated security claim in MeshMessageIdentity and the
BridgeService classify comment: forging a chosen ID onto different
content is infeasible, but all three hash inputs are cleartext on the
radio, so identical-content front-running by a radio-local attacker
remains possible (no worse than the unbridged mesh).
- Fix the stale archivedEchoKeys rationale: re-synced copies of others'
messages now carry the derived stable ID (insert-by-ID catches them);
the content key remains for echo--prefixed archive rows + self echoes.
- Tests: old-parser semantics on the new tag (m[1] per-message-unique
and equal to the derived ID) and a forged-m[1] event that cannot
pre-poison a genuine message's dedup slot.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* Quality pass on the 1.7.0 batch: fix confirmed bugs, bump to 1.7.1
Post-merge review of PRs #1400–#1417 (push-to-talk, mesh bridging, DM
store-and-forward, empty-mesh liveliness, geo-notes). Fixes the confirmed,
well-scoped findings; deeper architectural/security items are tracked
separately.
- PTT hot-mic leak: releasing the mic during VoiceCaptureSession.start()'s
150ms retry pause left the mic live and streaming for up to 120s, because
cancel() no-op'd once `completed` was set. Bail after the sleep if the hold
was released, and make cancel() always tear down a late-started capture.
- Bridge courier depositDrop reported success and burned the dedup slot before
the drop was actually published (evicted/compose-fail = lying 📦 "carried"
with no retry). Only consume publishedDropKeys on durable accept; add
BoundedIDSet.remove() to release evicted/failed slots (uses the dead dedupKey).
- Blocked senders resurfaced via archived "heard here earlier" echoes, the one
path that bypassed the live block filter — filter at seed time.
- A late optimistic .sent clobbered the router's .carried state; extend
ConversationStore.shouldSkipStatusUpdate to a full precedence guard
(sending < sent < carried < delivered < read).
- Read receipts were permanently burned when the router dropped them (marked
sent then dropped). sendReadReceipt/routeReadReceipt now return Bool; only
record as sent on a successful route, else retry on the next read scan.
- MessageRouter.cleanupExpiredMessages() had no production caller, so DMs to a
peer that never reconnects sat on .sending until relaunch — run it in the
120s bridge sweep.
- Sightings tally now rolls over at midnight while idle; wave notification
action localized across all 29 locales; bridged anon#tag uses suffix(4) like
everything else; makeThrowawayIdentity delegates to NostrIdentity.generate();
.swiftlint.yml excludes .claude worktrees.
- Add regression tests: carried→sent no-downgrade, carried→delivered upgrade,
evicted pending drop stays retryable.
- Bump MARKETING_VERSION to 1.7.1.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Fix CI: adjust delivery-status benchmark and drop now-dead addSystemMessage
The stricter no-downgrade guard (delivered/carried never regress to sent) broke
two things the earlier commit didn't catch locally (perf tests are skipped in
the default run, and Periphery runs only in CI):
- PerformanceBaselineTests delivery benchmarks alternated sent <-> delivered
assuming both directions apply; the delivered -> sent half is now correctly
skipped, so the pass measured 0 updates. Alternate two delivered timestamps
instead — every update is real, no downgrade.
- Routing the geoDM "not in a location channel" error into the thread removed
the only caller of ChatPrivateConversationContext.addSystemMessage, leaving
it (and its mock) dead per Periphery. Drop the protocol requirement, the mock
impl, and the now-vacuous systemMessages.isEmpty assertions (the invariant is
compile-time enforced: the context can no longer emit a public system line).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Address review findings: read-receipt dedup, carried-vs-sending, block-time echo purge
- Read receipts: claim the receipt in sentReadReceipts synchronously
before spawning the routing task (chat open runs two read scans in one
MainActor stretch, so the async insert let every unread message route
twice), and release the claim when the route fails so the
retry-on-failed-route behavior is preserved.
- Delivery status: extend the no-downgrade guard so the `.sending`
stamp a pre-handshake resend emits can no longer clobber
carried/delivered/read (the 📦 indicator survived `.sent` but not
`.sending`).
- Archived echoes: blocking a peer now purges their carried public
messages from the gossip archive at block time (UnifiedPeerService
and /block), while the fingerprint-to-peerID mapping is still known —
the seed-time filter can't resolve offline non-favorite strangers and
stays only as defense-in-depth. New Transport hook (default no-op) +
GossipSyncManager.removePublicMessages with immediate persist.
- Bridge courier: an envelope that can't encode within the drop size
caps fails identically on every attempt; consume the dedup slot so
the 120s retry sweep stops re-running Noise sealing on it.
- MeshSightingsTracker: cache the day-key DateFormatter instead of
building one per call.
Tests: double-markAsRead dedup + failed-route retry, carried→sending
no-downgrade matrix, block-time purge (manager + service wiring),
oversize-drop slot consumption.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Also skip the sent→sending downgrade in the delivery-status guard
Codex review follow-up: sendPrivateMessage without an established Noise
session emits `.sending` asynchronously, so it can land after the
message already reached `.sent` and visibly walk "Sent" back to
"Sending...". Treat `.sending` as weaker than `.sent` too — the status
was already truthful. `.failed` → `.sending` stays allowed so a retry
after a real failure remains visible.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Retain Codable properties in Periphery scan (same fix as #1421)
The noiseKey assign-only false positive fired persistently on this branch
(twice, including a rerun) despite the baselined USR. Byte-identical to the
fix on fix/announce-replay-link-steal so the branches merge cleanly in
either order.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
The variable only fed the deleted guard (#1415); the favorites lookup in
the unified-peer branch existed solely to populate it.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* DMs to unreachable peers route through store-and-forward; drop stale reachability gates
Field-found: sendPrivateMessage pre-judged reachability and marked the
message failed without ever calling the router, so the retained outbox,
courier deposits, and bridge drops never ran — a DM composed after a
peer's reachability window lapsed was dead on arrival while an identical
one sent a minute earlier delivered. Messages now always route; a live
path earns "sent", everything else stays "sending" until the router
reports carried/delivered or expires it as failed.
A sweep for sibling gates found and fixed:
- startPrivateChat refused offline non-mutual favorites ("mutual favorite
required for offline messaging") — store-and-forward only needs the
recipient's noise key, so the gate and its string are gone.
- markPrivateMessagesAsRead skipped the whole receipt pass for peers
without a stored Nostr key, starving mesh-connected non-favorites; the
router picks the transport now (sentReadReceipts dedups the parallel
PrivateChatManager path).
- DM/geoDM blocked notices and the unknown-group error posted to the
active public timeline; they now land in the thread they're about via
addLocalPrivateSystemMessage.
- Banned copy: literal "user" fallbacks in code become "anon" (the
default-nickname convention), and es/fr/it/pt translations of four keys
still saying usuario/utilisateur/utente/usuário now say person. Orphaned
keys removed (system.dm.unreachable, content.delivery.reason.unreachable,
system.chat.requires_favorite).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Deflake BLEServiceCoreTests: longTimeout for positive waits
CI flaked on duplicatePacket_isDeduped: the first message landed after the
5s wait expired on a loaded runner (the test's later count==1 assertions
passed, proving late delivery, not lost delivery). All four positive waits
in the file now use TestConstants.longTimeout, which exists for exactly
this — waitUntil returns as soon as the condition holds, so passing runs
never pay the longer ceiling.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix read-receipt test contamination; baseline Periphery noiseKey flake
Two CI failures, both environmental:
- markReadReceiptSent_returnsFalseOnSecondCall flaked because every test
ChatViewModel shared one per-process read-receipts scratch suite; the
lifecycle test persists the same "read-1" ID (a path the receipt-gate
removal now reaches), and test order decided who saw whose state. Each
instance now gets its own UUID-suffixed suite.
- Periphery intermittently misses the loadFromDisk read of
PrekeyBundleStore.StoredBundle.noiseKey and fails --strict with a false
"assign-only" finding (recurrence of a known flake). Its USR is
baselined; an in-source periphery:ignore can't work because strict mode
flags it as superfluous on runs where the indexer gets it right.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
The macOS Debug configuration uses AppIconDebug, which had no mac-idiom
entries at all, so Debug builds shipped with the generic dock icon. And
the mac slots in AppIcon reused the full-bleed square iOS artwork; macOS
does not mask icons at render time, so even Release showed a sharp-
cornered square.
- Regenerate all AppIcon mac PNGs with the Big Sur icon grid baked in
(824x824 rounded-rect body on a transparent 1024 canvas + standard
drop shadow), derived from the same 1024 iOS art.
- Add a full mac icon set to AppIconDebug from the green debug artwork.
- Add scripts/generate-mac-appicon.swift (pure CoreGraphics) to
re-derive the mac sizes whenever the 1024 source changes.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Mesh bridging: stitch nearby mesh islands over Nostr, courier drops, settings surface
Three features plus a UI consolidation, all opt-in behind a new Bridge toggle:
Channel bridge: while bridging, outgoing public mesh messages are also
signed (with a derived, unlinkable per-cell Nostr identity) as kind-20000
events tagged #r with the local geohash-6 cell and published to the cell's
deterministic geo relays; mesh-only peers deposit via new toBridge/fromBridge
carrier directions through a bridge gateway (bridge + gateway toggles).
Remote islands' events render into the mesh timeline marked with a network
glyph. Events carry the original mesh message ID so the store's insert-by-ID
absorbs radio/bridge duplicates in either order. Loop prevention mirrors
GatewayService (three BoundedIDSet caches + skip-if-seen-locally + budgets).
Nothing crosses a bridge unless its author signed it for the bridge; a
per-message "nearby only" composer toggle keeps a message radio-only.
Courier over the bridge: sealed courier envelopes park on default relays as
kind-1401 drops tagged #x with their day-rotating recipient tag (NIP-40
expiry), signed by per-drop throwaway keys. Recipients subscribe for their
own candidate tags; bridge gateways watch verified local peers' tags and
hand matching drops over as directed courier packets. DM delivery to known
peers stops requiring a physical courier encounter; the Noise-X seal never
opens in transit.
Presence: kind-20001 heartbeats on the rendezvous feed a "people across the
bridge" count in the header (approximate: local participants subtracted by
radio-copy attribution).
Settings/Info: AppInfoView is now a segmented Settings/Info sheet. Settings
hosts appearance, voice (fixes the duplicated Voice section), a Connectivity
section (bridge + gateway + Tor toggles, the latter two moved out of the
location sheet), and a confirmed panic-wipe button. New announce TLV 0x06
advertises the gateway's rendezvous cell; PeerCapabilities gains .bridge.
i18n: 23 new keys across all 29 locales; coverage tests green.
Tests: 50 new app tests + 3 BitFoundation tests; full suite 1445 green.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Settings polish: one toggle style, sticky Info-first tab, location access in Settings
- The live-voice toggle now uses the same settings card + IRC pill as the
connectivity toggles (settingToggle, renamed from connectivityToggle).
- Segmented control orders Info first; the selected pane persists across
opens (AppStorage), so first-ever open lands on Info and afterwards the
sheet reopens where it was left.
- "remove location access" moved from the channels sheet into the Settings
Connectivity section (same key, still deep-links to system settings).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Location UX + copy: state-aware access control, honest empty state, clearer bridge/gateway text
- Settings' location control now covers all three permission states: grant
(real prompt, only possible while never-asked), open-system-settings when
denied, remove-access when granted. The channels sheet keeps its own grant
path for people who start there.
- The channels list no longer spins forever without permission; it shows
"grant location access to find nearby channels" instead (new key, 29
locales).
- Bridge and gateway subtitles rewritten for clarity; the gateway subtitle
moved to a new key since it now carries bridge traffic, and the old
geohash-only key is deleted. The word "user" is banned from copy in every
locale ("this person is blocked").
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Field-test fixes: dedupe relay-connectivity triggers, throttle presence, log bridge decisions
First on-device run confirmed publishes accepted and the subscription
delivering, but exposed trigger spam: NostrRelayManager's isConnected
re-emits per relay recompute, so presence published 5x/second and the
courier-drop subscription rebuilt 6x in 300ms. removeDuplicates() on the
sinks + a 30s presence throttle (same-second heartbeats are byte-identical
events anyway). Also: injection/skip/downlink now log under 🌉 so field
verification is observable — the first test looked silent precisely because
dedup correctly suppressed same-island bridged copies.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix restart self-echo: recognize own rendezvous events by derived pubkey
Second field run proved bidirectional bridging live (~1-2s Mac<->iPhone via
Tor) but caught a bug: relay backfill after an app relaunch re-delivered the
device's own pre-restart events, and with the in-memory published-ID cache
wiped they rendered as bridged copies of your own messages. The rendezvous
identity is deterministically derived per cell, so self-recognition by
pubkey needs no cache and survives restarts; own events are also marked
never-downlink. Regression test simulates the fresh-launch state.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* People sheet: mesh, bridge, and groups in one list
The header's bridged count had no matching faces anywhere — the people
sheet only knew mesh peers. BridgeService now publishes named participants
(nickname from message tags, geohash-style #last4 disambiguation, presence
keeps a known name alive) and the mesh people sheet gains an
"across the bridge" section between mesh peers and groups. Display-only
rows in v1 (bridged identities have no DM route yet). Two new catalog keys
x29 locales; also normalizes one out-of-sort-order entry inherited from a
hand-edited key on main.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Header: one people icon, one count, one sheet
Fold the bridged-people count into the main person.2.fill count instead of
a second network-glyph counter; the merged people sheet (mesh / across the
bridge / groups) is the breakdown. VoiceOver still announces how many of
the total are across the bridge.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* People sheet symmetry: #mesh section header, no active count
Every section now gets the same glyph+label header shape (shared
PeopleSectionHeader): #mesh over the peer list, across-the-bridge over
bridged people. The "N active" line is gone (mesh); location channels keep
their geohash subtitle. Dead subtitle/count helpers removed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* One switch: the bridge toggle drives all internet sharing
Field feedback: two toggles (bridge + gateway) with an invisible dependency
was a trap — bridged messages silently never reached mesh-only neighbors
unless a second lever was found and flipped. Collapsed to a single switch
that does the right thing for your situation:
- Bridge ON + internet: your messages cross, you see the bridge, AND your
device serves its island — accepts toBridge deposits, carries remote
messages onto the radio, watches courier drops for verified local peers,
advertises the cell, and runs the geohash-channel gateway.
- Bridge ON, no internet: you ride whoever nearby is serving.
- Bridge OFF: nothing of yours crosses; radio reception of bridged traffic
stays passive and free.
With every online bridger serving, downlink gets a 0.2-1.5s jittered
holdoff + send-time suppression recheck so co-located gateways don't burn
duplicate airtime (two-gateway test included). The internet-gateway card is
gone from Settings (GatewayService now follows the bridge switch, with
launch-time migration); its orphaned catalog keys deleted and the bridge
subtitle broadened across all 29 locales. Also: MeshPeerList's empty state
("nobody around...") aligned to the section row rhythm.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Bridge pumps its own location; fix centered people sheet; stop drop-subscription churn
Field session 3 found the bridge silently cell-less: it read
availableChannels passively, which only flow while some other feature
(channels sheet, location notes, geo sampling) happens to pump location —
turn those off and the bridge never gets a rendezvous. BridgeService now
requests a one-shot fix whenever it's enabled without a cell (and
piggybacks one on the presence timer so moving devices migrate cells).
Also from the session: the people sheet's scroll content hugged its widest
child and got centered on iPhone when the list was empty — pinned to full
width, leading. And the courier-drop subscription rebuilt every ~60s on
verified announces despite an unchanged tag set — now resubscribes only
when the tags actually change.
(Also merges origin/main: keychain test isolation #1413.)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix launch race: bridge reacts to the permission callback, retries cell-less
Field session 4: the launch-time location request ran before the CoreLocation
authorization callback delivered, so refreshChannels() silently no-opped
(it requires .authorized) and nothing ever retried — the bridge stayed
cell-less all session. Three layers now close it:
- a $permissionState sink re-enters refreshRendezvous the moment
authorization resolves (the fast path),
- the maintenance timer arms even without a cell and retries the full
rendezvous refresh (the backstop; it previously required a cell, which
made it useless for exactly this failure),
- flipping the bridge switch while never-asked triggers the location
prompt — that's the user-initiated moment for it.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* People sheet: one header style for every section; bridged people visible while own bridge is off
GroupChatList's header now uses the shared PeopleSectionHeader (glyph +
label, same size/padding as #mesh and across-the-bridge; keeps its key and
header trait). Bridge section and the header count are no longer gated on
this device's own toggle: bridged people arrive over passive radio from a
serving neighbor, and whoever is visible in the timeline belongs in the
sheet and the count.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* People sheet: equalize the first section's gap
MeshPeerList's first row kept a legacy 10pt top bump from when nothing sat
above it, and the outer VStack's 6pt inter-child spacing applied between
the #mesh header and the list but not inside the other sections. Both gone:
sections own their rhythm (header 12/4, rows 4), spacing 0 outside.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* People sheet: rows drop their leading glyphs — the section header carries the type
Mesh rows lose the per-state transport icon (connected/relayed/nostr/
offline), bridge rows the network glyph, group rows the person.3 icon.
Trailing state badges (star, lock, verified, unread, blocked, crown) stay,
and the row accessibility description still announces connection state, so
VoiceOver loses nothing.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Remove dead code left behind by the Settings|Info consolidation
Periphery (--strict) flagged five leftovers on this branch:
- LocationChannelsModel.setGatewayEnabled: the standalone internet-gateway
toggle is gone (the bridge switch drives internet sharing), so nothing
calls it; the gatewayEnabled published property stays for the header dot.
- AppInfoView Strings.Location title/enable/openSettings: the old Location
section's header and permission buttons no longer exist. Their orphaned
Localizable.xcstrings entries go with them (the gateway-toggle keys were
already pruned).
- BridgePeopleList's appTheme environment value was never read.
The sixth CI finding (PrekeyBundleStore.StoredBundle.noiseKey assign-only)
is a Periphery flake: the property is read in loadFromDisk, the finding
didn't reproduce locally or on the next CI run of unchanged code.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* People sheet: mesh rows get their transport glyph back
The mesh section is the one heterogeneous list — the leading icon encodes
HOW a peer is reachable (radio / relayed / nostr-only / offline), which the
header can't say. Bridge and group rows stay glyph-free.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix courier drop skipped by stale BLE reachability; periodic deposit sweep
Field test: a DM sent seconds after the recipient's radio vanished still
saw them as "reachable" (60s verified retention), so canDeliverPromptly
held, every deposit was skipped, and the message sat spooled with no retry
path. MessageRouter now sweeps its outbox every 2 minutes and publishes
bridge drops for messages whose recipient no transport can promptly reach;
the drop layer's message-ID dedup makes the sweep idempotent. Regression
test reproduces the exact field sequence.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Show "carried" when a message ships as a bridge drop
Field feedback: dropped DMs delivered but the sender saw nothing — the
drop path never fired onMessageCarried, and the recipient's delivery ack
has no radio route back until the peers next share a transport. depositDrop
now reports whether a fresh drop was sealed and the router marks the
message carried (📦) on both the send path and the sweep; the ack still
upgrades it to delivered whenever a route exists.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix locale word order: offline tag after name in DM header; localized "ago"
The private-chat header rendered the localized offline word in the
availability-glyph slot, before the name — "sin conexión bob". Offline now
shows the same dimmed person glyph the mesh list uses, with the word as a
small trailing tag after the name and lock, so it reads correctly in every
locale. Full sweep of views found one more composition bug: notice
timestamps glued English "ago" onto a localized duration; now the whole
phrase comes from RelativeDateTimeFormatter (same as the "fades" label).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* DM header offline state: icon only
The availability slot now reads uniformly as a glyph (radio / relayed /
globe / dimmed person), matching the mesh list; the text tag is gone.
VoiceOver still announces "offline" via the glyph's accessibility label.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Offline glyph: slashed antenna instead of dimmed person
Offline is now the visual negation of connected (same antenna glyph,
slashed) in both the DM header and mesh list rows; a generic person icon
didn't say "unreachable".
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>
* Isolate tests from the developer's real login keychain
Every test run prompted for the login keychain password (repeatedly,
since the xctest runner's code signature changes each build, so
"Always Allow" can never stick) and silently deleted the developer's
real Nostr identity via panic-mode tests.
Two holes let tests reach the real keychain:
- NostrIdentityBridge() defaulted to the real KeychainManager. Tests
inject mocks, but app-side constructions with no injection point
(LocationNotesManager's static bridge, GeohashPresenceService,
BoardManager, AppRuntime) read the real chat.bitchat.nostr item
when exercised under test.
- clearAllAssociations() used raw SecItem* calls that bypassed the
injected keychain entirely, so panicClearAllData tests wiped the
real Nostr identity items on every run.
Fix: centralize FavoritesPersistenceService's test-guarded in-memory
default as KeychainManager.makeDefault() and use it for all default
keychain parameters, and add deleteAll(service:) to
KeychainManagerProtocol so clearAllAssociations() goes through the
injected keychain like every other operation.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Share one in-memory test keychain per process (Codex P2)
A fresh store per makeDefault() call diverges from production, where
separate default-constructed bridges share chat.bitchat.nostr —
BoardManager's publish and NIP-09 delete paths would derive different
geohash identities under test. PreviewKeychainManager gains a lock
since the shared instance is reached from arbitrary threads.
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>
* Empty-mesh liveliness: nearby conversations, echoes, wave action, dead drops, radar
The empty mesh timeline was a dead end: a grey zero and "nobody in range
yet". This turns it into a live surface and gives the app pull when the
mesh wakes up:
- Nearest conversation: background geohash sampling now tracks actual
chat messages (not just presence) per regional channel; the empty state
surfaces the busiest nearby conversation with a preview, one tap to
join (GeohashChatActivityTracker, fed from GeoPresenceTracker).
- Echoes: the carried 6h store-and-forward window renders as dimmed
"heard here earlier" rows at launch (new Transport
collectArchivedPublicMessages -> GossipSyncManager snapshot, decoded
with signature-derived nicknames; content-identity dedup guards
against re-synced duplicates).
- Wave: the "bitchatters nearby" notification gains a "wave" quick
action that broadcasts a mesh 👋 straight from the notification, even
backgrounded (first UNNotificationCategory in the app).
- Dead drops: /drop pins a note to the current building geohash as a
kind-1 location note with a 24h NIP-40 expiry; expired notes are now
dropped client-side at ingest; the notices sheet shows "fades in Xh";
a "location notes" toggle plus location-permission controls live in
app info (also fixes the duplicated Voice section).
- Radar: an ambient sonar animation shows the radio scanning, with a
privacy-safe daily tally ("N devices passed within range today" via
salted per-day hashes) and a "notes left here" hint that opens the
notices geo tab.
All new user-facing strings ship in all 29 locales. 1403 tests green,
including new suites for the activity tracker, sightings tally, and
note expiry/drop publishing.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Review round: app-info polish, urgent/expiry parity, centered radar, pin fill, Codex P2s
- App info: LOCATION header uppercased like sibling sections; location
notes and live voice descriptions shortened (29 locales); redundant
"location access granted" line removed.
- Notices parity: urgent + expiry controls now show on the geo tab too;
the bridged Nostr note carries ["t","urgent"] and NIP-40 so relay-side
readers see both; urgent parsed back from incoming notes.
- Radar moved from the top of the empty state to the center of the chat
area, below the help text (empty state fills the visible height).
- Header pin fills whenever the scope has notices (was: only unseen),
and Nostr-only nearby notes now light it too.
- Codex P2 fixes: notification completion deferred until the wave action
is handled (background suspension dropped the send); NIP-40 notes now
prune on a timer when they expire while displayed; the location-notes
kill switch retargets the nearby-notes counter immediately.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Hide macOS segmented picker's built-in label in notices composer (duplicate 'expires in')
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Geo notes: permanent (∞) expiry default, urgent stays mesh-only
- Geo expiry picker gains ∞ as the default: a permanent note posts as a
pure relay note (no NIP-40 tag, no mesh-board copy — a board copy must
fade within days, contradicting the ∞ the user picked). 1/3/7d keep
the board + bridged-note path with NIP-40.
- The notes manager is now owned by the notices sheet (not the list) so
the composer local-echoes ∞ notes into the list; it revives via
refresh() after a tab-switch cancel, and its expiry-prune timer
survives cancel (weak self, dies with the instance).
- Urgent toggle returns to mesh-only per review — notes are ambient;
the read-side urgent-tag parse stays so tagged notes still render.
- macOS: hide the segmented picker's built-in label (duplicate
"expires in").
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Geo notes latency: EOSE scoped to reached relays, connecting state with auto-retry
Field finding: opening notices on a cold launch showed "no notices yet"
after ~10s, with notes popping in later — the empty state was a lie told
by two mechanisms:
- EOSE tracking waited on ALL target relays, including ones still
mid-Tor-circuit; one dead relay of five pinned "loading" until the
10s fallback. Trackers now count a relay only once the REQ actually
reached it (marked from the send completion, or proven by its EOSE),
so the first responding relay resolves the initial load and dropped
targets can't stall it. The 10s fallback stays as backstop.
- When that fallback fired with ZERO connected target relays (Tor still
bootstrapping), LocationNotesManager reported .ready with no notes.
It now enters a .connecting state — rendered as "connecting to
relays…" instead of the empty state — and polls every 3s, re-
subscribing for a fresh initial fetch the moment a target relay
comes up.
New NostrRelayManager.isAnyRelayConnected(among:) feeds the check via
an injectable dependency (tests default to legacy behavior). String
localized in all 29 locales. 1412 tests green, iOS+macOS builds clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Clearing the mesh timeline dismisses echoes for good; tighter divider copy
Triple-tap /clear emptied the timeline but the next launch re-seeded
"heard here earlier" from the persisted archive. A MeshEchoSettings
watermark now records the clear; only messages heard after it come back
(the archive itself still carries everything for peers' sync). The
echo dedup keys reset with it, and panic wipe drops the watermark.
Divider copy tightened to "heard here earlier · last 6h" (29 locales).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Mark EOSE relays at send initiation, closing the in-flight-send race
Codex P2 on #1411: with several sockets already connected, a fast
relay's EOSE could complete the tracker while a slower relay's async
send completion hadn't yet moved it out of awaitingSend — the initial
load reported done with that relay's stored events still pending.
Relays are now marked awaiting-EOSE synchronously when the REQ send is
initiated (and when a flush skips an already-subscribed relay), so
every relay that was actually asked is counted before any EOSE can
race. Failed sends resolve via the disconnect settle or the fallback.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Echoes visual polish: tinted history block, radar-captioned tally, ambient footer
Device-test feedback on the echoes screen:
- Archived echoes now sit on a subtle tinted background (secondary at
8%) in addition to the dim, so "heard here earlier" reads as one
distinct block; the divider carries the echo ID prefix to join it.
- "N devices passed within range today" moves out of the narration
lines to sit centered under the radar as its caption.
- When the timeline holds only echoes/system lines, a compact ambient
footer (small radar + tally + live hints) renders below the history
instead of the whole ambient layer vanishing.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Notes strip persists above the mesh chat; leaner empty-state narration
- The 📍 "notes left here" line was empty-state-only, so starting a
conversation hid it. It is now a tappable strip pinned above the mesh
timeline whenever unexpired notes exist at this place (opens the
notices geo tab); the nearby-notes counter runs for the whole mesh
timeline, not just the empty state.
- Empty state narration drops "nobody in range yet..." (the radar and
the sightings caption already say it) and the nearby-conversation
hint moves below the help line instead of splitting the narration.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Radar means searching: hide the sweep once mesh peers are connected or reachable
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Resolve leftover merge conflict markers from the main restack
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Drop two Nostr helper constants resurrected by the restack merge (dead on main)
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>
* Empty-mesh liveliness: nearby conversations, echoes, wave action, dead drops, radar
The empty mesh timeline was a dead end: a grey zero and "nobody in range
yet". This turns it into a live surface and gives the app pull when the
mesh wakes up:
- Nearest conversation: background geohash sampling now tracks actual
chat messages (not just presence) per regional channel; the empty state
surfaces the busiest nearby conversation with a preview, one tap to
join (GeohashChatActivityTracker, fed from GeoPresenceTracker).
- Echoes: the carried 6h store-and-forward window renders as dimmed
"heard here earlier" rows at launch (new Transport
collectArchivedPublicMessages -> GossipSyncManager snapshot, decoded
with signature-derived nicknames; content-identity dedup guards
against re-synced duplicates).
- Wave: the "bitchatters nearby" notification gains a "wave" quick
action that broadcasts a mesh 👋 straight from the notification, even
backgrounded (first UNNotificationCategory in the app).
- Dead drops: /drop pins a note to the current building geohash as a
kind-1 location note with a 24h NIP-40 expiry; expired notes are now
dropped client-side at ingest; the notices sheet shows "fades in Xh";
a "location notes" toggle plus location-permission controls live in
app info (also fixes the duplicated Voice section).
- Radar: an ambient sonar animation shows the radio scanning, with a
privacy-safe daily tally ("N devices passed within range today" via
salted per-day hashes) and a "notes left here" hint that opens the
notices geo tab.
All new user-facing strings ship in all 29 locales. 1403 tests green,
including new suites for the activity tracker, sightings tally, and
note expiry/drop publishing.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Review round: app-info polish, urgent/expiry parity, centered radar, pin fill, Codex P2s
- App info: LOCATION header uppercased like sibling sections; location
notes and live voice descriptions shortened (29 locales); redundant
"location access granted" line removed.
- Notices parity: urgent + expiry controls now show on the geo tab too;
the bridged Nostr note carries ["t","urgent"] and NIP-40 so relay-side
readers see both; urgent parsed back from incoming notes.
- Radar moved from the top of the empty state to the center of the chat
area, below the help text (empty state fills the visible height).
- Header pin fills whenever the scope has notices (was: only unseen),
and Nostr-only nearby notes now light it too.
- Codex P2 fixes: notification completion deferred until the wave action
is handled (background suspension dropped the send); NIP-40 notes now
prune on a timer when they expire while displayed; the location-notes
kill switch retargets the nearby-notes counter immediately.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Hide macOS segmented picker's built-in label in notices composer (duplicate 'expires in')
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Geo notes: permanent (∞) expiry default, urgent stays mesh-only
- Geo expiry picker gains ∞ as the default: a permanent note posts as a
pure relay note (no NIP-40 tag, no mesh-board copy — a board copy must
fade within days, contradicting the ∞ the user picked). 1/3/7d keep
the board + bridged-note path with NIP-40.
- The notes manager is now owned by the notices sheet (not the list) so
the composer local-echoes ∞ notes into the list; it revives via
refresh() after a tab-switch cancel, and its expiry-prune timer
survives cancel (weak self, dies with the instance).
- Urgent toggle returns to mesh-only per review — notes are ambient;
the read-side urgent-tag parse stays so tagged notes still render.
- macOS: hide the segmented picker's built-in label (duplicate
"expires in").
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Clearing the mesh timeline dismisses echoes for good; tighter divider copy
Triple-tap /clear emptied the timeline but the next launch re-seeded
"heard here earlier" from the persisted archive. A MeshEchoSettings
watermark now records the clear; only messages heard after it come back
(the archive itself still carries everything for peers' sync). The
echo dedup keys reset with it, and panic wipe drops the watermark.
Divider copy tightened to "heard here earlier · last 6h" (29 locales).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Echoes visual polish: tinted history block, radar-captioned tally, ambient footer
Device-test feedback on the echoes screen:
- Archived echoes now sit on a subtle tinted background (secondary at
8%) in addition to the dim, so "heard here earlier" reads as one
distinct block; the divider carries the echo ID prefix to join it.
- "N devices passed within range today" moves out of the narration
lines to sit centered under the radar as its caption.
- When the timeline holds only echoes/system lines, a compact ambient
footer (small radar + tally + live hints) renders below the history
instead of the whole ambient layer vanishing.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Notes strip persists above the mesh chat; leaner empty-state narration
- The 📍 "notes left here" line was empty-state-only, so starting a
conversation hid it. It is now a tappable strip pinned above the mesh
timeline whenever unexpired notes exist at this place (opens the
notices geo tab); the nearby-notes counter runs for the whole mesh
timeline, not just the empty state.
- Empty state narration drops "nobody in range yet..." (the radar and
the sightings caption already say it) and the nearby-conversation
hint moves below the help line instead of splitting the narration.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Radar means searching: hide the sweep once mesh peers are connected or reachable
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>
Periphery 3.7.4 audit of both schemes (macOS + iOS, intersected so
platform-specific code is never touched), with test targets indexed and
the share extension built. 277 dead declarations removed or demoted:
dead forwarding wrappers (ChatViewModel+Nostr/+PrivateChat), removed-
feature remnants (autocomplete command suggestions, back-swipe tuning,
MediaSendError, GeohashParticipantTracker), unused Tor dormancy
bindings, assign-only properties, unused parameters (renamed to _), and
redundant public accessibility. 13 orphaned localization keys deleted
across all 29 locales (old pre-#1392 location-notes UI, app_info
warnings).
Two real tests were flagged as unused because they never ran: Swift
Testing methods missing @Test (NostrProtocolTests.
testAckRoundTripNIP44V2_Delivered, NotificationStreamAssemblerTests.
testAssemblesCompressedLargeFrame). Re-armed both; they pass.
Deliberately kept, now recorded in .periphery.baseline.json: iOS-only
code invisible to the CI macOS scan, C FFI signatures, keep-alive
NWPathMonitor reference, InboundEventKey.eventID (dedup semantics),
wifiBulk capability bit (reserved for Wi-Fi bulk work, used by
BitFoundation package tests), and the String secureClear cluster
(exercised by package tests).
New: .periphery.yml config and an advisory Dead Code CI job (mirrors
the SwiftLint precedent from #1361) that fails on findings not in the
committed baseline.
Verified: full macOS app suite, BitFoundation (119) and BitLogger (13)
package tests green; periphery scan --strict exits clean.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Require signed sender for broadcast file transfers (#1406 follow-up)
Broadcast file transfers trusted the packet's claimed senderID whenever
the peer was merely connected (resolveKnownPeer allowConnectedUnverified:
true), unlike public messages and public voice frames, which both require
a valid packet signature from the claimed sender.
Codex flagged the consequence on PR #1406: a peer that observed a public
voice burst could broadcast a spoofed voice_<burstID>.m4a note under the
talker's senderID, and ChatLiveVoiceCoordinator.absorbFinalizedVoiceNote
would replace the signature-verified live bubble with attacker audio
(senderPeerID + scope were the only bindings, both attacker-forgeable on
this path).
Bring broadcast file transfers up to the same bar as public messages:
verify the packet signature against the registry signing key, falling
back to the persisted-identity signature lookup, before trusting the
sender. Directed (private) transfers keep the lenient connected-peer path
— they are addressed to us specifically and carry no broadcast exposure.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Exempt self broadcasts from the file-transfer signature gate
Review of #1407 caught a regression: our own broadcast files replayed via
gossip sync arrive with ttl==0 (so isSelfEcho does not drop them) and
cannot be verified against the peer registry or identity cache, so the new
broadcast signature guard would drop them. Mirror BLEPublicMessageHandler's
self exemption — self packets are trivially authentic — and add a
regression test.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Stop relaying broadcast file packets that fail sender authentication
Codex review on #1407: the new signature gate dropped spoofed broadcast
files locally, but BLEService's .fileTransfer case still fell through to
scheduleRelayIfNeeded, so a forged file kept propagating to downstream
(possibly older, ungated) nodes. Have the handler report failed sender
authentication and skip the relay step, like invalid board posts and
voice frames. Local-only drops (malformed payload, quota, save failure)
and files directed to other peers still relay unchanged.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix CI hang: sign the max-size reassembly file transfer, unhang timeouts
Both CI runs on #1407 died at the 5-minute watchdog (SIGKILL, exit 137)
with the test process fully idle. Root cause was a pair of issues in
FragmentationTests:
- "Max-sized file transfer survives reassembly" injected an UNSIGNED
broadcast file from an unknown peer, which the new broadcast
signature gate now drops by design. Sign the packet and preseed the
sender's signing key, mirroring the public-message reassembly tests.
- CaptureDelegate's wait helpers could never time out: the timeout task
threw, but withThrowingTaskGroup then awaited the sibling child that
was parked in a non-cancellable withCheckedContinuation, deadlocking
the whole run (hang instead of a 5s failure). Resume the parked
continuation from a cancellation handler so timeouts now fail fast.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* Make image tap-to-reveal a Button so the DM sheet can't swallow it
Received images in a DM rendered as a grey "tap to reveal" box that
never revealed: the DM sheet wraps the whole conversation in a
high-priority swipe-to-close DragGesture (ContentSheetViews), and an
ancestor high-priority gesture starves descendant TapGestures — the
image's reveal/open tap never fired. Button actions survive that
suppression (the sheet's own header buttons work for the same reason),
so the tap now lives on a plain-style Button wrapping the image;
swipe-to-hide stays attached as a simultaneous gesture.
Fixes#1388
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Move the cancel control out of the reveal Button
Nested buttons don't get reliable independent hit testing, and the
outer reveal tap is a no-op while sending, so the in-flight cancel x
could become untappable. The cancel overlay now sits on the Button
rather than inside its label.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Root cause: received media stuck in .sending — grey box, dead tap
Field testing showed the Button conversion alone didn't fix#1388: a
received DM image still rendered as a flat grey box with a dead tap.
The real culprit is BitchatMessage's initializer, which defaults every
private message without an explicit status to `.sending`.
BLEFileTransferHandler built incoming media messages without one, so
every received private image/voice note was permanently "sending":
mediaSendState returned progress 0 → BlockRevealMask rendered 0% of
the image (the flat grey box is the blur overlay over an empty mask),
and the reveal tap was disabled by the isSending guard — regardless of
which gesture carried it.
Two layers:
- BLEFileTransferHandler now stamps incoming private media
`.delivered(to: <local nickname>, at: <packet time>)`, matching the
received-text path in ChatPrivateConversationCoordinator.
- MediaMessageView treats received messages as never-sending, so no
other construction path can reproduce the grey-box state.
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>
* Heal peer-ID rotation: rebind link on verified announce, retire ghost
When a peer relaunches it rotates its ephemeral peer ID, but a
still-open BLE connection kept its stale peripheral/central→peerID
binding for the reachability retention window (~45-60s). Until it aged
out, the other side showed a duplicate ghost peer and dropped the
rotated peer's direct announces as spoofing attempts.
Root cause: the ingress guard rejected a direct announce whose claimed
sender differed from the link binding before signature verification
could ever see it, so the binding could never heal.
- Ingress guard: let a mismatched direct announce through, attributed
to the claimed sender; REQUEST_SYNC keeps the strict binding check.
- Bind sites: raw (pre-verification) announces may only bind unbound
links, never rebind bound ones — rebinding now requires the announce
handler's signature verification to pass.
- On a verified direct announce whose ingress link is bound to a
different peer, rebind the link to the announced ID and retire the
rotated-away ID immediately (registry + gossip + UI), mirroring
handleLeave.
- BLELinkStateStore.bindPeripheral: drop the previous peer's reverse
mapping on rebind so the retired ID no longer claims the link.
Fixes#1387
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Contain forged-directness rebinds: no identity steal, per-link cooldown
The announce signature does not authenticate directness (TTL is
excluded from signing because relays mutate it), so a bound peer could
replay another peer's fresh signed announce with its TTL restored and
reach the rotation rebind path. Contain what such a replay can do:
- Refuse a rebind when the claimed identity already owns another live
link — a replayed announce can no longer steal a connected peer's
binding or route its directed traffic to the replaying link.
- Allow at most one rebind per link per cooldown window (60s) so two
identities cannot fight over a link in a replay flip-flop, with each
flip retiring the other peer.
A replay against an identity with no live link remains possible, but
that capability already exists today on unbound links, where any raw
direct announce binds pre-verification.
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>
* Live push-to-talk voice for DMs: stream while you talk, voice note as fallback
Holding the mic in a DM now streams AAC frames live over the Noise session
(walkie-talkie style, ~0.5s mouth-to-ear at one hop) while recording the same
audio as a normal voice note. On release the note ships through the existing
fileTransfer pipeline; receivers that heard the live stream absorb it silently
into the same bubble (matched by the burst ID embedded in the file name), so
reliability comes for free and nobody sees duplicates.
Protocol:
- NoisePayloadType.voiceFrame = 0x08 carrying VoiceBurstPacket
(burstID + seq + START/data/END/CANCELED, length-prefixed AAC frames)
- 210-byte burst-content budget keeps each Noise packet inside the 256-byte
padding bucket: one BLE frame, never the fragment scheduler
- fire-and-forget: frames are dropped (never queued) without an established
session; live is only offered when the peer is mesh-reachable
Receive:
- ChatLiveVoiceCoordinator assembles bursts (jitter-ordered, 0.5s gap skip,
3s idle end, flood/size caps), persists progressively as ADTS .aac so even
a partial burst is a replayable bubble
- live autoplay only when the conversation is on screen, app active, and the
new app-info "live voice messages" toggle is on (also gates live sending)
- one-playback-at-a-time via a shared ExclusivePlayback slot
Capture:
- PTTCaptureEngine taps AVAudioEngine, dual-encodes: live AAC frames + the
finalized .m4a (same 16kHz/mono/16kbps settings as VoiceRecorder)
- VoiceRecordingViewModel now drives a pluggable VoiceCaptureSession; the
composer HUD shows a pulsing LIVE treatment when streaming
Includes the push-to-talk design doc, 6 new localization keys across all 29
locales, and unit tests for framing, packetizer budget, ADTS output, codec
round-trip, and the assembly/absorb lifecycle. Public-mesh PTT (MessageType
0x29) lands separately on top of this.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Public-mesh push-to-talk: signed live voice bursts in the mesh channel
Extends live PTT from DMs to the public mesh timeline. Holding the mic in
the mesh channel now broadcasts the burst live as signed voiceFrame packets
(MessageType 0x29) while the finalized voice note still ships on release —
new clients hear you as you speak and absorb the note silently into the live
bubble; old clients (and late joiners) keep receiving the note exactly as
before, so mixed-version meshes lose nothing.
Wire/relay:
- MessageType.voiceFrame = 0x29: ephemeral signed broadcast, never
gossip-synced (SyncTypeFlags maps it to no bit), never padded (padding to
the 512 block would push every ~490-byte signed packet into fragmentation)
- RelayController treats voiceFrame like media fragments: dense-graph TTL
clamp contains the sustained ~15 pkt/s per-talker stream, tight 8-25 ms
jitter keeps multi-hop latency inside the receiver's 350 ms jitter buffer
- inbound gate mirrors public messages: broadcast-only, 30 s freshness cap,
packet signature verified against the claimed sender's announce before any
audio reaches the UI
App:
- ChatLiveVoiceCoordinator gains burst scopes: public bubbles land in the
mesh timeline, autoplay only while that timeline is on screen, and the
finalized-note absorb is scope-bound (a public note can't replace a DM
burst or vice versa)
- floor courtesy: while someone talks live in the public channel the
composer mic tints red and pulses, with an accessibility value naming the
talker ("%@ is speaking", localized in all 29 locales); holding still
works — a decentralized mesh has no floor arbiter, the tint just
discourages talk-over
Tests: relay policy (sparse cap + dense clamp), public bubble + talker
indicator lifecycle, note absorption into the mesh store, and scope-binding
rejection; full suite green (1382 tests).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* PTT follow-ups from review + field test: peer-ID normalization, toggle gates inbound, drop-path diagnostics
Codex review fixes (#1403):
- makeVoiceCaptureSession normalizes the selected peer with toShort() before
the reachability/session checks and binds the send target to that same
routing ID — a conversation selected under the stable 64-hex Noise key no
longer silently falls back to a classic note while the short-ID session is
established
- the live-voice toggle now gates inbound bursts too: off means
classic-notes-only in both directions (no live bubble, partial file, or
early notification; the finalized note still arrives), with a test
Field-test diagnostics (first device run: DM frames decrypted but no bubble
appeared, with no log evidence of which guard dropped them):
- coordinator logs undecodable frames (size + hex prefix) and blocked drops
- makeAssembly logs directory/file-handle failures instead of returning nil
silently
- PTTLiveVoiceSession logs capture start and finish (packet/frame/duration
counts); PTTCaptureEngine logs engine start success/failure with the input
format; BLEService.sendVoiceFrame logs no-session drops
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix iPhone live-capture failure: dead input unit (AURemoteIO -10851, 0 Hz)
Field testing showed the phone's live capture failing at mic enable with
AURemoteIO -10851 and an input format of 0 Hz / 2 ch — an input unit bound
to an earlier (playback-only or settling) audio session. The Mac, which has
no session lifecycle, captured fine, which is why public bursts from the Mac
worked while phone-side sends degraded from working (first hold) to sporadic
to dead across holds.
Three layers of defense:
- PTTCaptureEngine recreates its AVAudioEngine on every start(), after the
session is configured, so the input unit binds to the session that is
active now; a dead input (0 Hz or 0 channels) is now a distinct, logged
error instead of a silent setup failure
- PTTLiveVoiceSession retries the capture start once after a 150 ms
route-settle pause
- VoiceRecordingViewModel falls back to the classic VoiceRecorder within the
same hold if the live engine still cannot start — a route glitch now costs
the live stream, never the voice note
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Blue mic when the hold will stream live
The mic button now shows readiness at a glance — and doubles as a build
marker for device testing:
- blue: holding will stream live (DM peer reachable with an established
Noise session, or the public mesh channel)
- accent (orange in DMs): holding records a classic voice note (no session
yet, peer unreachable, or live voice toggled off)
- red states unchanged (recording, floor busy)
Refactors capture-backend selection into a single liveVoiceTarget() so the
indicator and makeVoiceCaptureSession can never disagree.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Revert the blue live-ready mic to the normal accent color
The build-verification marker did its job; idle mic color goes back to the
accent. The LIVE recording HUD remains the signal for whether a hold is
streaming. Keeps the liveVoiceTarget() refactor so backend selection stays
in one place.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Leave a trace on every mic press and every inbound-frame drop
Field testing read "tap does nothing" as breakage: the mic start is async
(permission check + engine spin-up), so releasing before recording begins
has always been a silent cancel — for classic voice notes too. Every press
now logs which backend it chose and, for quick presses, that it released
before recording started.
Also logs the two remaining silent drops: inbound voice frames rejected by
the live-voice toggle (the one unlogged guard left in the receive path) and
the classic-note fallback now includes the toggle state.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix mic hold dying instantly in DMs: sheet swipe gesture starved the composer
Field logs showed every DM mic hold ending 3-10 ms after it began, on both
platforms, while public-channel holds worked — the private sheet wraps its
entire content (composer included) in a high-priority swipe-right-to-leave
DragGesture, and a high-priority ancestor drag cancels the mic button's
press-and-hold within milliseconds. Same starvation mechanism as the DM
image-reveal bug (#1402), hitting a drag instead of a tap.
The swipe-to-leave gesture now lives on the message list only, so the
composer's gestures (mic hold, text field, buttons) are out of its reach and
the swipe still works where users actually swipe.
Also stops touching the capture engine when a hold cancels before the engine
ever started: probing inputNode on a never-started engine instantiates its
input unit against whatever session is active and spams benign-but-alarming
AURemoteIO -10851 errors into field logs.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Reorder app info sheet: usage first, then settings, then reference
New section order: HOW TO USE, then the adjustable bits (appearance, voice,
network), then the reference material (features, privacy, symbols legend).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* App info: flow HOW TO USE into one paragraph; "list" and "person" wording
The six how-to-use bullets now read as a single comma-separated paragraph
(same instruction strings, legacy bullet prefix stripped at render). Two
wording updates across all 29 locales: the people icon opens the "list"
(not "sidebar"), and you tap a "person's" name (not a "peer's") to start
a DM.
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>
* Live push-to-talk voice for DMs: stream while you talk, voice note as fallback
Holding the mic in a DM now streams AAC frames live over the Noise session
(walkie-talkie style, ~0.5s mouth-to-ear at one hop) while recording the same
audio as a normal voice note. On release the note ships through the existing
fileTransfer pipeline; receivers that heard the live stream absorb it silently
into the same bubble (matched by the burst ID embedded in the file name), so
reliability comes for free and nobody sees duplicates.
Protocol:
- NoisePayloadType.voiceFrame = 0x08 carrying VoiceBurstPacket
(burstID + seq + START/data/END/CANCELED, length-prefixed AAC frames)
- 210-byte burst-content budget keeps each Noise packet inside the 256-byte
padding bucket: one BLE frame, never the fragment scheduler
- fire-and-forget: frames are dropped (never queued) without an established
session; live is only offered when the peer is mesh-reachable
Receive:
- ChatLiveVoiceCoordinator assembles bursts (jitter-ordered, 0.5s gap skip,
3s idle end, flood/size caps), persists progressively as ADTS .aac so even
a partial burst is a replayable bubble
- live autoplay only when the conversation is on screen, app active, and the
new app-info "live voice messages" toggle is on (also gates live sending)
- one-playback-at-a-time via a shared ExclusivePlayback slot
Capture:
- PTTCaptureEngine taps AVAudioEngine, dual-encodes: live AAC frames + the
finalized .m4a (same 16kHz/mono/16kbps settings as VoiceRecorder)
- VoiceRecordingViewModel now drives a pluggable VoiceCaptureSession; the
composer HUD shows a pulsing LIVE treatment when streaming
Includes the push-to-talk design doc, 6 new localization keys across all 29
locales, and unit tests for framing, packetizer budget, ADTS output, codec
round-trip, and the assembly/absorb lifecycle. Public-mesh PTT (MessageType
0x29) lands separately on top of this.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* PTT follow-ups from review + field test: peer-ID normalization, toggle gates inbound, drop-path diagnostics
Codex review fixes (#1403):
- makeVoiceCaptureSession normalizes the selected peer with toShort() before
the reachability/session checks and binds the send target to that same
routing ID — a conversation selected under the stable 64-hex Noise key no
longer silently falls back to a classic note while the short-ID session is
established
- the live-voice toggle now gates inbound bursts too: off means
classic-notes-only in both directions (no live bubble, partial file, or
early notification; the finalized note still arrives), with a test
Field-test diagnostics (first device run: DM frames decrypted but no bubble
appeared, with no log evidence of which guard dropped them):
- coordinator logs undecodable frames (size + hex prefix) and blocked drops
- makeAssembly logs directory/file-handle failures instead of returning nil
silently
- PTTLiveVoiceSession logs capture start and finish (packet/frame/duration
counts); PTTCaptureEngine logs engine start success/failure with the input
format; BLEService.sendVoiceFrame logs no-session drops
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix iPhone live-capture failure: dead input unit (AURemoteIO -10851, 0 Hz)
Field testing showed the phone's live capture failing at mic enable with
AURemoteIO -10851 and an input format of 0 Hz / 2 ch — an input unit bound
to an earlier (playback-only or settling) audio session. The Mac, which has
no session lifecycle, captured fine, which is why public bursts from the Mac
worked while phone-side sends degraded from working (first hold) to sporadic
to dead across holds.
Three layers of defense:
- PTTCaptureEngine recreates its AVAudioEngine on every start(), after the
session is configured, so the input unit binds to the session that is
active now; a dead input (0 Hz or 0 channels) is now a distinct, logged
error instead of a silent setup failure
- PTTLiveVoiceSession retries the capture start once after a 150 ms
route-settle pause
- VoiceRecordingViewModel falls back to the classic VoiceRecorder within the
same hold if the live engine still cannot start — a route glitch now costs
the live stream, never the voice note
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 private-chat sheet wraps its entire content — composer included — in a
high-priority swipe-right-to-leave DragGesture. A high-priority ancestor
drag preempts child gestures, so the composer mic's press-and-hold was
cancelled 3-10 ms after touch-down (observed on both iOS and macOS in field
logs), making voice notes unrecordable inside DMs while working fine in the
public timeline. Same starvation mechanism as the DM image-reveal bug
(#1402), hitting a drag instead of a tap.
The swipe-to-leave gesture now attaches to the message list only — where
users actually swipe — leaving the composer's gestures (mic hold, text
field, buttons) out of its reach.
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
The gateway globe indicator was a plain Image with a tooltip but no tap
handler. Wrap it in a Button that opens the location channels sheet,
where the gateway toggle lives, so tapping it lets people turn the
gateway on or off. Adds an accessibility hint localized into all 29
locales.
When the header got crowded with indicator icons, the bitchat/ logo and
the nickname field both sat at layout priority 0, so compression was
split arbitrarily between them — and the logo, lacking a lineLimit,
wrapped to two lines inside the fixed-height bar. Make the degradation
order explicit: the nickname shrinks first, the logo holds full width
until the name is gone and then truncates on one line, and the icon
cluster (priority 3) never compresses.
Render-verified with an offscreen ImageRenderer harness at 320/375/500pt
with the maximum icon load (globe, courier, envelope, pin, bookmark).
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
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>
* Make peer lists accessible and actionable; block by stable identity
Who you can reach — the app's most important fact — was encoded in
unlabeled 10pt icons with macOS-only tooltips, and the mesh list had no
actions (block/favorite/verify were slash-command-only).
- Both peer lists become real accessibility citizens: each row is one
element announcing name, reachability, and favorite/unread/blocked
state, with a button trait and custom actions for the gesture-only
interactions. Neither file previously had a single accessibility
modifier. Reachability icons gain tooltips reusing existing strings;
teleported vs in-area pins are explained.
- Mesh rows gain the context menu the geohash list already had: direct
message, favorite, show fingerprint, block/unblock. The fingerprint
double-tap, previously shadowed by the single tap, is reordered so it
fires.
- The DM header's offline state (previously EmptyView — absence of a
glyph as the only signal) becomes a dimmed "offline" tag, and a
geohash DM — always Nostr-routed — no longer mislabels itself
"offline".
- App Info gains a SYMBOLS legend defining every glyph the lists and
headers use; nothing defined them before.
- Mesh block/unblock now resolve by the peer's stable Noise identity
instead of a `/block <displayName>` string, so the exact tapped row is
affected and offline peers can be unblocked (with covering tests).
New strings are added source-language (en) only.
* Surface block/unblock feedback in the conversation where it was triggered
setMeshPeerBlocked silently returned when the peer's identity could not
be resolved (e.g. long-press-blocking an old public message from a
sender who left and was never a favorite), where the /block command
printed "cannot block X: not found or unable to verify identity" — post
that same message from the guard branch.
Both the failure and confirmation messages now route through
addCommandOutput instead of addSystemMessage, so blocking from inside a
private chat prints into that chat rather than invisibly into the
public timeline (same routing #1363 applied to command output).
The confirmation also reuses the /block wording ("blocked X. you will
no longer receive messages from them") for parity with the command.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Remove dead accessibility label and unreachable /unblock fallback
The favorite button's .accessibilityLabel in MeshPeerList is
unreachable: the row-level .accessibilityElement(children: .ignore)
swallows child elements, and the row's custom accessibility action
already covers favoriting.
ConversationUIModel.unblock is only called from the mesh peer list with
a non-optional mesh peerID, so the "/unblock <name>" fallback branch
could never run — take PeerID directly and drop the branch.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: jack <212554440+jackjackbits@users.noreply.github.com>
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Improve message-list interactions: empty-state guidance, jump-to-latest, per-message actions
Three usability gaps in the message list, all presentation-layer:
- Empty timeline was a blank screen. It now narrates itself in dim,
terminal-styled lines: what the channel is, that it's waiting for
peers, and where the channel switcher and help live. Disappears with
the first message.
- Scrolled up in a busy channel, nothing signalled that new messages
arrived and there was no way back. A small "jump to latest" pill now
appears while scrolled up, counting messages that arrived below, and
taps back to the newest via the existing scroll helper. The unseen
count re-baselines on channel switch so a cross-channel count delta is
never shown as "new".
- A single tap anywhere on a message overwrote the composer draft with
"@sender " and force-focused the field — casual taps while reading
destroyed drafts. That whole-row tap is removed; mention/DM/hug/slap/
block now live in the per-message context menu (reusing the handlers
the existing action sheet already calls), and mention appends to the
draft rather than replacing it. A failed own private message gets a
resend item. The triple-tap-to-clear gesture gains a confirmation.
New strings are added source-language (en) only.
* Remove the failed original when resending a private message
Resend re-submitted the content but left the red failed bubble in
place, so every tap stacked another copy under it. Route resend
through ConversationUIModel, which drops the failed original from the
conversation store (removePrivateMessage) before sending the new copy.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Count only rendered human messages in the jump-to-latest pill
The unseen count was a raw delta of the messages array, so system
lines (join/leave narration) and whitespace-only messages that never
render as rows inflated the "N new" pill. Baseline the counters
against the number of messages that render as human message rows,
using the same predicates the row builder applies.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Hide mention/DM context-menu actions inside 1:1 conversations
In a private conversation, mentioning the only other participant is
noise and the DM action just reopens the already-open conversation
(toggling the sidebar). Gate both behind privatePeer == nil so the
public-timeline context menu is unchanged; hug/slap/block/copy/resend
remain in DMs.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: jack <212554440+jackjackbits@users.noreply.github.com>
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Require confirmation before deleting a received image; label media controls
Double-tapping a received image permanently deleted the message and its
file — no confirmation, no undo — while double-tap is the most ingrained
photo gesture on mobile, and it raced the reveal tap via
`.exclusively(before:)`. A mesh may never re-deliver that image, so an
accidental double-tap can destroy the only copy.
- Remove the double-tap-to-delete gesture. Delete moves into a
long-press context menu behind a confirmation dialog ("this cannot be
undone — the sender may not be in range to send it again"), alongside
explicit open and hide-image actions (the swipe-to-re-blur was
undiscoverable). Taps now only reveal and open.
- The blur overlay says "tap to reveal" instead of a bare eye-slash.
- Add the first accessibility support to these media views: labeled
image states (hidden/revealed/sending) with custom actions, labeled
voice play/pause with the duration as the value, and labeled cancel
buttons.
Delete remains available and its underlying behavior is unchanged — it's
just gated. New strings are added source-language (en) only.
* Expose the in-flight cancel button to VoiceOver
The image tile uses accessibilityElement(children: .ignore), which
collapses the whole subtree — including the visible cancel button shown
while a send is in flight — into one element. VoiceOver users could not
cancel an in-progress image send. Add a cancel accessibility action for
the sending state.
* Mark the accessibility delete action destructive too
The context-menu delete already uses role: .destructive; the matching
accessibility action did not. Make them consistent.
* Deduplicate image actions and align accessibility labels with convention
Extract the open/hide/delete button set shared by the context menu and
accessibilityActions into a single @ViewBuilder so the two can't drift.
Move the interaction hints out of the accessibility labels into
accessibilityHint (labels stay nouns; "tap to reveal" was wrong for
VoiceOver activation anyway), and rename the blurred-state action to
"reveal image" since it reveals rather than opens.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Offer cancel-send in the context menu while an image is sending
The context menu body was empty during sends, which some OS versions
still present as an empty preview. The accessibility path already
exposed a cancel-send action in that state; share the same button with
the context menu so pointer/touch users get a cancel path too.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Label broken images honestly and drop actions that need the file
When the image file fails to load, the placeholder kept the "hidden
image"/"image" accessibility label with a reveal/open hint, and the
context menu still offered open/reveal on a URL that will not load.
Track the failed load, announce "image unavailable" with no interaction
hint, show a broken-photo glyph instead of an endless spinner, disable
the reveal/open gestures, and drop open/hide/reveal from the context
menu and accessibility actions -- keeping delete so received broken
attachments can still be cleaned up.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: jack <212554440+jackjackbits@users.noreply.github.com>
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Give private DMs an unmistakable visual signature
An open DM renders identically to the public room — same view, same
green-on-black surface, with a small header name and two orange icons
as the only cues. For this audience the cost of misreading "am I in the
encrypted DM or the public channel?" is severe: sensitive text typed
into the wrong composer.
Four presentation-layer cues; no formatter or cache changes:
- The composer placeholder states the destination instead of a generic
prompt: "message @jack — private" in a DM, "message #mesh — public,
nearby" on mesh, "message #9q8yy — public" in a geohash channel.
- A persistent lock caption sits above the DM composer. It reads
"private · end-to-end encrypted" only once the Noise session is
actually secured or verified, and "private conversation" before that
— the caption must not overstate encryption mid-handshake.
- The DM sheet header carries a faint orange wash (6%), extending the
existing orange self-accent to the chrome.
- Each private message row is prefixed with a small orange lock glyph
(view-layer, hidden from VoiceOver — the caption carries the
semantic; the cached AttributedString formatter is untouched).
New strings are added source-language (en) only.
* Fix geohash-DM caption and placeholder
Two carve/review follow-ups:
- The privacy caption showed "private conversation" for geohash DMs,
implying they are not encrypted — but geohash DMs are NIP-17
gift-wrapped (always end-to-end encrypted), they just carry no Noise
session status. Show the encrypted caption for geohash DMs and for
secured Noise sessions; the pre-secured wording now applies only while
a mesh handshake is still in progress.
- The private-chat placeholder prepended "@" to the partner name, which
for a geohash DM (whose display name is already "#geohash/@name")
produced a doubled "@". The "@" is now added only for mesh nicknames.
* Make the DM header orange wash visible in the matrix theme
The 6% orange background was chained after .themedSurface(), so in the
default matrix theme (whose themedSurface paints an opaque background)
the wash sat behind the surface and never rendered — it was only
visible in liquid glass. Apply the orange tint before .themedSurface()
so it layers in front of the themed background.
* Align DM lock glyph across text and media rows; keep header wash visible under glass
Media rows in a private conversation now get the same leading lock
glyph as text rows, so left edges line up instead of misaligning by
the glyph's width. The DM header's orange wash gets a higher opacity
under the liquid-glass theme, where themedSurface() adds no opaque
backing and 6% orange disappears into the backdrop gradient. Also
drops the dead sender != "system" guard in TextMessageView — system
messages are routed to systemMessageRow before this view is built.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Remove orphaned content.input.message_placeholder from the string catalog
The destination-stating placeholders replaced its last code reference;
nothing on the branch resolves this key anymore.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: jack <212554440+jackjackbits@users.noreply.github.com>
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Make private-message delivery status legible and accessible
The delivery indicator is the most stress-relevant signal in an
off-grid messenger, but it is hard to read:
- The status glyphs are 10pt icons whose only explanation is a
`.help()` tooltip, which does not exist on iOS.
- Delivered vs read is the same double-checkmark distinguished only by
colour.
- No case carries an accessibility label, so VoiceOver announces
nothing.
- Two failure reasons ("Not delivered", "Encryption failed") bypass the
localized reason catalog and are hardcoded English.
Changes (presentation only; the DeliveryStatus enum and the
contract-tested `displayText` are untouched):
- Add `DeliveryStatus.bitchatDescription`, a localized app-layer
description, used as the macOS tooltip, a VoiceOver label on every
status glyph, and — on iOS, where tooltips don't exist — a
tap-to-reveal caption under the message.
- Failure reasons stay visible as a red caption without a tap.
- Read vs delivered is now legible without colour: read uses
filled-circle checkmarks.
- Route the two hardcoded failure reasons through the localized catalog.
New strings are added source-language (en) only.
* Show the failure reason on failed media messages too
TextMessageView gained a visible red failure caption (the status
glyph's .help() tooltip does not exist on iOS), but MediaMessageView
still rendered the bare glyph — so a failed voice-note or image send
showed only a 10pt red triangle with no reason on iOS. Add the same
failure caption to media messages.
* Collapse revealed delivery detail when the status changes
A caption revealed while a message was "sending" stayed open and
silently morphed through later statuses (sent, delivered, read).
Reset showDeliveryDetail when the snapshotted DeliveryStatus changes.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Add tap-to-reveal delivery detail to media rows
Media rows showed the same delivery glyphs as text rows but offered no
way to explain them on iOS, where .help() tooltips don't exist. Mirror
the text-row pattern: the glyph is now a button that reveals the
localized status caption below the header, failure reasons stay
visible without a tap, and the revealed caption collapses when the
status advances.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Localize the remaining voice-note failure reasons
ChatMediaTransferCoordinator still passed hardcoded English reasons
into .failed(reason:), which now surface verbatim in the always-visible
failure caption. Route them through String(localized:) under the
existing content.delivery.reason.* convention.
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>
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>
The autocomplete panel is the only in-app surface for discovering slash
commands, but several suggestions do not match what CommandProcessor
accepts, so tapping them inserts a command that returns "unknown
command":
- CommandInfo suggests /dm, /favorite, /unfavorite, but the processor
only handles /m, /msg, /fav, /unfav. Aliases are aligned to the
accepted spellings (msg, fav, unfav).
- Favorites are suggested only in geohash contexts (isGeoPublic ||
isGeoDM) — exactly where the processor rejects them ("favorites are
only for mesh peers"). The gating is inverted so they appear in mesh,
where they work.
Also, small related fixes to the discovery surface:
- /help is now handled (the ChatViewModel command docstring already
claimed it existed); it prints a local system line listing the valid
commands, and the unknown-command error points at it.
- The suggestion panel keeps the matched command's usage row (e.g.
"/msg <nickname>") visible while arguments are typed, instead of
vanishing at the first space; in that mode the row is informational
and no longer overwrites the draft on tap.
New string is added source-language (en) only. The CommandInfo contract
test is updated to the corrected metadata.
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>
* Add SwiftLint as an advisory CI-only lint job (no Xcode plugin dependency)
* Harden the advisory lint job and exclude build dirs from local runs
The lint job runs a third-party container image, so drop its token to
read-only, stop actions/checkout from persisting credentials into the
workspace the container can read, and pin the image by digest as well
as tag (tags are mutable). Also add an excluded: list to .swiftlint.yml
so local swiftlint runs don't drown in .build/DerivedData artifacts —
CI checkouts are fresh, so this only affects working trees.
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 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>
