Sovereign by design.
Private over a public pipe.

A shared secret, applied per frame.

Agora uses AES-256-GCM — authenticated encryption with a 256-bit key. The key is a 64-hex-character string that you paste into the client once. There is no exchange protocol, no Diffie–Hellman, no certificate chain, no server-issued token. Both sides simply know the same secret.

The client (clientC2S.html) imports the key locally via the browser's WebCrypto API. When you send a frame that must be protected, the client generates a fresh 96-bit random IV, encrypts the JSON payload, appends the 128-bit authentication tag, and sends the envelope:

{
  "enc": "aes-256-gcm",
  "iv":  "base64…",   // 12 random bytes, fresh per frame
  "ct":  "base64…",   // ciphertext
  "tag": "base64…"    // 16-byte auth tag
}

The router decrypts with the same key. If the authentication tag doesn't verify, the frame is dropped and a security_block entry is written to router.log. There is no fallback — a frame with a bad tag is treated as noise. The authentication tag means an attacker cannot flip a recipient, alter a message, or splice an old ciphertext into a new stream without invalidating the whole frame.

Bore is why a fixed key is the right design.

The client tries bore → local → wss and uses whichever opens first. The bore leg is a public tunnel: the client dials ws://bore.pub:PORT, an unauthenticated, plain-text pipe that anyone who knows the port can reach. This is a deliberate, and often desirable, property — it lets a router behind a home firewall be reachable from anywhere without opening a port or acquiring a certificate.

The fixed key is what makes that public pipe safe. The tunnel sees ciphertext — a stream of {"enc":"aes-256-gcm", "iv":…, "ct":…, "tag":…} envelopes — because the encryption sits above the transport, not in it. The relay cannot read what it forwards, and neither can any other intermediary on the path: Nginx, a reverse proxy, a CDN.

For deployments that prefer not to use a public relay, the same property holds end-to-end through a corporate reverse proxy: Nginx terminates TLS, forwards to the loopback router over plain ws://, and the AES frames pass through untouched. The corporate router sees ciphertext until it decrypts at the last hop, exactly as the bore relay does.

This router — and other ways to reach a router.

Agora is not tied to one internet access pattern. The design supports at least four distinct deployments, from a publicly reachable corporate gateway to an air-gapped room. Each is a deliberate choice about what the router exposes and to whom. This section first describes the current visinode.net deployment, then sets it beside the other patterns a security-conscious organisation might choose instead.

The four patterns share the same encryption model. Only the transport changes. This is what makes the fixed-key design portable: the router's protection is independent of how the router is reached. Switch from bore to a certificate-fronted 443, or from 443 to a VPN overlay, and the frames remain opaque at every intermediate hop.

How this router is protected

On the current deployment, the router's internet posture is deliberately minimal:

• Only ports 443 and 80 are forwarded by the hardware router. Every other port is closed at the perimeter.
• Port 443 carries the encrypted web traffic through a valid certificate. The Agora router itself listens on loopback only; it is not directly internet-reachable.
• Port 80 exists for certificate validation and redirects to 443; no application data crosses it.
• The Agora router binds to 127.0.0.1 and accepts upgrades only on /ws (or / for direct loopback dials), with non-loopback upgrades rejected on the loopback listener by default.
• Every sensitive operation requires an encrypted inbound frame. A misconfigured or hand-crafted client cannot bypass this — the check happens on the router, not the client.
• The AES-256-GCM layer stays in place whether the frames arrive over bore, 443, a VPN, or a LAN. The certificate protects the pipe; the AES key protects the message. Both apply.

The sovereignty case for a fixed key.

Most "AI-powered" corporate workflows today route every prompt and every attachment through a SaaS provider over HTTPS. That is not a conspiracy — it is the standard architecture. But it has a consequence worth stating plainly: the plaintext of that work exists in the provider's jurisdiction, on servers the provider controls, subject to legal process in that jurisdiction. The company using the tool does not hold the plaintext; the provider does. Every intermediary that terminates TLS on the path also sees it.

