Start here

FAQ

Why no accounts?

Accounts are an attack surface. Once you have accounts, you have passwords (or password resets, or OAuth tokens, or session cookies), which means you have a database of secrets, which means you have something worth stealing. You also have a unique identifier per user that ties their conversations together over time, which is exactly the kind of metadata Pug Network is built to avoid producing.

Pug Network's identity model is "anyone with the URL can join". The URL is the credential. That sounds weak until you remember that the URL contains 16 bytes of random secret plus the encryption key, and neither one ever reaches the server.

Why no message history?

Same logic. Stored history is something to leak, subpoena, exfiltrate, or accidentally back up. The product is for conversations where the absence of a record is the point. If you want a record, take notes elsewhere — Pug Network does not give you one and that is a feature.

Why a URL fragment for the key?

Per RFC 3986 §3.5, browsers never send the part of a URL after the # in any HTTP request. This is bedrock URL semantics — every browser on the planet does it, and it has been true since the spec was written.

Putting the AES key and the room secret in the fragment therefore means the server has no way to receive them, even by accident, even if someone misconfigures logging, even if a debug build leaks more than it should. The construction is structural, not policy.

Why two implementations (JS and Go)?

Different jobs:

• JavaScript is what powers the live site. It is the easiest path to "I want my own Pug Network running in the next ten minutes" — push to Render, done. It runs on Node.js + Express + a tiny dependency tree.
• Go is the reference implementation. Single static binary, zero third-party dependencies, embedded assets, kernel-level sandboxing on OpenBSD. It is what we recommend for on-prem, air-gapped, or "I want to be able to read every line of my server in an afternoon" deployments.

Both implement the same protocol bit-for-bit. If they ever diverge, the Go spec wins.

Is the encryption "real"?

Yes. Messages are encrypted with AES-256-GCM in the browser using the Web Crypto API before they leave your machine. The server only ever sees ciphertext. The 32-byte key is generated locally by the room creator and shared via the URL fragment, where (per the answer above) it never reaches the server.

What Pug Network does not currently ship is forward secrecy via a Double-Ratchet-style protocol. The same AES key is used for the lifetime of the room. This is fine for short-lived rooms and is the explicit tradeoff we are making in v1; a forthcoming client-side ratchet is on the roadmap.

Can the server operator read my messages?

No. The server has never had the key. See Trust model for the full explanation, including what the worst-case server breach actually exposes (it is metadata, not message contents).

Can someone with my room link read messages I sent before they joined?

No, because there are no messages stored anywhere to read. Messages are relayed in real time and are not retained on the server. A late joiner sees only what is sent after they join.

What happens when a room expires?

The TTL fires, the in-memory data structure is freed, all active WebSockets receive a close frame, and the room ID becomes invalid. Reusing the URL after expiry returns "not found". See Room lifecycle.

Why a Proof-of-Work check?

Without it, a single script could spin up thousands of rooms per second on a public deployment. Adding a small computational cost to room creation makes that uneconomical without requiring identity, an email, or a captcha. A human waits a fraction of a second; a spammer pays a real CPU bill.

Can I use this for groups, not just two people?

Yes — set the participant cap when creating a custom room (up to 6 in the default deployment configuration). The protocol is not limited to two-person rooms; the cap is a deployment policy you can change in the server config.

Can I run it on my own domain?

Yes. Pug Network does not hardcode any domain anywhere — point any hostname at your deployment and it works. See Deploy on Render for the easiest path or Self-host the Go build for the most secure one.

Is it open source?

Yes. The full source — both the JavaScript and Go implementations, plus the canonical PUG_NETWORK_LOGIC.md spec — is published in the project's repository. The site you are reading is generated from the same source tree.

I found a bug. Where do I report it?

For functional bugs, open an issue on the repository. For security bugs, please follow the process on the Report a vulnerability page — do not file public issues for security findings.