Nebula Built Overlay Mesh Networks. The Certificate Authority Is Still Central.
by Nick Clark | Published March 28, 2026
Nebula, created at Slack and open-sourced, builds encrypted overlay mesh networks where each node receives a certificate from a central certificate authority defining its identity, group membership, and allowed IP range. Nodes communicate directly through peer-to-peer tunnels without routing through a central server. The mesh operates without a central data path. But the certificate authority that defines identity and group membership is central. If the CA is compromised, every node's identity is compromised. The gap is between peer-to-peer mesh transport and protocol semantics where identity and trust authority are intrinsic to each node's accumulated behavior.
Nebula's combination of certificate-based identity with peer-to-peer encrypted communication is elegant engineering. The lightweight binary and cross-platform support make deployment straightforward. The gap described here is about the identity and trust authority model, not about mesh connectivity.
Identity defined by certificate, not by behavior
Each Nebula node's identity is defined by a certificate signed by the CA. The certificate specifies the node's name, IP address, group membership, and validity period. The node proves its identity by presenting its certificate. Identity is what the CA says it is.
If a certificate is compromised, the node's identity is compromised. If the CA key is compromised, all identities are compromised. The certificate model concentrates identity authority in a single signing key. The mesh is decentralized for transport but centralized for identity.
Firewall rules enforce group-based policy statically
Nebula's firewall rules control which groups can communicate with which groups on which ports. These rules are defined in each node's configuration file. The rules are static: they do not adapt to network conditions, trust changes, or governance requirements. A node in the "servers" group can communicate with nodes in the "monitoring" group because the configuration says so, not because the protocol dynamically evaluates trust.
What memory-native protocol semantics provide
A memory-native protocol would embed trust authority in the protocol itself. Each node's identity would derive from accumulated behavioral continuity, not from a static certificate. Routing policy would travel with each packet, evaluated dynamically based on the content's trust scope and the receiving node's governance requirements.
Nebula's efficient peer-to-peer tunneling could serve as the transport layer. The memory-native protocol above would provide dynamic identity, semantic routing, and governance that adapts to network conditions rather than static certificate and firewall configurations.
The remaining gap
Nebula built lightweight overlay mesh networking with certificate-based identity. The remaining gap is in the protocol layer: whether identity and trust can be protocol-intrinsic properties derived from behavior rather than static certificates issued by a central authority.
