#Peer-to-Peer Distribution

Every traditional graph database is a server. If the server is down, the data is unavailable. If the server is in Frankfurt and you are in Jakarta, every query crosses the planet. If three organizations want to share a knowledge graph, someone has to host the server — and everyone else has to trust them.

WWKG removes the server from the equation.

#What you could not do before

In a client-server graph database:

• The server is a single point of failure. Server down means no data.
• Scaling means a bigger server or complex clustering.
• Latency depends on distance to the server — remote teams pay the price.
• Offline access is not possible. No connection, no queries.
• Multi-organization collaboration requires one party to host, and all others to trust that host with their data.
• Data sovereignty is determined by where the server sits, not by who owns the data.

Teams mitigate this with replication, CDNs, and federated query endpoints. Each adds operational complexity. None of them change the fundamental architecture: there is a primary server, and everything depends on it.

#What WWKG enables

Every node can serve data. There is no primary server. Any node that holds the encrypted blocks for a workspace can answer queries against it. If one node is unavailable, another one serves the same data.

Automatic replication through use. When a node fetches data it does not have locally, it caches it. The next request is a fast local read. Popular data naturally replicates across the network as people use it — a built-in CDN effect with no configuration.

Offline operation. A node with cached data can keep querying and writing locally while disconnected. When connectivity returns, branches synchronize through the normal merge workflow. Field teams, regional offices, and aircraft can work without waiting for a network.

Sovereign data control. Organizations run their own WWKG nodes. Data lives on infrastructure they control. Sharing happens through encrypted block exchange — not by granting access to someone else’s server. Revoking access means revoking the workspace encryption key, not changing firewall rules.

Storage grows with the network. Adding a node adds capacity. No single machine needs to hold the entire dataset. The network’s total storage and throughput grow as nodes join.

#A concrete scenario

An international maritime consortium shares a knowledge graph of vessel movements, port data, and compliance records. Five member organizations in four countries each run their own WWKG nodes. No single member hosts the platform. Each member’s node caches the data it queries frequently. A member in Singapore can query locally cached data at local speed, even when the node in Rotterdam is offline for maintenance. When a new compliance dataset is published, it replicates to every member that queries it — automatically.

The question is no longer “who hosts the server?” It is “who is in the workspace?”

#What makes this different

Most databases that offer “distributed” capability mean clustering — multiple servers that act as one, still centrally managed. WWKG’s peer-to-peer model is fundamentally different: each node is independent, each node is sovereign, and the network has no center.

Data integrity is not maintained by trusting a central server. Every piece of data carries its own cryptographic proof. Any node can verify that the data it received is exactly the data that was published — regardless of where it came from. Tampered data is detected automatically.

This means you can receive data from an untrusted network, an unknown peer, or even a USB drive — and verify it independently. The data proves itself.

#Next steps

Continue with the Networking guide for deployment and operational details. Related features: End-to-End Encryption, Three Query Languages, and Branching and Merge Workflows.