Keybase never reached its true potential after being acquired. Our goal is to continue the original vision that this awesome messaging app has deviated from.

Creating a federated fork of Keybase with strong privacy guarantees:

Using the Keybase existing client, KEY2KEY will look to rebuild the server side, with the goal of allowing anyone to host a chat server.

KEY2KEY will also improve and expand on many features Keybase currently has, with a strong focus on identity, by building on existing Keybase’s very strong encryption primitives.

Let's build it together...


Core Principles

Privacy and anonymity are central tenets of KEY2KEY, the messaging system will be built with selective disclosure and compartmentalization as core principles.

KEY2KEY is a project born out of our need and passion and we will grow the project as a meritocracy and technocracy; whoever wishes to participate is welcome. Some of our founders and developers are anonymous.

Metadata Protection

KEY2KEY is looking to build a fully distributed encrypted messaging system that emphasizes privacy and resiliency. Metadata leaked should be the minimum required for the system to operate. Server outages should not break messaging capabilities. The security and privacy model are designed around the assumption that any server can and will be malicious or compromised.

We aim to use easy to reason about primitives to build a system that is private, secure, and resilient without complexity that prevents a simple analysis of the components and the whole.

Servers will only have limited awareness of the data being stored, beyond basic validation/sanitization parameters.

The goal is that a malicious server will not know with certainty:


Identity is the core and focus of KEY2KEY, to expand on the primitives built by Keybase allowing easier privacy for any user, with the ability to prove ownership of personal data and participate in the public forum via governance of social systems, building the tools for the sovereign digital individual.


To prevent a single points of failure, after our first iteration of the federated system our long-term goals are such that servers are federated so that a user can decide to use one or multiple external servers to store their messages and groups.

If participants do not share the same servers in common, data is redundantly stored to ensure that each participant has access to their groups and messages through one of their trusted providers, it is always possible for users to run their own services.

The Fractal Design

Federated Instances

Federated instances will be fully autonomous parts of the system which will naturally structure around common interests/topics such as general KEY2KEY, git federated instance, videogame federated instance etc.

Instances will act as hubs to which different resources will fully integrate, thanks to instances, chat rooms will have access to storage capabilities, git and more, using Keybase already existing resources and expanding on them.

Identity Servers

Identity servers govern federated instances and keep the identity of all users and all the metadata needed for operations, they also allow for users to find all the resources and connect to all other instances services.

Chat Servers

Users will not be communicating in a p2p way but using chat servers in between them, chat server stores all the chat messages and allow people to create and join groups, everything is fully encrypted and the system is resilient thanks to easily portable data and client side storage.


Phase 0: Keybase Proof of Concept KEY2KEY

Keybase client, Golang API server Keybase id/account and chat API.

Phase 1: Federated instance Proof of Concept

Add federated instances, identity and resource server functionality and new social functions.

Phase 2: Metadata

Have a fully working codebase that protects people metadata.

Phase 3: Plugins

Build plugins as native code integration and as expandable framework.

Phase 4: Distributed Consensus

Distributed consensus for identity storage, this phase will allow anyone to host a identity server.

Deeper governance for federated instances and multi federated instance support.

Phase 5: Interoperability

Have basic interoperability between federated instances, such that people can port their identity and cross communicate.

Phase 6: WASM Sandbox

WASM website plugins, 2nd class of plugins in web assembly with access to specific info through an API that is able to communicate outside a sandbox.


Interested in working on KEY2KEY? Contact us at