In decentralized systems, effective communication and identity management are crucial for smooth operation. Peer-to-peer networks require some mechanism to discover peer identities and exchange information such as public keys and routing data. This is often called a PKI (Public Key Infrastructure). However, a “pure” PKI only handles cryptographic identity. A fully-decentralized computer network requires more data to be made available globally in order for peers to efficiently establish communication. This applies to more than just networking: there are several components of the p2p software stack that demand globally-available data, such as distributed file storage, decentralized applications (dApps), and blockchain-based voting systems.
Kinode’s novel solution to this problem is a fully-onchain namespace. The Kinode namespace contains more than just the PKI protocol: it enables the creation of other protocols which can store arbitrary data and compose with one another.
Critically, the Kinode namespace is not a standalone identity system in competition with the diverse world of onchain identity primitives. For wallets with an existing identity, it can serve instead as an extension that lets that identity asset operate a fully-sovereign cloud computer; it can also store data relevant to that computer’s operation onchain in a manner associated with the identity.
In this post, we’ll explain in technical detail what the Kinode namespace is. Then, we’ll introduce some concrete examples of its uses, touch on the question of governance, and share some avenues of future development.
Kinode uses kimap, an onchain key-value store that organizes data hierarchically and supports both mutable and immutable keys. Data is structured in a path format where some entries can be updated (mutable) while others remain permanent (immutable).
The full specification of the namespace, the Kinode Name System, and everything else described in this article will be part of the Kinode whitepaper. The following is a high-level description–more to come!
Kimap organizes data in the following way:
The namespace unifies all globally shared data in one location, making it easy to read and verify. This ensures a consistent view of the network’s state. In practice, the developer experience of using kimap data inside Kinode applications will be as easy as reading from a variable.
Systems can rally around roles for specific names and the associated wallet or smart contract account can accrue coordinative value.
As noted, kimap is designed to be fully extensible, allowing various protocols to build on top of it. The Kinode Name System is just one of these protocols. Another that’s already been created is the Kinode Package Manager–a system that benefits tremendously from global data and integration with node identities. Extensibility also means kimap can integrate other namespaces and identity systems, like ENS or Lens, by creating a TLZ managed by a smart contract.
Each namespace entry in kimap is an ERC-6551 token-bound account, meaning it has a built-in wallet for receiving, holding, and sending digital assets. The address of a given namespace entry’s wallet is counterfactual, meaning that it can be known before the entry even exists. For developers, this property enables new and more secure ways to manage user assets. By isolating wallets, we gain consistent and predictable addresses and enhanced security as well as easy ownership transfer and interoperability with other decentralized applications.
KNS is a protocol that turns namespace entries into node identities.
Node identities are created by entries in kimap with specific sub-entries (~net-key, ~routers, and/or ~port sub-entries, depending on the type of identity). This is the general method by which a protocol on kimap is defined: a set of sub-entries are expected below a given namespace entry, and when a user indexes the map, valid namespace entries become units of that protocol.
Direct and indirect nodes offer flexible networking options. Direct nodes publish IP and port information, while indirect nodes use routers to manage communication. Indirect nodes, for instance, are a good choice for users who want more privacy or who move around often (and thus do not have a regular, fixed internet connection).
KNS uses public-key infrastructure to ensure secure communication between nodes. The Ed25519 public keys for ~net-key entries allow nodes to generate and sign encryption keys used in the Kinode networking protocol, which is implemented across a number of underlying transport protocols and is end-to-end encrypted, even when used by two indirect nodes through a router-node.
The Kinode namespace can improve decentralized application (dApp) user experiences. Separate from any onchain protocol that a given dApp might interact with, its Kinode backend can publish global data to the namespace to share with other nodes. An app store can use this to share app metadata such as reviews and ratings. A game might use the namespace to publicize high scores or achievements. Many programs will still want to create their own onchain protocol for such things, but another class of simpler applications can skip the smart contract development phase entirely and just use the namespace for minimal global data.
A single developer can build rich applications while never leaving the Kinode programming environment.
The Kinode protocol includes a mechanism to manage the namespace, oversee the distribution of top-level zones and ensure fair and transparent governance. This mechanism makes key decisions like creating and auctioning top-level zones.
Community members can help govern and enrich the Kinode namespace. More clarity on this mechanism will be published later as part of the whitepaper.
Kinode will continue to build on the namespace and the load-bearing protocols within the namespace that are used by the OS. Future updates include:
The Kinode namespace provides a great developer experience for building decentralized apps. KNS combines excellent discoverability and secure communication with flexibility in node types. Top-level zones will allow for a diversity of governance strategies within the namespace, and protocols that operate on the namespace will compose with TLZs and with one another. We’re excited by the possibilities unlocked by Kinode and the namespace, and we’re eager to see all the novel applications that developers come up with!
If you want to get started building on Kinode, find our docs here. For assistance, or just to hang out and chat with us, find us on Discord and Telegram.
We can't wait to see you on Kinode.