#End-to-End Encryption

Think about how Signal or WhatsApp works. You are in a group. Everyone in the group can read the messages. The service that relays the messages cannot. Removing someone from the group means they cannot read future messages. The encryption is invisible — you just type and read.

WWKG applies that same model to knowledge graphs.

#What you could not do before

Most graph databases encrypt data in transit (TLS) and optionally at rest (disk encryption). But the server itself sees everything in plaintext. Every query, every triple, every result passes through the server unencrypted. That means:

• The database operator can read all your data.
• A compromised server exposes everything.
• Cloud providers and hosting partners have technical access to your knowledge.
• Sharing data across organizations requires trusting every intermediary in the chain.

Teams work around this with network segmentation, VPNs, and contractual agreements. These reduce risk, but they do not eliminate it. The server still sees plaintext.

#What WWKG enables

Encryption before storage, before transit, before everything. Data is encrypted on your machine before it is stored, before it is shared, and before it leaves your node. The servers, peers, and infrastructure that store and relay your data see only encrypted blocks. They cannot read them.

Workspaces as encrypted groups. A workspace is not a database with encryption turned on. It is an encrypted group — like a Signal group chat for knowledge graphs. The shared key is what makes data readable. If you have the key, you are a member. If you do not, the data is opaque.

Transparent to applications. Your SPARQL, Cypher, and GQL queries work exactly as they would without encryption. You do not need encryption libraries, key management in your application code, or special client drivers. The WWKG node handles everything internally.

Automatic access revocation. When someone is removed from a workspace, new keys are generated. The removed person cannot read any data created after their removal. This happens automatically — no manual key distribution, no re-encryption of old data.

Protection against every intermediary. Storage providers, network operators, cloud platforms, WWKG relay nodes — none of them can read your data. The only entities that can are the members of your workspace.

#A concrete scenario

A pharmaceutical company collaborates with three contract research organizations on a shared clinical data graph. Each party needs access to the shared workspace. The cloud infrastructure that hosts the relay nodes does not. A departing CRO loses access to future data automatically when their membership is revoked.

The conversation shifts from “do we trust this cloud provider?” to “who should be in this workspace?” — because the cloud provider literally cannot see the data regardless.

#What makes this different

In most databases, encryption is a layer you add around an otherwise unencrypted system. The database engine operates on plaintext. WWKG inverts this: encryption is the foundation, not a wrapper. The identifiers that track your data are derived from the encrypted form — even the identifiers reveal nothing about the content.

This is not encryption at rest. This is not encryption in transit. This is encryption as the default state of all data, at all times, in all locations. Plaintext exists only in memory, on the node that holds the key, for the duration of a query.

Your data is a sovereign asset. Encryption is what makes it sovereign.

#Next steps

See the Workspaces guide for operational details on creating and managing encrypted workspaces. Related features: Branching and Merge Workflows, Peer-to-Peer Distribution, and Vector Search for Graph Workloads.