abkslmandClaude Fable 5
272039cca5
Browser login — the auth key is now optional on both platforms. When the embedded node starts with no key, TailnetNode asks the backend (LocalAPI backendStatus — IPN state, deliberately not filesystem heuristics: tsnet writes logs and a machine key on every start, registered or not) whether a login is needed, triggers login-interactive, surfaces the auth URL through a new statusStream()/.needsLogin, and waits for Running (4-minute deadline, generation-fenced against stop/restart). The Mac auto-opens the login page from Settings ▸ Remote and shows a re-open button; the iPhone auto-opens only during user-initiated pairing (a background reconnect that suddenly needs a login must not eject the user to Safari — Settings ▸ Tailscale carries the link). The remote-access toggle now reflects the in-flight start instead of snapping off for the whole login window, and toggling off mid-start is honored at both commit points (before and after host.start). LAN↔tailnet fallback — picking Tailnet now keeps LAN on too: the host runs both listeners under a new CompositeSyncListener (merged accept stream; one child ending doesn't end the rest) and the pairing QR carries both hints. The phone builds an ordered candidate chain — LAN first (QR hint or Bonjour), tailnet second — and walks it on pair and reconnect, so a phone that leaves the Mac's Wi‑Fi rolls over to the tailnet and rolls back when it returns. A per-channel 4s connect guard (readiness-checking, bound to exactly its channel) keeps a stale LAN hint from hanging the chain; a stale-client guard in consume() keeps a replaced client's tail events from advancing it; chain exhaustion during pairing lands in a terminal failure instead of spinning on "Connecting…"; routine pre-fallback handshake errors no longer flash the red error bubble. "Connected · LAN / Tailnet" shows whichever transport won. Multi-agent review: 11 confirmed findings (incl. the login gate being dead code via tsnet's eager state-dir writes, and two connect-timeout races), all fixed and re-verified. Suite green (24 sync-related tests incl. 3 new CompositeSyncListener tests); macOS + iOS builds clean. Co-Authored-By: Claude Fable 5 <[email protected]>
NucleicRemote (iPhone client)
The thin iOS remote client for Nucleic (PLAN milestone M4). It's a pure projection of the
Mac host over LAN: monitor sessions, read transcripts/diffs, answer approvals, and send
follow-up input — scope approve. No local git or CLI; the Mac is the single authority
(see docs/UX_IOS.md and docs/SYNC_PROTOCOL.md).
Architecture
All wire/crypto logic is shared with the Mac via the NucleicProtocol SwiftPM library
(this Xcode project links it as a local package at ../..):
- Transport —
NWFrameChannel(NWConnection) +LANDiscovery(Bonjour_nucleic._tcp). - Engine —
NucleicProtocol.SyncClientruns the Noise handshake (XXpsk0 to pair, IK to reconnect), exchanges hello/welcome, and turnsHostMsgs into aSyncClient.Eventstream. - State —
RemoteStore(ObservableObject) is the single on-device UI state, a pure projection of the host. Identity + pinned host live inIdentityStore(Keychain + UserDefaults). - UI — SwiftUI:
SessionsView(attention-first list),SessionDetailView(transcript/diff + status-driven action area),ApprovalCardView(Face ID gate on high-risk),PairingScannerView(QR),SettingsView.
Build & run
# Resolves the local NucleicProtocol package automatically.
xcodebuild -project ios/NucleicRemote/NucleicRemote.xcodeproj \
-scheme NucleicRemote \
-destination 'platform=iOS Simulator,name=iPhone 17 Pro' build
Or open NucleicRemote.xcodeproj in Xcode and run. To pair, start the sync server on the Mac
(Nucleic ▸ Settings ▸ Add iPhone shows the QR), then scan it. On a real device, both must be
on the same Wi‑Fi.
Status
The full pair → list → subscribe → approve → reconnect path is implemented and the protocol/
server side is covered by tests in Tests/NucleicProtocolTests and Tests/NucleicCoreTests.
Push notifications / Live Activity (UX_IOS §5.1/§5.3) are the M5 follow-up (needs the relay).