4 ms·

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 li

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.

eterps 1y ago
> 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.
- maxtaco 1y ago
  E2E-encrypted git. Keybase has KBFS, and FOKS has a poor man's equivalent, which is E2E-encrypted Key-value store.
  - eterps 1y ago
    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.
    - maxtaco 1y ago
      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.
dannyobrien 1y ago
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.
- maxtaco 1y ago
  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.
- kreetx 1y ago
  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.
- frytaped 1y ago
  Can't Keyoxide be considered as a decentralized, open source version of Keybase ?
pmw 1y ago
Max, this looks interesting and I'd like to follow the blog. Would you please add an Atom feed to the blog?
deleted 1y ago
[deleted]
oooyay 1y ago
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.
- maxtaco 1y ago
  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.
  - packetlost 1y ago
    Something like pa should be easy enough to port to it as a first pass: https://github.com/biox/pa 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.
jazzyjackson 1y ago
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/ https://keri.one/
- rapnie 1y ago
  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-2-what-exactly-is-keri-e46a649ac54c https://medium.com/finema/the-hitchhikers-guide-to-keri-part...
vkaku 1y ago
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 https://github.com/guilt/groupenc
xtajv 1y ago
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.
deleted 1y ago
[deleted]
dpifke 1y ago
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.

eterps 1y ago

> 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.

maxtaco 1y ago
E2E-encrypted git. Keybase has KBFS, and FOKS has a poor man's equivalent, which is E2E-encrypted Key-value store.
- eterps 1y ago
  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.
  - maxtaco 1y ago
    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.

dannyobrien 1y ago

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.

maxtaco 1y ago
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.
kreetx 1y ago
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.
frytaped 1y ago
Can't Keyoxide be considered as a decentralized, open source version of Keybase ?

pmw 1y ago

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

deleted 1y ago

[deleted]

oooyay 1y ago

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.

maxtaco 1y ago
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.
- packetlost 1y ago
  Something like pa should be easy enough to port to it as a first pass: https://github.com/biox/pa 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.

jazzyjackson 1y ago

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/ https://keri.one/

rapnie 1y ago
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-2-what-exactly-is-keri-e46a649ac54c https://medium.com/finema/the-hitchhikers-guide-to-keri-part...

vkaku 1y ago

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 https://github.com/guilt/groupenc

xtajv 1y ago

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.

deleted 1y ago

[deleted]

dpifke 1y ago

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.