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.
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.
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.
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.
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.
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.
I used to use Keybase Git repos for file-based secrets management for my toy DevOps project. Either FOKS Git repos or native support in SOPS would be pretty damn cool!
Easy multi-accounting is something that I hope we already have (`foks key switch` is pretty smooth). It's a feature I use a lot (I have a personal account on @foks.app and our company account is on @ne43.foks.cloud).
This is a great point and I thought a lot about this. This is the sort of thing that can be changed later if it's really a good idea, but I got to thinking that having non-local admins would mean more server-to-server communication and more server-to-server trust, and I was trying to avoid that.
Imagine alice@foo is an admin of bluejays@bar. One thing alice@foo will need to do is to make signed changes to bluejays@bar, when adding or removing members, let's say. Right now, the server at bar will check the validity of these signatures, that they were made with the alice@foo's latest key. So in other words, there would have to be some way for bar to authenticate to foo to allow bar to read alice's sigchain and to determine her latest key.
I was thinking that keeping foo and bar separated was a good idea both in terms of privilege separation and keeping the network simpler (which would in turn be good for uptime and would simplify software upgrades).
How does the "federation" work? I assume the actual team data is stored on a single foks server, the one the term is on, so I guess from there you basically have some lightweight SSO for team members using their server?
Correct! Remote members of the team get access to shared team keys, and the team's data, even though they don't have accounts on that server. Knowledge of the team key suffices to allow a remote user to authenticate and transfer (encrypted) data to and from the server.
There is very little server-to-server communication, which simplifies the design and software upgrades.
To better wrap my head around how FOKS facilitates team collaboration, I'd like to see two comparisons:
1) compare to a team-shared Linux machine with SSH daemon. Each team member has a user account, and they can manage their SSH authorized keys, including keys stored on Yubikey. The team can share files and git repositories on the Linux machine's own storage. Some differences I see with this approach are the federated aspect and "append-only data structures that allow clients to catch dishonest server behavior".
2) compare to Radicle, a decentralized git service. Identities are keypairs.
With FOKS, how coupled is storage of git and secrets to the FOKS server?
I'm not familiar with Radicle, but I'll check it out. For (1), consider the case of that server being hosted on AWS. Even though only members are authorized to SSH into it, the plaintext is still known to the cloud hardware, and can be exfiltrated that way. In FOKS, the server sees encrypted data only, so that attack is greatly mitigated. I would say that if the SSH server was hosted on one of the workstations of one of the team members, then the security advantages of FOKS would be much less.
The KV-Store and Git server are implemented as "applications" on top of the FOKS infrastructure, so they aren't coupled. They see a sequence of Per-Team-Keys (PTKs); they use the older ones for decryption and the newest for encryption. I'd really love to see all sorts of other applications built on top of FOKS but we might need to do some work as to nailing the right plugin architecture.
Federation in key services solves a critical problem: it prevents centralized control while maintaining the convenience of discovery and verification across organizational boundaries.
And in reality, someone making a personal project used a tool at their disposal to add pretty pictures to their website, said website not being a part of the project in any way.
If they vibe coded the app, sure, be skeptical. But there's no indication they did, just that they wanted images for their website, and they're a software engineer and not a graphics designer.
I put about as much weight in the origin of those graphics as which website editor they use. If they were advertising themselves as a web designer, sure, maybe that's relevant. That's not what they're doing here though.
Why is that different from disliking their font preference? It's an aesthetic choice, made by someone who's not advertising their web design expertise, that's purely subjective.
If this site were their product, maybe that'd matter. But why does that matter in this context?
It shows the author is willing to publish content that looks right at first glance but falls apart upon closer inspection, lacking rigor and consistency. That same description could also apply to your average amateur cryptosystem, which tends to be insecure as a result. If the author has low standards for images, might he also have low standards for his own code?
In this case, probably not! The text on the website and the author’s comments here and his background all suggest that he writes high-quality cryptosystems. But the AI art by itself is still evidence pointing to lower quality.
Because it shows a lack of respect for and understanding of the work graphic artists actually do. Now if that's your brand, great. You are communicating it effectively. If it's not your brand, it's probably worth considering the subtext in your presentation.
> it shows a lack of respect for and understanding of the work graphic artists actually do
No more than wearing off-the-rack clothes shows a lack of respect for and understanding of the work tailors actually do.
No more than wearing factory-woven cloth shows a lack of respect for and understanding of the work weavers actually do.
No more than heating a can of soup shows a lack of respect for and understanding of the work chefs de cuisine actually do.
In my cases as well as yours, one certainly can choose to spend extra for the luxury of the best to meet the want, but it is also fine to spend less and meet the need. In my cases as well as yours, judging someone for the value he assigns to a luxury is gauche.
It shows a lack of attention to detail when the illustration for "Merkle Trees" is not a forest (it has cycles). And "A Simple Key Hierarchy" could use an illustration of a real example instead of nonsense.
If someone used comic sans for their cryptographic software landing page, and someone else said: "this font makes me wonder if I can have any faith in this human being's aesthetic sense", I am willing to bet a nickel that you wouldn't be employing any of the same arguments that you're now employing to defend their choice of LLM images so devotedly.
Many people find using LLM images tacky and garish. It screams low-effort slop, to a significant number of people. When it's so easy to find great usable images on wikipedia, for example, it's hard to know why a sophisticated technical person would take the risk involved in this choice.
I'd a quick look there at the images on the wp page for chains, and the one for knots - some really excellent images. One doesn't need a PhD in web design to pull it off, either.
https://keri.one/
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.
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.
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.
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.
https://blog.foks.pub/posts/introducing/
> all the admins and owners — those who have the ability to change the team — must be on the same home server
Maybe with easy multi-accounting it could be made less annoying, but this seems like a big limitation for a federated system.
This is a great point and I thought a lot about this. This is the sort of thing that can be changed later if it's really a good idea, but I got to thinking that having non-local admins would mean more server-to-server communication and more server-to-server trust, and I was trying to avoid that.
Imagine alice@foo is an admin of bluejays@bar. One thing alice@foo will need to do is to make signed changes to bluejays@bar, when adding or removing members, let's say. Right now, the server at bar will check the validity of these signatures, that they were made with the alice@foo's latest key. So in other words, there would have to be some way for bar to authenticate to foo to allow bar to read alice's sigchain and to determine her latest key.
I was thinking that keeping foo and bar separated was a good idea both in terms of privilege separation and keeping the network simpler (which would in turn be good for uptime and would simplify software upgrades).
There is very little server-to-server communication, which simplifies the design and software upgrades.
1) compare to a team-shared Linux machine with SSH daemon. Each team member has a user account, and they can manage their SSH authorized keys, including keys stored on Yubikey. The team can share files and git repositories on the Linux machine's own storage. Some differences I see with this approach are the federated aspect and "append-only data structures that allow clients to catch dishonest server behavior".
2) compare to Radicle, a decentralized git service. Identities are keypairs.
With FOKS, how coupled is storage of git and secrets to the FOKS server?
The KV-Store and Git server are implemented as "applications" on top of the FOKS infrastructure, so they aren't coupled. They see a sequence of Per-Team-Keys (PTKs); they use the older ones for decryption and the newest for encryption. I'd really love to see all sorts of other applications built on top of FOKS but we might need to do some work as to nailing the right plugin architecture.
If they vibe coded the app, sure, be skeptical. But there's no indication they did, just that they wanted images for their website, and they're a software engineer and not a graphics designer.
I put about as much weight in the origin of those graphics as which website editor they use. If they were advertising themselves as a web designer, sure, maybe that's relevant. That's not what they're doing here though.
If this site were their product, maybe that'd matter. But why does that matter in this context?
In this case, probably not! The text on the website and the author’s comments here and his background all suggest that he writes high-quality cryptosystems. But the AI art by itself is still evidence pointing to lower quality.
No more than wearing off-the-rack clothes shows a lack of respect for and understanding of the work tailors actually do.
No more than wearing factory-woven cloth shows a lack of respect for and understanding of the work weavers actually do.
No more than heating a can of soup shows a lack of respect for and understanding of the work chefs de cuisine actually do.
In my cases as well as yours, one certainly can choose to spend extra for the luxury of the best to meet the want, but it is also fine to spend less and meet the need. In my cases as well as yours, judging someone for the value he assigns to a luxury is gauche.
Many people find using LLM images tacky and garish. It screams low-effort slop, to a significant number of people. When it's so easy to find great usable images on wikipedia, for example, it's hard to know why a sophisticated technical person would take the risk involved in this choice.
I'd a quick look there at the images on the wp page for chains, and the one for knots - some really excellent images. One doesn't need a PhD in web design to pull it off, either.
You 100% didn’t vibe code this, but the AI images give that sort of impression.
I'm excited to try this out personally! Thanks for building this maxtaco