Making content unreadable to whoever holds it gets closer to the point of security than adding another lock.

Public key cryptography in ordinary conversation

Keybase is a communication tool built around encryption. Its front page keeps the definition short: secure messaging and file sharing. What supports both abilities is public key cryptography, which the project says it uses to keep messages private. The user holds the key, the service only carries ciphertext, and that single design choice is what separates its trust model from an ordinary hosted chat application.

The difference matters most in the worst case. With a hosted chat service, the operator sits between the two ends and could, in principle, read what passes through. Here the readable copy never leaves the device that produced it. Whether one trusts the maintainers or not, the amount of trust required is smaller, and that is the practical argument rather than the promotional one.

There is a cost side as well. Holding your own key means nobody can recover it for you. A lost key or a lost device is not a support ticket but a closed door, so the recovery habit has to be planned while everything still works: register a second device, or write the recovery phrase down and store it away from the machine.

Identity verification is the companion piece. Once a public key is bound to social accounts, two parties can confirm who they are talking to before exchanging anything, instead of judging by a nickname and a profile picture. For material that has to be traceable, that confirmation often solves more than the encryption itself, because an encrypted message from the wrong person is still the wrong message.

Files, messages and a time limit

File handling shares the same foundation. The project states that a team s photos, videos and documents can be stored with end to end encryption, so the protected range covers long term storage and not only transport. For a group that passes material back and forth, that removes the search for a separate encrypted drive and keeps one access model instead of two.

Messaging gets one further control. The project supports placing a timer on the most sensitive messages so they disappear once the time is up. Together with the key design, this covers two separate worries: that the content is not read at all, and that it is not readable for longer than intended. Neither is complete protection, and both are useful against the ordinary case of a borrowed phone or a screen read by someone standing nearby.

The stated audience is wider than security teams. The project also mentions households, roommates, clubs and groups of friends, which says something about the intended barrier to entry: the tool is meant to be usable without a background in cryptography. That is a reasonable goal, though it also means the defaults carry the weight, and the defaults here sit on the strict side.

Platforms, licence and the current pace

Coverage is fairly complete. The official description lists macOS, Windows, Linux, iPhone and Android one by one. The client costs nothing, and the same account on different devices resolves to the same cryptographic identity, so a message that arrives on the phone opens on the desktop without a second enrolment step.

The source is published in a public repository under the three clause BSD licence, which means it can be obtained and reviewed. For a tool that handles encrypted conversation, readable code is a precondition rather than a bonus: without it, a claim of end to end encryption is only a statement about intent.

The current state deserves an honest note. The latest release in the repository is 6.6.3, published on 3 June 2026, with changes concentrated on multi account notification handling and a handful of fixes. The repository still received commits in October 2026, but their content is mostly dependency updates and lint fixes. In other words it still runs, though the rhythm has shifted from rapid development to low speed maintenance. Treating it as a finished tool that will keep working suits the evidence better than expecting a stream of new features.

That reading shapes how to adopt it. A project in maintenance is a poor fit for a team that needs a feature roadmap, and a good fit for one that wants a stable channel it can inspect and keep. Pairing it with an independent backup of anything that matters removes the single point of failure that every hosted service carries.

Trust in an encryption tool comes from code that can be read, and from a clear eyed view of how fast it is still moving.

A few suggestions before starting. Run a small pilot with the people who matter most, and check that sending, receiving and identity verification all work before moving a whole group over. Keep an independent backup of team files rather than letting long term archiving rest on one service. And if following new features matters to you, look at the pace of the repository first, then decide how much to build on top of it.