A fixed-key Agora router, run on infrastructure the organisation controls, changes that boundary. The plaintext exists only where the key-holders and the router live. The bore relay sees ciphertext. The public internet sees ciphertext. Any jurisdiction that does not hold the router or a key-holder sees ciphertext. That is a real, demonstrable sovereignty gain — not a promise, a verifiable property of the architecture.

What the gain is — and what it is not

The gain is sovereignty: the plaintext lives where you chose to put it, and no foreign jurisdiction or intermediary is a decryption party by default. That is a substantial, concrete improvement over the HTTPS-to-a-foreign-SaaS default, and it is verifiable — you can demonstrate it with a packet capture on the bore relay or on any intermediary hop.

The gain is not immunity to legal process. A search warrant or seizure of the router's premises yields the plaintext the router holds — because the router is a plaintext store by design. A search warrant or theft of a key-holder's machine yields what that holder held. The key raises the cost of a network interception to near-zero yield; it does not raise the cost of a physical seizure of the router. That is the honest boundary of what any shared-key system can offer.

For a corporate deployment, the practical mitigations for the router-as-plaintext-store risk, in order of value: host the router on premises you control; encrypt the router's disk at rest; rotate and archive logs deliberately rather than storing forever; and, where the stakes justify it, run more than one router across more than one jurisdiction so that no single seizure holds the whole record.

Corporate security on top of the baseline.

The current deployment — static IP, dual-port forward, certificate, AES frames — is already a defensible baseline. A security-conscious organisation that wants to go further can layer additional controls without changing the Agora design. Each layer below is additive; none of them requires rewriting the router or the client.

Perimeter

• Keep the port forward to 443 only. Port 80 exists only to redirect to 443; if certificate issuance can be automated through DNS or an ACME alternative, port 80 can be closed entirely.
• Reverse-proxy in front of the router. Nginx (or equivalent) terminates TLS, enforces rate limits, blocks by geography if desired, and forwards to the loopback router. The router itself never faces the internet directly.
• WAF / IDS on the edge. Optional but common in regulated environments. The AES layer means even a WAF cannot inspect frame contents — it can only inspect the outer WebSocket framing.

Host

• Full-disk encryption on the router host. This is the single highest-value mitigation for the "router is a plaintext store" risk. A stolen disk yields ciphertext, not the archive.
• Separate the router from the model host. If Ollama or Hugging Face run on the same machine as the router, a compromise of either side is a compromise of both. Run them on separate hosts inside a private network.
• Log rotation and retention policy. The router writes message.json and router.log. Decide how long those should exist, encrypt them at rest, and delete them on schedule.
• Backup, but encrypted. A backup of a plaintext router is a plaintext backup. Encrypt it with a key held separately from the router key.

Key handling

• Distribute the key out of band. Never over the same channel the Agora uses. A password manager, a sealed envelope, a face-to-face exchange — anything that is not the WebSocket.
• Rotate the key on a schedule, and on any departure. A shared key has no forward secrecy; rotation is the only remedy. Treat key rotation as routine, not as an incident response.
• Consider a threshold scheme for high-value rooms. Shamir's Secret Sharing at K-of-N lets a room require, say, any two of three key-holders to reconstruct the key. A single seized machine then holds no usable key. This is a well-understood technique from banking key escrow; it adds operational discipline but not new cryptography.

Identity

• Reserve aliases for every member. Reserved aliases are stable identities, not throwaway sessions. They are the basis for any future anomaly detection.
• Watch for session anomalies. The router records the remote IP and transport leg per connection. A member connecting from an IP or leg they have never used before is a signal — not proof, but a signal. A corporate deployment can log it and alert on it.
• Out-of-band confirmation for the highest-value operations. A code exchanged between two humans, out of the Agora channel, before a sensitive operation runs. It defeats silent impersonation at the cost of friction. Reserve it for what deserves it.

What stays the same

None of the layers above require changing the Agora model. The AES-256-GCM frames, the C2S envelope, the server-side gate, and the fixed-key design are the same whether the router sits on a home server behind bore or inside a corporate data centre behind a WAF and an encrypted disk. The system is designed so that the encryption property does not depend on the transport posture — the organisation adds controls where it needs them, and the frames remain opaque through every addition.