Nearby link: ask for more time and suggest limits over Wi-Fi, with no server

[jsconu]

A local build has no way for a kid's phone to ask a parent's phone for anything — the "Suggest a change" and "more time" flows only exist in the cloud build. For the case that actually matters, both phones at home on the same Wi-Fi, they don't need a server to talk.

Design

A nearby link: a 32-byte key the two phones agree in person, and messages sealed under it.

• Pairing — the parent's phone shows a QR carrying a fresh key; the kid's phone scans it once. A QR code is a private channel between two phones held by the same person in the same room, and it's the same shape of secret an end-to-end-encrypted cloud would need later.
• Messages — MoreTimeRequest, LimitSuggestion, Answer. Deliberately tiny: no usage data crosses the link, only a request and its answer.
• Envelope — AES-GCM under the link key. Anyone else on the Wi-Fi can reach the same port, so a message that's tampered with or sent without the key must not open at all.
• Replay — ids are claimed once. Sealing proves who wrote a message, not when; without this, a captured "grant 15 minutes" could be replayed every evening.
• Discovery — mDNS/NSD, advertising a name derived from a hash of the key, so only the linked phone can find it and nobody can tell whose is whose.

What it cannot do, and must say so on screen

• Both phones must be on the same network — mobile data on one breaks it
• Guest Wi-Fi that isolates clients will never work, and nothing in an app can fix that
• The parent's phone must be awake and listening, so a request is kept and retried, never shown as delivered
• It does nothing when the kid is at school — that's what the cloud build is for

Done

The transport-independent layer, in :shared under nearby/, with 12 unit tests covering round trip, wrong key, a flipped bit, truncation, version skew, nonce freshness, replay and the QR payload. The Wi-Fi transport (LanNearbyTransport) is written but has not run on hardware.

Left to build

• QR display screen in the parent app, and camera scanning in the kid app (ZXing core — not a Play Services dependency)
• A queue on the kid phone: hold a request, retry, and never imply an answer is coming
• Listening on the parent phone, tied to its existing foreground service
• Approve/decline UI and a notification on the parent phone
• Applying an Answer to the local profile
• Manifest permissions and the first-run explanation of what this does and doesn't reach
• Verification on two physical phones, including a network with client isolation
• Bluetooth LE behind the same NearbyTransport interface

Design notes are in the KDoc of each file, and the wider context is in docs/LOCAL_AND_CLOUD.md.

[jsconu]

Built and on #44. The scope widened from "requests only" to a real sync — the kid's phone reports usage and receives limits in one round trip — because a request channel alone doesn't give a parent anything to look at.

Done

• Sealed, keyed message layer (AES-GCM, replay-refused, hash-derived mDNS name) — 20 unit tests
• NearbySync: who decides what, as plain testable functions. Limits come from the parent's phone, usage from the kid's, a request is acknowledged and never self-granted
• Wi-Fi transport: NSD discovery + a short-lived socket
• QR display on the parent's phone, camera scanning on the kid's (zxing, not Play Services)
• Parent hosts while its app process is alive; a report is saved with the time it arrived
• Dashboard shows the linked kid's usage with "synced N minutes ago" beside it, always
• Kid's periodic worker syncs; "ask for more time" and "suggest a change" return once linked
• Request reaches the parent as one notification with no grant button on it

Not done

• Verified on two physical phones — none of the discovery, socket or camera paths have run on hardware
• The parent answering a request (the notification opens the app; granting still has to be wired to send an Answer)
• Back-filling days the parent missed (UsageReport.recentDays is sent empty)
• Hosting that survives the app process being killed
• Bluetooth LE behind the same interface