Without centralized databases to manage online identity, slapping nametags on our digital chests like we’re at a conference cocktail party, we are quickly confronted by large existential questions: How do others know who I am? How can I prove I am myself?
One of the most important features of a peer-to-peer network is the ability to maintain a unique and persistent identity. This identity must be self-sovereign, unforgeable, and easy to discover by peers. In other words, it’s a bit more complicated than a sticker that says, Hello, My Name is McAfee (and I’m still out here).
To achieve this persistent, resistant identity, Kinode OS uses a domain system similar to ENS. Like ENS, Kinode domains (managed by our KNS) are registered by a wallet and owned in the form of an NFT. However, unlike ENS, Kinode domains never expire. Additionally, they contain metadata necessary to both:
KNS provides both sensible defaults and flexibility. The cheapest option is also the default: minting a new NFT, a .os Top Level Domain (TLD).
However, unlike ENS, KNS is not restricted to a single set of NFTs. Instead, it is designed to easily extend and wrap existing NFTs, enabling users to employ identities they already own as their Kinode identity (including ENS domains themselves). For example, the owner of this fine digital artwork may decide to go by doria.milady
Developers will then be able to gate their applications and groups by TLD or other metrics. Such native identity management drastically simplifies building NFT communities and administrating DAOs. Instead of cobbling together communications from a range of imperfect corporate services, DAOS built on Kinode will actually be decentralized for the first time.
It's easy enough to check for provenance of a given identity. If you have a Kinode domain, you can prove ownership by signing a message with the wallet that owns the domain. However, to essentially use your Kinode identity as a domain name for your personal server, KNS domains have routing information, similar to a DNS record, that points to an IP address.
A KNS domain can be either direct or indirect. When users first boot a node, they may decide between these two domain types as they create their initial identity. Direct nodes share their literal IP address and port in their metadata, allowing other nodes to message them directly. However, running a direct node is both technically demanding (you must maintain the ability of your machine to be accessed remotely) and a security risk (you must open ports on the server to the public internet). Therefore, indirect nodes are the best choice for the majority of users that choose to run their own node.
Instead of sharing their IP and port, indirect nodes simply post a list of routers onchain. These routers are other direct nodes that have agreed to forward messages to indirect nodes. When a node wants to send a message to an indirect node, it first finds the node onchain, and then sends the message to one of the routers listed in the node's metadata. The router is responsible for forwarding the message to the indirect node and similarly forwarding messages from that node back to the network at large (you can check out our docs if you want to get technical).
For now, Kinode is offering free hosting for indirect nodes, making it simple for developers to get on the network and start developing right now (you can read more about joining the network here.) Eventually, we anticipate a variety of third-party companies will compete to offer hosting and other infrastructure services.