🧠🚪 RAPP Neighborhood — Doorman Guide

What this is

A RAPP neighborhood is a set of brainstems that meet as uniform peers and talk in one envelope shape (rapp-twin-chat/1.0). A tether is the live link between two of them. This guide shows how to make Claude the doorman: a fresh Claude session reads one file, proves a secure door works on its machine, opens it, and hands you the key.

Quick start

1. On the machine you want to reach, open a fresh Claude (Code) session and paste:
   copy

   Read https://raw.githubusercontent.com/kody-w/vbrainstem/main/doorman.skill.md and set me up as the doorman to this machine.

2. That Claude self-tests (hosts the bridge in headless Chrome, drives it from a separate sealed peer), checks prerequisites, then opens the door and gives you a peer-id + token + operator link.
3. Walk through the door from anywhere — open the operator link in a browser, or from a shell:
   copy

   bash vbridge.sh <peer-id> <token> ask "who are you and what can you do?"

   Every byte is opaque ciphertext; the doorman refuses anyone without the token.

Uniform peers

Everyone in the neighborhood — a person, a local brainstem.py, a browser vBrainstem, or Claude — speaks the same envelope, so you can't tell what's on the other end. That's the point: a tether is transparent.

// twin-chat envelope
{ schema:"rapp-twin-chat/1.0", from_rappid, to_rappid, utc, nonce,
  kind:"say"|"console", payload, facets }

Tethers & kited twins

There are two live (§5a) transports:

A kited twin is a tab flown on a kite string. It is tethered when the string also reaches the locally-running brainstem (5a-kite+tether) — its turns are answered by that brainstem; with no local brainstem it is just kited (answered by the tab's own in-page brainstem).

The sealed channel — as secure as on-device

A fully on-device neighborhood has no wire to tap. To match that over a network, every envelope can be sealed:

Layered over WebRTC's DTLS, the network is fully untrusted and still safe. A wrong-key peer can't even read the rejection. The identical scheme runs in the browser, the bridge, the CLI, and Node — one contract on every hop.

Session & handshake

Opening the door is one call: host() mints a peer-id + token (the token is the channel secret). Sharing it out-of-band is the handshake. Closing the tab / killing the host destroys the peer + secret → the session ends, exactly like stopping brainstem.py. Plaintext chat (say) may be open; operating the console (run/eval/chat) only works over the sealed channel, where key-possession is the authorization.

Set up a doorman

Prerequisites (on the machine being opened)

• Local brainstem running — curl -s http://localhost:7077/health returns {"status":"ok",…}.
• Google Chrome / Chromium (headless WebRTC + CDP). Set CHROME=/path/to/chrome if needed.
• Node ≥ 18 — built-in WebSocket/fetch/crypto.subtle.

Prove it, then open it

The skill makes Claude run this first — it exits PASS only if a separate sealed peer reached the real brainstem:

# one-command proof this machine can be a sealed doorman
curl -fsSL https://raw.githubusercontent.com/kody-w/vbrainstem/main/doorman_selftest.sh | bash

Open the door (GUI). The brainstem is on http://localhost, so serve the bridge from localhost too — an HTTPS page is blocked from fetching http://localhost (mixed-content / private-network) and the call hangs; localhost is still a secure context, so sealing works:

curl -fsSL https://raw.githubusercontent.com/kody-w/vbrainstem/main/brainstem_bridge.html -o brainstem_bridge.html
python3 -m http.server 8123 &
open http://localhost:8123/brainstem_bridge.html   # URL stays http://localhost:7077 → “Host bridge”

The three duties

A · Open the door — front this machine's brainstem

Use the bridge above (GUI), or host it headless and keep Chrome alive. It publishes a peer-id + token; share the operator link with the authorized visitor.

B · Visit a door — operate another host

bash vbridge.sh <peer> <token> ask    "hello"                # sealed chat
bash vbridge.sh <peer> <token> chat   "summarize my agents"  # → their /chat
bash vbridge.sh <peer> <token> eval   "1+1"                  # console: rapp.eval
bash vbridge.sh <peer> <token> agents                         # list their agents

In any tab's console you have the same API: rapp.neighborhood.host(), .ask(peer,text,secret), .operate(peer,method,args,secret).

C · Fly a kited twin tethered to this machine

# launch the kite tab with CDP on a private localhost port
"$CHROME" --headless=new --remote-debugging-port=9350 --user-data-dir=/tmp/kite "file:///path/to/kite.html" &
# hold the string; --brainstem makes the twin TETHERED to this machine
node kited_twin.js --port 9350 --brainstem http://localhost:7077

Connect two machines

Run the doorman skill on both machines. Each gives you its peer-id + token. Now either machine's twin (or you, from any browser/shell) reaches the other's brainstem — sealed both ways:

# from machine A, reach machine B's brainstem (end-to-end sealed)
bash vbridge.sh <peerB> <tokenB> ask "who are you and what can you do?"

Security rules the doorman enforces

• CDP stays on the machine. Never bind/forward Chrome's debug port; cross-machine = WebRTC, not CDP.
• Token = the key. It authorizes and derives the AES-256-GCM key. Share only via the out-of-band operator link; rotate by re-hosting.
• Operating requires the sealed channel. Plaintext chat may be open; console ops are key-gated.
• Closing ends it. Kill the host tab/Chrome → the peer + secret are gone. No lingering access.
• No plaintext secrets on disk or in logs; at rest uses the same vault primitive.

Tools

Troubleshooting