For context this is the original keybase guy coming back to make a workalike opensource version -
The fact that this already has git support is amazing. I can easily migrate my Keybase git repos with a single command.
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?
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?
It looks cool, and I agree with the creators that something like this ought to exist and optimally free from monetization incentives.
From a user standpoint it does seem like quite the undertaking to introduce it though. Most of the needs I'm looking for from such a system are currently already filled quite well by SOPS[0], where I would say I get 80% of the features (I care about) for 10% of the complexity.
[0]: https://getsops.io
Max, the first thing I thought of for use cases here is a better backend for pass[0]. Being able to manage people, families (aka teams), and getting the ability to more easily manage my yubikeys are all wins.
This looks interesting, but I'm having a lot of trouble understanding the section "A Simple Key Hierarchy".
> Everything starts with base-level keys, like user device keys, backup keys, or YubiKeys. Device keys are generated on user devices and never leave the machine they are generated on.
These base-level keys are private keys, no? The previous paragraph introduces symmetric keys, and doesn't discuss private/public keypairs.
> Every user of the system has a sequence of per-user-keys (PUKs) at the next level up the hierarchy. The secrets seeds for these keys are encrypted for all available base-level keys.
Is the idea that, if user Joe is a member of group Sales (I know, I know, how boring this example is), and Sales is a member of group Employees, if Joe wants to write something that all Employees can read, he first decrypts a symmetric key for Sales using one of his personal base-level private keys, uses that to decrypt a symmetric key for Employees, and then stores his data encrypted data with that Employees symmetric key?
> In FOKS, there are two types of parties: users and teams. In both cases, there is a rotating list of constituents (be they devices or team members), and as these constituents change, so to does the corresponding active PUK or PTK.
Does "rotating" here mean simply "potentially changing [over time]"?
Also, do I understand correctly that "rotate keys" means "choose a new key, decrypt everything that was encrypted with the original key, and then reencrypt it all with the new key"? If so, then since servers do not have access to keys (needed for decryption), I think this means that, whenever someone leaves a group or a device is lost, some client must download all data available to that group, decrypt, reencrypt and reupload it -- is that right? This suggests it would be expensive to have frequently-changing groups with access to a lot of data. (I'm certainly not suggesting I know a better way -- just checking my understanding.)
I am working on an open source project where users provide signatures of their projects artifacts (this is oversimplified for the sake of the discussion).
Started using Minisign as the signature scheme. But we're struggling to find a clean solution for users keys renewal, revocation and updated public key distribution. I thought foks might help for that but the examples don't seem to confirm this. Basically the question I need to answer is :how can users trusting an existing signing key also trust the new key replacing it? I hoped we might outsource this to foks, but I think I misunderstood foks in the first place.
The whitepaper says:
> 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.
Okay sorry nobody's said it yet. I'll say it.
You cannot call it that.
I will not be entering the workplace and suggesting that we use a product whose name is very easily mistaken for "the F word". It is an immediate non-starter.
(I'm sure it's a great project, and you probably meant for people to pronounce the name as "folks" rather than... y'know, the other way. I'm telling you this in a spirit of kindness so your project can be more successful and see increased adoption)
Max, can users be limited to delete/push/force push certain branches? Is a server repo incremental backup-friendly? Is is as efficient in storage space and data transfer as regular git? Can we incrementally sync dbs like Sqlite?
Seems this is the best E2EE storage. No choosing creator's cloud vs finicky self hosting, nor worry about flaky sync solutions for my password manager, note app, photo storage etc. A 2$ vps would be overkill.
can you replace systems like infisical with something like foks ? where are the similarities/differences ? would it make sense to use foks for a secrets store in kubernetes for example ?
This project sounds incredibly interesting.
Of course there is terrible AI-generated slop stock images on the homepage.
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.