Five things that make it different

Each of these is a consequence of changing the topology, and each is unusual enough to deserve its own page.

1. The network is the security boundary

On the internet, security is something you add: a password, a token, a firewall, an apology after the breach. On a tailnet, security is the default state of the wire. Our tailnet runs a policy file that denies everything first and grants only what is named — a file that is version-controlled, tested on every change, and applied the way software is applied: a pull request, a machine that checks the rules, a merge that refuses to land while a test fails.

We call the tests deny-tests, and they are the heart of the matter. You cannot prove a door is locked by asserting that it is locked. You prove it by writing a test that tries to open it and must fail. Our policy ships with tests that say: a member cannot reach the broker's port; a member cannot open another member's device; the node can never push into a member's machine. They run on every save, on every pull request, on every apply. Isolation is a failing test that stays green.

[FIGURE 3 — "The constitution": the policy file as a written constitution beside the tailnet, with red X's marking the deny-tests that must fail. Caption: Security as a failing test.]

2. Identity is the wire

In the old shape, you prove who you are by remembering something, and the system stores what you remembered. On the tailnet, the connection itself carries who you are. Tailscale proves the identity of a connecting device with cryptography before a single request is read. When your own phone reaches your own node, the network already knows it is you — no second sign-in, no password to lose, no credential store to leak.

We treat that identity as the login. A person's device is their presence. And because the proof is cryptographic and lives in the wire, there is nothing extra for an attacker to phish.

3. Sharing is scoped to the thing

This is the one that changes what a community can be.

Under the cloud, sharing meant giving someone access to the machine, and then building ever more careful walls inside it. Here, you share an item. You mark one book as restricted and grant it to one person. For everyone else the book is gone from the shelf, from search, from the AI's answers, from the knowledge graph, from the library's constellations. It does not exist for anyone who was not granted it. Revoke the grant, and it stops existing again, immediately, everywhere at once.

Locked rooms can be picked. A room that was never built cannot.

[FIGURE 4 — "The book that isn't there": two members' views of the same library side by side — one sees the book, the other sees a gap where the book would be. Caption: Restricted means absent.]

4. The machine becomes unaddressable

Members never address the machine. They address a named capability — svc:community-web, svc:community-models — a name that floats above the physical host and can be drained, moved, or failed over without anyone's configuration changing. The host itself has no address a member can aim at.

While building this we found that the hiding runs deeper than we planned: a Tailscale service's name does not even resolve for a device that holds no grant to it. The ungranted never learn the capability's address. DNS is a second boundary. A machine you cannot name is hard to attack.

5. Public exposure is a decision

Nothing is public unless someone deliberately says so — and the decision is reversible, tag-scoped, and visible in the policy. Our community node once had a public door; we closed it, and proved it closed from outside the network. What remains of the public face is a single path-scoped slot for a Telegram message — a mail-slot. If the decision ever stops being worth it, it is one rule away from being undone.