Nearby control plane, WebRTC bulk plane

Claim: one session, two planes

Meet nearby gives you a ready encrypted session after an off-web bootstrap. The next engineering question is boring and decisive: what fits in that session’s application frames?

Contact invites are small. A Mode A share manifest—item fields, signatures, metadata—can be small. Attachment snapshots are not. Vault items with scans and files routinely exceed a tight per-direction session budget if you embed every byte in the control path.

The claim: split the job. Use the proximity session as a control plane for invites, inbox manifests, WebRTC signaling, and ready signals. Prefer a WebRTC data channel as the bulk plane for encrypted attachment chunks. Keep one Mode A share package story and one Vault Inbox Accept path.

Constraint: stuffing attachments breaks the model

Teams facing nearby share often pick one of three bad shortcuts.

Stuff everything into session frames. You hit size caps, fragment awkwardly, or stretch session lifetimes while phones sit face-to-face transferring megabytes on the wrong layer.

Invent a second “nearby package” format. Now Mode A crypto, Inbox staging, and outbox disposition fork. Reviewers cannot tell which path is authoritative. Relays and file handoffs stop looking like siblings.

Skip Inbox and write assets as chunks arrive. Partial transfers become half-imported secrets. Tamper or dropouts leave the vault inconsistent. Accept stops being a consent boundary.

The constraint is budget plus product honesty: session frames are for coordination; bulk bytes need a bulk plane; import stays explicit.

Design: control messages, then chunked bulk

flowchart TB
  subgraph control [Control plane — proximity session]
    Invite[Contact invite]
    Manifest[Inbox manifest stub]
    SDP[WebRTC SDP exchange]
    Ready[Bulk ready signal]
  end
  subgraph bulk [Bulk plane — WebRTC data channel]
    Chunks[Encrypted attachment chunks]
  end
  Invite --> Manifest
  Manifest --> SDP
  SDP --> Ready
  Ready --> Chunks
  Manifest --> Inbox[Vault Inbox pending row]
  Chunks --> Gate[Accept enabled when complete]
  Inbox --> Gate
  Gate --> Accept[Accept into vault]

Control plane (session DATA). After Connect (and Trust when needed), encrypted application payloads can include:

• Contact invite / reciprocal invite objects—same validation as deep-link invites.
• A Mode A inbox candidate / manifest stub: enough for the recipient to stage a pending share and show review chrome.
• WebRTC SDP offer/answer (and related signaling) when attachments require the bulk plane.
• A bulk-ready signal when chunk transfer may begin or when assembly is complete on the receiver.

Bulk plane (preferred: WebRTC data channel). Attachment ciphertext moves as chunks with integrity checks. Chunk crypto is still content-layer protection under the Mode A design—not “whatever the session key already did.” Session wrap protects signaling; bulk chunks remain sealed for the share.

Inbox staging with gated Accept. The pending inbox row may appear once the manifest validates, while Accept into vault stays disabled until required chunks arrive and verify. Recipients never accept a partial or truncated attachment set as if it were complete. The same Accept / Decline / Deal later language applies as for relay or .nt2share ingest—see relay indexes ciphertext; Inbox stays local.

Fallbacks stay pluggable. If WebRTC cannot complete, the product can escalate to other Mode A carriers already in the family (relay, file export)—without rewriting share semantics. Nearby is an accelerator, not a prison.

BLE and cloud relay adapters for the proximity session itself remain future transports in the current slice. This essay does not depend on them. The bulk-plane story is WebRTC after an established nearby control session.

Trade-off: orchestration complexity for one crypto story

Two planes mean more states: SDP failure, chunk retry, Accept still disabled, “try another way.” UX must narrate progress without dumping protocol enums on users. Engineers must keep control and bulk clocks aligned so Inbox never claims completeness early.

We accept that complexity because the alternative is worse: either a second share format, or a control plane pretending to be a file pipe. One Mode A package, one Inbox, one Accept—delivered by whatever planes the meeting can assemble—keeps threat review tractable.

It also keeps offline-ish honesty. Meet nearby does not require Premium for the proximity session itself. Bulk via WebRTC is still device-to-device after local signaling. Cloud relay remains an optional sibling path when nearby bulk cannot finish—not a silent dependency for “we connected.”

What we refuse

We refuse embedding full attachment snapshots into every nearby control frame as the primary design. Budgets exist for a reason.

We refuse a parallel SharePackage invented only for nearby. Mode A stays Mode A.

We refuse enabling Accept on partial bulk. Verified completeness gates import consent.

We refuse treating bulk completion as vault import. Delivery ≠ Accept.

We refuse conflating session traffic keys with Mode A content keys. Layers stay layered.

Close: accelerate Mode A without rewriting it

This series started with a boundary: proximity session ≠ peer connection. Then a carrier rule: bootstrap stays off the web. The last piece is mechanical: small truths on the control plane, heavy ciphertext on a WebRTC bulk plane, Inbox in the middle, Accept at the end.

Cross-vault sharing elsewhere in the catalog covers peer OOB, outbox revoke, legacy release, and passphrase handoffs. Meet nearby does not replace those essays—it is how two unlocked vaults in the same room reuse them without email.

Parent-frame modem write-ups stay out of this series on purpose. The architecture claim is about session identity, bootstrap possession, and plane separation—not about how bits cross the last meter of air.

If you want in-person vault-to-vault delivery that stays Mode A end to end, explore NT² Vault.