Editor’s Note: this article is more focused on developers, read here for general information about NKN’s Universal Communication Service. (https://nkn.org/community/blog/introducing-the-universal-communication-system-ucs/)
People often ask questions about what NKN can do outside NKN blockchain, for example:
- Can we use NKN to enable real time communication between two Ethereum addresses?
- Can we use NKN to do communication between different blockchain addresses, like Ethereum to Bitcoin?
- Can we use NKN to communicate between web2 addresses (e.g. domain, email address) and web3 addresses (e.g Ethereum address, ENS)?
Now the answer is YES.
NKN address is not enough
NKN is the network layer for decentralized communication, where the role of NKN addresses is similar to IP addresses in TCP/IP. When sending an NKN message, one would need to know the recipient’s NKN address. Although NKN addresses have advantages over IP addresses like geo-location independent, end-to-end encryption friendly, they do share one thing in common: they are both machine friendly addresses that most people won’t remember, recognize, or even be aware of. In many scenarios, people don’t want to use NKN addresses directly to receive messages. A few common examples:
- A user already has a well known Ethereum address, and wants to use it as his/her identity.
- A user registered an ENS, and wants to use it in public to keep his/her address human readable.
To make those possible, we need a protocol that can use non NKN addresses to receive NKN messages.
A resolver is basically a plug-in in the NKN SDK that can resolve a non NKN address to an NKN address. The address it resolves can be anything from an Ethereum address to a subdomain or email address, as long as there is a data source that contains the information about the map. The data source can be decentralized like a smart contract, or centralized like a database, as long as users follow the same protocol. Users who control the addresses to be resolved need to store their NKN addresses in the data source as a one-time setup process.
A few resolvers we have implemented:
- [eth-resolver-go](https://github.com/nknorg/eth-resolver-go) maps an Ethereum-compatible address or ENS to an NKN address through a smart contract
- [dns-resolver-go](https://github.com/nknorg/dns-resolver-go) maps a (sub)domain like foo.com or email address like firstname.lastname@example.org to an NKN address through DNS TXT record
A developer example
Let’s say a developer has built an app that allows users to chat with each other using their NKN addresses. Now he wants to support Ethereum/ENS addresses and email addresses too so users can use their existing addresses like `0x…` and `email@example.com` to chat. He needs to make the following changes:
- Instruct users who want to use an Ethereum/ENS address to set up the address map through the smart contract. This could be done in a few clicks for Metamask users at https://ethnkn.nkn.org/
- Instruct users who want to use subdomain or email address to set up the address map by adding a DNS TXT record following the format in https://github.com/nknorg/dns-resolver-go
- When creating NKN multiclient, pass ethResolver and dnsResolver as resolvers in config, e.g. https://github.com/nknorg/eth-resolver-go
That’s all he needs to do to make it work. Now users can send and receive messages using their existing Ethereum/ENS addresses like `0x…` and subdomain/email addresses like `firstname.lastname@example.org`.