That being said, and as our first and second identity principles state, it is not required to use nor have a Keybase account in order to use Aragon.

Integrating Keybase and Ethereum

When we started working on this problem, we came up with a quick solution and published an article about it.

This approach had two main problems:

It relied way too much on Oraclize and if Oraclize was corrupt it could undermine the whole system. We weren’t comfortable at all by making a random third party the trusted party.

In order to have a ‘trustless’ two way verification (this username really owns this address) an onchain transaction to the registry was needed.

Keybase Registry 2.0

The most important change is the fact that in the new implementation the file that the user uploads to their KBFS is not a text file with the Ethereum address anymore, but a signed proof asserting that username owns an address, and cryptographically signed with that address private key.

In the case of Aragon, given that the main interface for users right now is a native desktop client, it allows us to find the username, sign the proof on behalf of the user and save the file to their KBFS directory, making the process very straight forward.

The fact that this file exists in my KBFS public directory verifies that I own that username, and after fetching this proof anyone can verify the signature locally and independently, and prove that in fact it was signed with the address claimed.

This is a major improvement because there is no need for an on-chain component to perform searches username to address. Anyone can just get the file from my public KBFS https://<username>.keybase.pub/ethereum.json and see if the address I’m claiming as mine is the one that signed that proof. If that is the case, nothing else is needed to be sure that a certain username owns an address private key and can sign with it.

The Keybase Registry on-chain component is still useful for having two way mappings between usernames and addresses. It still depends on Oraclize to function, but what it requests is the signature for a given username before creating the mapping. It performs the same check ( ecrecover ) on-chain and if the proof is legit it creates the mapping.

The advantages of this new system is that anyone can verify anyone’s username on their behalf (and pay for the verification).

The API for getting information out of the contract is very straight forward:

All the code for the registry is open source and you can check it out in the Github repository:

Bonus: ENS compatible Keybase Resolver

Given this new implementation, the need for having a on-chain registry is lower, but we figured out that an interesting use case of it would be to make it compatible with the Ethreum Name Service.

We built a very simple resolver that uses the Keybase Registry as its base class and provides the following mappings

ens.resolve(“ji.keybase.eth”) -> 0xcc…da20

ens.reverse(“0xcc…da20.keybase.eth”) -> “ji”

Once ENS launches in the mainnet, we will try to secure the keybase.eth name and deploy the resover there.

Wrap up

We are very happy with our current integration with Keybase as it goes well with our principles on how identity should be built in Aragon.

We are of course looking forward to integrating other identity providers and allow users to freely decide what they want to use. We find uPort proposition very interesting and it is probably what we will be looking into next.