A proximity session is not a peer connection

Claim: nearby connect is a tunnel, not a contact

Two people stand next to each other. Both have NT² Vault unlocked. One taps Meet nearby, shows a QR, the other scans. Devices negotiate, agree on keys, and can exchange structured payloads without email, chat paste, or a cloud relay.

That flow feels like “we’re connected.” Cryptographically and product-wise, it is thinner than it sounds.

A proximity session is an ephemeral encrypted tunnel: a short-lived session id, per-meeting X25519 key agreement, directional traffic keys after confirmation, and immediate zeroize on success, cancel, or timeout. The handshake alone does not teach either side the other’s Vault Key DID. Identity-bound trust is optional cargo inside the tunnel—not a property of the tunnel.

A peer connection is the durable row in Contacts: Key DID for who they are, Peer DID material for how you encrypt Mode A packages. That relationship survives the meeting. It is privacy-sensitive vault state. We already drew that boundary in a peer connection is not a phone contact.

The claim in one line: Meet nearby accelerates delivery; it does not replace peer connections, Mode A encryption, or Inbox consent.

Constraint: “connected” tempts auto-trust

Engineers building nearby exchange often collapse three moments into one:

1. Devices can talk privately.
2. People recognize each other as vaults.
3. A share lands in the vault as owned data.

Collapsing them is convenient and wrong.

If session encryption implies verified contact, consent becomes cosplay. Transport confidentiality is not the same as “I accept this Key DID into Contacts.” Preview, fingerprint, and explicit accept still belong to the contact invite path—even when the invite rides the nearby session.

If a successful nearby transfer writes asset rows directly, Inbox becomes optional theater. Vault-to-vault shares are still Mode A packages: signed by the sender’s Key DID, sealed to the recipient’s Peer DID, staged as pending inbox messages. Delivery success means message received, not imported.

If proximity invents a new sharing mode, you get a parallel crypto story. Mode A already answers vault-to-vault encryption. Mode B/C answer passphrase handoffs for people without NT². Nearby is a carrier for Mode A (and for contact invites)—not Mode F.

If the handshake reveals Key DIDs “to save a round trip,” the session stops being identity-agnostic. Captured bootstraps and curious intermediaries learn more than a routing id. NT² keeps the session identity-agnostic until application payloads intentionally introduce invites.

The constraint: do not upgrade a tunnel into a relationship by accident.

Design: Connect → Trust → Deliver → Accept

Product phases and protocol phases are related but not identical.

flowchart LR
  Connect[Connect session] --> Trust{Trust needed?}
  Trust -->|yes| Invite[Contact invite in session]
  Trust -->|already peers| Deliver
  Invite --> Deliver[Deliver Mode A package]
  Deliver --> Inbox[Vault Inbox pending]
  Inbox --> Accept[Accept into vault]

Session crypto is transport-only. Ephemeral ECDH derives session traffic keys. Those keys wrap application frames for the meeting. They never become the Mode A content keys. Opening a vault-to-vault package still needs the recipient’s unlocked vault and Peer DID material—see share passphrase ≠ master password for why Mode A refuses the disposable-passphrase model.

Trust is cargo. When the counterparty is not yet a complete Mode A contact, the same meeting can carry a contact invite (and a reciprocal invite) over encrypted session data. Acceptance UI, signature checks, and peer-row persistence stay owned by Contacts—not by the session layer. One-way accept still does not silently unlock mutual send; that rule from the peer-connection essay still holds.

Deliver stages Inbox. Nearby-delivered shares use the same inbox adapters as relay or file carriers: a pending share message, review chrome, and explicit Accept into vault. Relay indexes ciphertext; Inbox stays local remains true when the carrier was a room instead of an edge relay.

Done ≠ import. Dismissing Meet nearby after a clean transfer is orchestration hygiene. Import remains a separate, deliberate act.

Trade-off: guided friction instead of one-tap magic

Meet nearby costs orchestration.

Users see Connect, maybe Trust, then Deliver, then later Accept. Incomplete peer connections still block outbound Mode A. Engineers cannot “just decrypt whatever arrived on the session key into the vault.” Support language must stay precise: session versus contact, received versus accepted.

We accept the friction because blast radius stays honest. A stolen phone that finished a nearby session does not auto-import secrets. A successful tunnel does not mint a verified contact without preview. A captured QR after expiry does not resurrect a spent session into a durable relationship.

Preview maturity is also honest: Meet nearby is a guided in-person path under active hardening. The architecture claim does not depend on marketing it as a finished modem story. This series stays on session boundaries and application planes—not parent-frame physics.

What we refuse

We refuse treating a ready proximity session as a completed peer connection. Tunnels do not write Contacts.

We refuse a new sharing mode for “nearby.” Vault-to-vault nearby delivery remains Mode A.

We refuse session encryption as a replacement for Peer DID Mode A sealing. Transport wrap ≠ content crypto.

We refuse auto-import on transfer success. Inbox Accept stays mandatory.

We refuse handshake designs that leak Key DIDs as a side effect of connecting. Identity enters only through intentional application payloads.

Close: accelerate the path you already trust

Cross-vault sharing already had the hard parts: peer connections, Mode A packages, local Inbox, explicit Accept. Meet nearby is the in-person accelerator—one scan to open a short-lived tunnel, optional trust exchange in the same meeting, then delivery into the same inbox model.

Next in this series: why the bootstrap authenticator must stay off the web. After that: how small control-plane messages and a WebRTC bulk plane split attachment delivery without inventing a second share format.

If you want vault-to-vault handoffs that stay Mode A even when you are standing in the same room, explore NT² Vault.