Hacker News Reader

Comment by maxtaco | Hacker News Reader

Max here, author of FOKS. I find it interesting how much glue is required to perform basic cryptographic operations, even in 2025. Imagine a very simple idea like encrypting a secret with a YubiKey. If it's an important secret, that you really don't want to lose, then now you need a second YubiKey as a backup, in case the primary is lost or breaks. But now how do you encrypt and how do you rotate the primary out if needed? To the best of my understanding, there aren't great solutions short of a system like FOKS. If not FOKS, I really believe a system like it ought to exist, and it ought to be entirely open, so that arbitrary applications can be built on top of it without paying rent.

View on HN

Max! I'm so happy that you're doing this! I was a huge fan of Keybase, and have spent the last few years praying (and sometimes brainstorming funding) a decentralized, open source version of it. Looking forward to digging into the details of FOKS, but just wanted to say thank you and the Keybase team for all you've done -- including keeping Keybase going after the Zoom purchase.

Thanks Danny! The Keybase team (not including me) deserves all the credit, I've been gone for over six months. It's a great team and I miss working with them.

I would like to second this! I'm still using Keybase for e2ee git, and have been on the lookout for alternatives because Keybase isn't developed (AFAICT) and may just disappear when the people keeping it up lose interest.

Can't Keyoxide be considered as a decentralized, open source version of Keybase ?

If you haven't seen KERI they're worth a read, I found out about them at an Internet Identity Workshop. It has all those quality of life features for public keys - revocation, rotation, recovery. "Key Event Receipt Infrastructure". Relies on "witnesses" which I don't know if I love it but their presentation impressed me.

https://keri.one/

A good 3-part "Hitchhiker guide" introduction to Keri is available to get a quick overview. Here part two "What exactly is KERI?":

https://medium.com/finema/the-hitchhikers-guide-to-keri-part...

For all of GnuPG's faults, the usage you've described is exactly why I still use it. I have my master PGP key copied to several offline Yubikeys (one of which is stored offsite), and two day-to-day Yubikeys (one of which is always with me on my physical keychain) containing my current signing and encryption subkeys. The signing subkey is also used for SSH authentication. The second slot on the day-to-day Yubikeys is used for WebAuthn/Passkeys. The master key is brought out of storage only if I need to rotate or revoke a day-to-day subkey, or attest someone else's key for web-of-trust purposes.

I sign all of my Git commits, as well as Debian packages. I occasionally sign and encrypt email. My most important encryption use case is file backups, which are encrypted to my public key and copied offsite.

I'm excited about FOKS if it can serve as a modern alternative to the above, with fewer footguns that GnuPG.

Good to know someone's thinking of decentralizing the whole thing :) Always been wondering where to lay these keys out, if people want to start recovering their data / keys. Something like this + IPFS would be radical, and allow folks to encrypt and circulate easily. Thank you for building this. So ... I wonder how you got here after building Keybase, what's the motivation this time, how do you envision this gets hosted?

P.S. I built this for Group Encryption a few years ago, to help circulate key hives offline https://github.com/guilt/groupenc

Max, this looks interesting and I'd like to follow the blog. Would you please add an Atom feed to the blog?

FOKS is a cool project; what kind of projects do you foresee getting spun off from this?

I'm actually working on a crytpography based project inspired by Keybase's use of Merkle Trees and identity proofing but with an added dash of privacy through pseudonyms and chain hashing. Thanks for putting time into this.

Thanks! Would love to see a file sync app, an MLS-based chat (where the encryption key is essentially a combination of the keys output from MLS and the PTK from FOKS). Password managers. I think there's the potential for something like a Hashicorp-Vault-style server-side secret key material manager, but many details left to reader. Maybe a Skiff-style Google-docs clone? I think there are lot of potential directions to go in.

Something like pa should be easy enough to port to it as a first pass: https://github.com/biox/pa

IMO Vault is really nice, but something as simple as possible is better for managing secrets, especially when the storage layer has permission and sane encryption handled for you.

> TL;DR: FOKS is like Keybase, but fully open-source and federated

What features from a user perspective does it currently have in common with Keybase?

F.e. I remember Keybase mostly for secure messaging using public identities (HN, Reddit etc.), and sharing data/files.

E2E-encrypted git. Keybase has KBFS, and FOKS has a poor man's equivalent, which is E2E-encrypted Key-value store.

Thanks! Sorry for being lazy, but I was wondering how you share something using the E2E-encrypted KV store (it wasn't obvious in the website)? In kbfs, I remember it was as easy as putting it in a comma separated usernames path.

It's not as seamless. You need to first make a team, then invite (or add) that user into the team, and then use `foks kv put --team <your-team>`. One key difference is that in Keybase, all user's profiles were essentially world-readable. FOKS aims for more privacy by default, so in order to add Bob to your team, Bob has to first allow you view his sigchain, so you can learn his public keys.

The add vs invite distinction referred to above is because servers can choose different visibility policies. You can set up a server at foks.yourdomain.cc, and set it to "open-viewership", which means that any user can see any other user by default. If you and Bob are both on that host, you can add him to your team without his permission. But other hosts, like foks.app, do not work this way, and Bob has to authorize you to view him.

This is actually so needed. I've heard the phrase "minting your own tokens?!" used as an argument for (N)oAuth. The current state of affairs is honestly just sad.

Reply on news.ycombinator.com