Alice and Bob in wonderland: Bootstrapping identity and authority in a world without servers
English transcript (with translations of the Chinese questions). Edited transcript of the presentation and discussion on 5 October 2026. Repetitions and clear recognition errors have been corrected while preserving the order, examples, qualifications and questions. Product status and plans reflect the talk date. Timestamps refer to the edited video.
Contents
- Without servers, what anchors identity and authority?
- From DevResults to local-first
- Document IDs and revocation
- Public-key cryptography and key management
- Signal, WhatsApp and device keys
- The limits of trust on first use
- PAKE and the Seitan token exchange
- Identity is rooted in relationships
- Distributed access control and signature graphs
- Membership, delegation and key rotation
- Concurrent additions and removals
- When administrators remove each other
- What anchors identity and authority
- Keyhive, BeeKEM and Subduction
- Q&A: contribution and authority
- Cryptographic primitives and document permissions
- Comparing with Secure Scuttlebutt
- Social relationships and invitation security
- Scale and independent communities
- Key rotation, identity conflicts and malicious members
- Bulletin boards and identity revocation
- Peer discovery, sync and relay trust
Without servers, what anchors identity and authority?
My name is Herb Caudill, and I'm going to be talking about local-first authentication and authorization. When I first started thinking about this a few years ago, I really found it disorienting and weird. It might not be obvious what would be disorienting, so let me explain.
In the world that most of us are used to, authentication and authorization are ultimately anchored in physical hardware, right? That hardware is owned and controlled by a single company. You trust that company: it might be your employer, a software service provider, or a big tech company. That server has all your stuff on it, and it has rules about what you're allowed to do. It has your username and password. Anybody who wants to access their stuff has to go through that server, right?
The server is like a guard at the castle gates. If it doesn't recognize you, it doesn't let you in. If it thinks you shouldn't be allowed to have something, then it just doesn't give it to you. Of course, we're talking about local-first. We would prefer not to be dependent on a central server. But the good thing about a server is that it does give you a single source of truth, and it is the physical custodian of your data. That gives you solid ground to stand on, right?
When the server goes away, you lose that solid ground. All you have are clients that relate to each other as equals. So how do you know who is who? How do you know who to trust? How do you know who has what permissions? What do permissions even mean in this context, where everybody has a copy of all the data? Who is giving permission? Without a server, we have to find new ways to solve problems that the centralized arrangement had already solved. That is what makes this disorienting, like going down the rabbit hole.
The English word “bootstrapping” has become a word that we associate with something as easy and routine as turning your computer on, right? Booting up your computer. But obviously, the whole point of the metaphor of bootstrapping is that it's supposed to be impossible. You can't lift yourself up by your own bootstraps. It's not possible. It can't be done. But we kind of have to figure out a way to bootstrap identity and permissions in this context.
The first question without a server is: what anchors identity? How do we know who we're collaborating with? The other is: what anchors authority? How do permissions work? Who has the authority to give anyone permission in the first place?
From DevResults to local-first
Just some background on my own motivation. About 15 years ago, I started building a software product called DevResults that's used by government aid agencies and international NGOs. This is me, for example, a long time ago, training a team in Sierra Leone in West Africa. The company has been successful in a small way. We have a small team of very competent people, and I've been starting to think about what we build next.
As soon as I started experimenting with building a new version of this, I was frustrated by some fundamental things about the way software was made. Around that time—this is 2018—I stumbled across this video, which introduced me to Automerge. That was the beginning of my journey into Wonderland.
Shortly after that, I wrote this post. I just want to note for the record that this came out five months before the Ink & Switch local-first manifesto. So I've been thinking about this for a long time. There are a couple of things that appeal to me about local-first. It appeals to me both as a maker of software and as someone who uses software. As a developer, I like the simplicity. All you have to write is the client, and that means that you can iterate faster.
Really, what I want to do is make software. I don't really want to be the custodian of anybody's data, right? If I don't have to host your data, then that also makes things simpler for me. As someone who uses software, I want ownership of my stuff. The right to access the documents I create should never be in question. I shouldn't have to be online to access my stuff. Of course, for my customers at DevResults, who are in Africa and Latin America and other places with intermittent internet access, it's important for them to have offline access as well.
Document IDs and revocation
With my team, we started experimenting on building local-first tools to use internally, but immediately we ran into the problem of how to secure them. The first solution that we ended up with might be familiar to some of you: we just took the document ID of the root document and used that as an access token. It's a long random ID. It's hard to guess. The idea is that just by knowing the name of the document, you have access to it, right? That's good enough for some use cases.
But of course, for a team, if somebody leaves the team, or if somebody's device is compromised, or they lose their device, what do you do then? You can't just change the ID of the document. You kind of have to start over. There's not a lot of good options. That's definitely not going to be good enough for a commercial product, right?
Public-key cryptography and key management
In 2020, a couple of weeks into the pandemic, I started working on a library called @localfirst/auth. To be clear, I'm not a cryptographer, and I had to learn about modern cryptography from scratch. I was immediately fascinated by how empowering public-key cryptography is, in the sense that it can put me on equal footing with anybody in the world, no matter how powerful they are.
In the movies, defeating encryption is just something that you can do by typing very fast. You can decrypt anything. But the reality is more like this. If you do it right, it can't be done. There's not a way to decrypt something if it's been encrypted properly.
It doesn't matter how powerful or well-funded your adversary is. The mathematics of it just means that it's not feasible for anybody, with any amount of resources, to decrypt a message without the right key or to fake a digital signature. That's really empowering. It doesn't require any specialized equipment. It's just math that you and I can do on a cheap laptop, and it doesn't even require that much code.
This is the entire codebase for a compact C implementation of the NaCl cryptography library that was designed to fit in 100 tweets, right? So less than 25,000 characters. That's amazing. That's not very much code.
It was clear to me that public-key cryptography had to be part of the solution to local-first auth. But the first problem, in both of these scenarios, is that Bob has to know Alice's public key. How do we make sure that Bob knows Alice's key in a decentralized context? That brings us to this first question: what anchors identity without a central server?
This is a famous quote: “Crypto is a tool for turning a whole swath of problems into key management problems.” This quote is from Dr. Lea Kissner, who was the head of information security at Twitter at the time. They didn't really mean this tweet to be encouraging, right? The rest of it says, “Key management problems are harder than most people think.” But I found this idea very encouraging because, yes, it's a hard problem, but I would rather have one hard problem than many, many problems, as long as I can find a solution to that one hard problem.
How do we solve the key management problem? How do we learn what people's public keys are? The most obvious solution is to have a trusted party keep a directory of people and their public keys. This is called PKI, which stands for public key infrastructure. The solutions to this generally involve centralized servers. You have the certificate authorities that make HTTPS connections possible. Some big companies have their own certificate authorities to anchor their employees' digital identities. Countries can do the same for residents.
I live in Spain, and in Spain I have a certificate that's given to me by the government. I install that certificate in my browser, and then I can use that to log into government websites, sign official documents, pay my taxes, and those kinds of things. But how do you do this without a centralized server? How do you do this in a peer-to-peer context or in a decentralized context?
The earliest solution to this was something called PGP, which stands for Pretty Good Privacy. For example, this is my PGP public key. The idea here was that you would just share your public key with other people directly. People would put their public keys on their websites, or they would put their public key in their email signature. But of course, this is a big, scary thing.
They had what they called key-signing parties, where people would line up, show each other their ID, and sign to verify that they had seen that. The idea was that this would build up a web of trust. But obviously, only nerds did this. This is not something that was popular with normal people, and so it really never became a thing.
There was a company called Keybase a few years back, which was actually bought by Zoom in 2020. Keybase had a very cool idea called social proofs. The idea was that you would post a cryptographic proof on a site like Twitter, GitHub, or Reddit, and that linked your public key to your identity on those sites. You could then sign something with your key. There was an application that they made that would then verify that that was your key by linking it back to your GitHub account or whatever.
Of course, this is easier than a key-signing party, but it was still something that only nerds did, right? It was not something that the general population found useful. We'll come back to Keybase, though, in a minute.
Signal, WhatsApp and device keys
What really made the difference here, and brought end-to-end encryption to the masses, was the Signal protocol. First you had the Signal app. It was a little bit nerdy. It was still only used by people who were really interested in encryption. But then WhatsApp, from one day to the next in 2016, brought end-to-end encryption to their entire customer base, which was about a billion people at the time. Now there are over 3 billion people using WhatsApp on a regular basis. It's one of the most widely used communication tools in the history of humanity.
What is it that WhatsApp and Signal figured out that we hadn't figured out with Keybase or with PGP? They did it by making encryption transparent to the user. This required a change in perspective. Rather than have a single key that belongs to me as a person, I have a key for every app on every device. Rather than managing the key myself—because people are just bad at managing keys; we can't even deal with passwords properly, let alone PGP keys—we let computers do it. Computers are good at that kind of thing.
In this model, the device generates keys. The user never sees them. Peter van Hardenberg, who's the head of Ink & Switch, is fond of saying that if a user sees an encryption key, you've already lost. So you just keep that internal to the computer. It's an implementation thing that the user doesn't need to know about. People don't share keys with each other. Devices just share them with each other automatically. This is a much better perspective on how to manage keys.
The limits of trust on first use
But you still have the question of how Alice's device learns the public key of Bob's device. WhatsApp and Signal and others use an approach called TOFU, which stands for Trust On First Use. The idea is that Alice's device trusts that the device it first connects with is Bob's device. Alice's device sends its public key to Bob's device. Bob's device sends its public key back, and each device just remembers the other's key. From that point on, they can use those keys to authenticate and to encrypt messages to each other.
That seems reasonable, but “device” doesn't really capture the reality of what's going on here. For example, if you open the app in a different browser, like Firefox instead of Chrome, that's a different device. If you reset your phone, get a new phone, or reformat your computer, that's a different device. If Bob reinstalls the application, it can lose its keys, and so on.
Suppose that Bob reinstalls the application. He now sends a new public key to Alice, and Alice has no real way to tell from that key alone whether she's actually still speaking to Bob. So she has to trust this connection as well. It's not really trust on first use. It's trust on first use, plus every time a device gets compromised or you use a new browser, and so on.
The way that WhatsApp and Signal handle that is that they ask users to compare security codes or safety numbers. This is basically a digital version of the PGP key-signing party thing. Most users don't do this. I've never done it, and I'm a nerd. So if I'm not doing it, then I don't think really anybody is doing it.
The real problem with this approach is that it doesn't scale to groups. It's one thing to do this comparison between two people, because you just have one verification to do. But if you have four people, you need six comparisons. If you have 16 people, you need 120 comparisons. It just becomes completely unmanageable once you start to deal with a group of any size.
PAKE and the Seitan token exchange
If Alice wants to connect with Bob and doesn't know his public key, is there an alternative to trust on first use for securing that first connection? One way is for Alice to share a single-use password out of band. That can mean in person, by email, or through some other channel that she already uses to communicate with Bob. Bob's device then connects and gives Alice's device a cryptographic proof that it knows the password. This is a family of protocols called PAKE: Password-Authenticated Key Exchange.
The idea here is that you have what we're calling a password. It's usually presented as an invitation code. In this example, this is what's called a balanced PAKE, in that Alice can verify Bob because she also knows the password. The disadvantage is that the inviter and the invitee need to connect directly to do this exchange. But what if you want to invite someone to a team and let another team member admit them later? How would that work?
The alternative is what we call an asymmetric PAKE. It uses some additional cryptographic machinery to make it possible for a third party to do the validation. Alice gives Bob the password or the invitation code, and she gives Charlie some material that's derived from the password, not the password itself. Bob then uses the password to generate a proof and sends it to Charlie. Charlie validates the proof and confirms Bob's identity to Alice. Charlie can do this without knowing the password himself. This is a neat trick.
Going back to Keybase: Keybase had built this system for doing social proofs. The way they originally planned to monetize their work was to build an encrypted app for team chat, similar to Slack. It would be used by a company, or a team within a company, to communicate. They realized that they weren't going to get everybody in a company to put their public keys on Twitter or GitHub. They needed another way to bootstrap those key exchanges.
They came up with something called Seitan, presumably the joke being that seitan is firmer than TOFU. I found this approach when I was thinking about this in 2020, and that was the approach I took. It gives us the kind of third-party verification that we were looking for. Here's a simplified picture of how Seitan works.
Alice creates an invitation password. She derives a signing key pair from that password. She puts the derived keys aside and invites Bob by giving him the password through some existing trusted channel: she reads it to him on the phone, or sends him an email, or whatever. She gives Charlie the derived public key so that he can verify the invitation later.
Now Bob derives the same signing key pair from the password. He takes the private key from that pair, writes a document identifying himself, and signs it with the private key. His signature is now the proof that he knows the invitation password. He sends that to Charlie. Charlie takes Bob's signed statement, checks it using the public key Alice gave him, and concludes that this is indeed the person Alice invited. When he and Alice are back online together, he can communicate back to her that he was able to verify Bob.
All of the keys we're seeing here are derived from the invitation. They're all specific to this invitation. Nobody is sending their own keys around to do this. So this initial trust still depends on Alice giving the invitation code to the right person through an existing channel, but it can be verified by a third party.
Identity is rooted in relationships
We've been talking about identity, but that doesn't necessarily mean who you are in the world, in the sense of your name. It just means who you are to me. I know it's you because I gave you the invitation. That's how I know who I'm dealing with.
Around this time, Ink & Switch had a project called Backchannel. One of the motivating use cases was connecting to an anonymous source, such as a whistleblower: having a journalist talk to somebody who didn't want to reveal their identity. The journalist doesn't need to know the source's name; the source can stay anonymous. Trust and identity are rooted in the interactions between these two human beings. I know you because we already interact. We can use that interaction to cryptographically secure connections, and use those connections to form a network of trust relationships.
Distributed access control and signature graphs
That gives us an answer to our first question, and it's one that feels right to me: identity is anchored in human interactions and human relationships. We'll come back to that in a minute. We have a way of knowing who we're talking to, but now, how do I know who's on my team? How do I know who I should share with? How do I know who's allowed to do what? Who decides who's allowed to do what? How do you resolve that in this setting?
I started by thinking about how to make an access control list. This is what a server uses: a list of identities and their permissions. My first thought was that, in a decentralized system, everybody just needs a copy of that list. Maybe we could just put it in an Automerge document and sync it.
The problem is that the list needs to be tamper-evident. If somebody changes this document, it needs to be visible that the document was changed. It needs to be eventually consistent, so everybody who receives the same changes arrives at the same access control list. The changes also need to be authenticated, so we know who made them. We need a different structure from just a plain CRDT for this.
For a tamper-evident history, the first thing you might think of is a hash chain. We start with the first link, A. The next link, B, contains a cryptographic hash of A. Then C has a hash of B, D has a hash of C, and E has a hash of D. E is the head of the chain. If anything changes in one of those earlier links, it breaks all of the hash references that follow it. This is how blockchain works. It makes tampering detectable because we have a trusted reference to check against.
The problem is that a chain is linear. It doesn't give you a way to merge concurrent branches. Blockchain solves this by requiring you to spend a lot of energy to resolve conflicts in the correct way. But how would we do this in this setting?
A hash graph adds branching, and branching allows us to represent concurrent changes. We start again with A. B refers back to A, and C refers to B. Now suppose one person adds link B and another person adds link E at the same time. They both refer back to C. The next person who knows about all the links that came before can refer back to two links instead of just one, and that effectively merges the graph.
With suitable conflict resolution, this lets you replicate changes with eventual consistency. This is a CRDT: it lets peers merge their changes and reach the same results. Automerge uses a history of changes to support this kind of replication. This is exactly how Automerge works. Git also has a branching history, although you have to resolve any conflicts manually. So this is a well-understood way of doing this.
We still need a way to verify who made each change. A signature graph is a hash graph with the added twist that each operation is cryptographically signed by its author. Alice signs the first operation. She also signs B and C. Bob signs D on one branch, Alice signs E on the other branch, and then Alice signs F, which joins the branches. We can verify who signed each operation, as well as detect changes to the history. Any change to anything that happened here will be obvious: the signatures will fail.
We now have the three things we're looking for: tamper-evident, eventually consistent, and authenticated. But we still need rules that say which operations are allowed. We'll get back to that. The signature graph records operations that change the team. This is how it actually works in practice.
Membership, delegation and key rotation
For example, Alice creates the team, so she gets to decide who's on it. At this point, she is the absolute dictator of the group. She's the only member, so it doesn't matter, but she is the absolute dictator. She adds Bob. It is still the case that only Alice is an admin in this group. But Alice can then add a link to the chain promoting Bob to an admin, delegating some of her authority to him.
At that point, Bob can add Charlie. Say Alice adds Dwight, and Bob makes Charlie an admin. Charlie can now even remove Alice, because she delegated the authority that eventually reached him.
The key insight for me is that the root of the graph, this first link in the chain, is what anchors authority in the group. Alice creates the team, so she gets to decide who's in it. Even if she's removed from the group, we still trace every action in the group back to the original founding link of the chain. The root of the graph gives us an anchor for authority. Every valid addition, every removal, and every further delegation ultimately traces back to the authority that comes from the fact that Alice is the one who created the group.
Concurrent additions and removals
To support changes while peers are disconnected, we need to be able to handle concurrency. The problem with a regular CRDT like Automerge is that it doesn't supply the permission rules we need in this context.
In a very simple situation, you could use something like Automerge. Alice creates the team, adds Bob, and makes Bob an admin. Alice and Bob go offline, so each device now has its own copy of the history. Bob adds Charlie, and Alice independently adds Dwight. When their devices reconnect, they just merge the two histories. There's no conflict between these operations, and we can apply them in either order. So far, there's nothing here that you couldn't handle with a regular CRDT.
But suppose Alice creates the team, adds Bob, and makes Bob an admin. What happens if Bob takes an action while Alice is removing him at the same time? Suppose Bob adds Charlie to the group, and while they're still disconnected, Alice removes Bob. When they try to merge their histories, we have a conflict. Is Charlie in the group or not? It depends on what order you take those two items in, or which ones you preserve. It's important to resolve this conflict correctly. Otherwise, Bob could get around his removal by adding another identity that he controls.
The solution I came up with is to resolve the conflict by prioritizing the removal. This is what Martin Kleppmann calls strong removal. It means that Bob's concurrent addition of Charlie doesn't take effect, because he was being removed at the same time.
A generic CRDT like Automerge can't provide that kind of logic. In fact, Automerge wouldn't even see these as a conflict. A conflict in Automerge is when you try to change the same property at the same time, whereas here, two different things happen that are in logical conflict. Basically, this means that any system you have is going to need a custom CRDT designed specifically for group membership.
When administrators remove each other
There are other situations where you might have conflicts. The obvious one you're probably thinking of is: what happens when two admins remove each other concurrently? Alice creates the team, adds Charlie, and so on. Alice and Bob are now disconnected. Bob tries to remove Alice, and Alice tries to remove Bob. Now what? We have an even more difficult conflict to resolve.
One solution would be to use the same approach as before, strong removal, and remove both admins. The problem is that Charlie, who is not an admin, is now the only member of the group. That's not the outcome you wanted, because the group is now useless. This creates an opening for what is essentially a denial-of-service attack: a rogue device can leave the group without an admin rather than accept its own removal.
Another solution is to fork the world into two versions of the same group and have the remaining members decide which one they want to be in. In a way, this is brilliant because it reflects the reality of a decentralized system, but it leaves the members with a decision to make. It's like when the Catholic Church was split for a few years and there were two popes, one in Rome and one in Avignon. Every Catholic had to decide which pope they believed was the correct one. So that's not a great solution either.
The solution I ended up with is to use seniority as a proxy for who's more likely to be right. These lines show how long Alice and Bob have been in the group. Alice has been in it longer, so her removal of Bob takes effect. That was the choice I made in my library.
What anchors identity and authority
We started with two big questions about how to find our footing in a local-first world. The first was how to anchor identity, and the second was how to anchor authority. This invitation protocol involves a lot of cryptographic subtleties, but at its core is the interaction where Alice gives Bob an invitation code. When I first designed this system, that seemed like cheating. It didn't seem like a principled solution.
But the more I think about it, the more I think this is correct. That pre-existing side channel, whether it's email, talking on the phone, or meeting in person, represents the fact that the initial trust exists. That's not nothing. It really is the core of where trust comes from in this situation. This trust exists because Alice and Bob already have some relationship in the world. It's that existing relationship that gives us an anchor for identity.
That's our first answer to what anchors identity. What anchors authority? To go back to these chains: What anchors authority is the act of creation. Whether it's a company that you founded, a project that you started, or a document that you created, creating something gives you that initial authority over it. It doesn't mean that you have to keep the power all to yourself. You can delegate your authority to other people.
It doesn't even mean that you have to keep that authority until the end of time. You might create something and then leave it, just like the founder of a company can eventually leave the company and the company carries on. But even in the case of a company, that authority ultimately traces back to the person who created it, even if they're not there anymore. Even if there are people in the company now who are more powerful than the founder, it all comes from that founder's delegation of authority.
In English, the connection is right there in the word. Authorship and authority both come from this idea of creating something and having that power over the thing you created. These are the answers I came up with and implemented in code in my library: human relationships and interactions anchor identity; the act of creation anchors authority. That feels like a correct and satisfying answer to those questions.
Keyhive, BeeKEM and Subduction
The spiritual successor to my library is something called Keyhive. It takes essentially the same ideas and implements them in a much more production-ready way. Although I should say that's the intent: Keyhive is still in alpha. But I've used it, it works, and it should be live and ready to be used very soon.
There are a couple of other pieces to this. You have something called BeeKEM, which is a separate library—or a separate package within this library—that creates a cryptographic structure for dealing with all the keys and the history of keys within a group. And you have Subduction, a sync protocol and a sync server for relaying encrypted documents without having access to their contents.
All of this is very cool technical work. People much smarter than me are working on it now—real cryptographers, as opposed to someone who learned cryptography during COVID. I'd encourage you to check these projects out. That's all I have. This is my contact information; I'd be happy to discuss any of these things further.
I see there's a question in the chat.
Yes.
Q&A: contribution and authority
Does that mean, if there's a contribution scoring system for each user in the chain, that we could also use contributions to determine power? If the chain is equipped with a contribution score, right?
There are different solutions. I think mutual removal is the hardest question here. The solution I came to is about the depth of the links going back to when a person was added. If I was added ten links ago and you were added five links ago, I have seniority and I win in a mutual-removal situation.
There are different ways to solve this. You could also have a system where you say Bob is Charlie's boss, even though Charlie was hired earlier, so Bob is going to win that conflict. You could find a way to encode those relationships. But obviously that becomes more complicated.
I believe Keyhive makes mutual-removal resolution pluggable, so you can override the logic it uses. I'm not sure whether that's actually the case, though. But certainly there are different solutions to this.
Cryptographic primitives and document permissions
We have another question: ‘Are there new cryptographic primitives that could make it easier to build trust?’
What I found was that, in my library, I didn't need to come up with any new cryptographic primitives. The Keyhive team did come up with some interesting new primitives; the main one is BeeKEM.
I won't describe it, primarily because I don't think I could describe it accurately. But it's a very cool way of building a tree of relationships between cryptographic keys. It's very efficient—much more efficient than what I ended up cobbling together in localfirst/auth.
Another question: ‘The example is about member management. Is a similar method used for granting document access rights?’
Yes. In Keyhive, basically every document is a group. You can have a fairly complex delegation graph. You can say, ‘Here's this document,’ and associate it with five people; that association pertains to the document.
The internal system is very elegant: documents, groups, devices, and individuals are all basically the same kind of thing. If you think about it, a group consists of individuals, and an individual consists of a group of devices. I might have a laptop, a phone, and two different browsers, for example.
A document can be accessed by multiple people, so all these things are treated as the same sort of internal construct. That's all I'll say about it, because I don't want to misrepresent it. It would be great to get Alex Good or Brooklyn to meet with you and talk more about the solutions they came up with while working on this.
Hi, Herb.
Comparing with Secure Scuttlebutt
Yes?
I have a question. Someone in our community introduced a protocol called SSB, Secure Scuttlebutt. It's a kind of person-to-person network. I'm interested in how it differs from your product, like Keyhive, and in how you think about trust models—how you work through and formulate those models.
Right. There are a lot of similarities with Secure Scuttlebutt. I did look at SSB when I was working on this.
Oh.
I actually don't remember what it was about SSB that made it unsuitable for this particular context. But there was something; I think it probably had to do with some of the specific rules for managing group membership. There's also another issue with SSB…
Yes.
It's a very inefficient protocol in the sense that you kind of have to have everything in the universe before you can do anything. My experience when trying to use it was that you sit there waiting for a spinner for a very long time, because it has to bring in every document it knows about…
Mm-hmm.
…before you can do anything. But it's a very cool project. SSB is a very cool project, and I know some of the people who created it.
Mm-hmm.
It's a very cool project, and it might work for your use case.
Thanks. From what you're saying, it sounds as though you prioritize efficiency in establishing trust. That's my impression.
Could you say that again? Prioritize the…?
The efficiency. Okay.
Right, yes. I think it's more about a more efficient way of establishing that trust in the first place.
Cool, thanks.
Social relationships and invitation security
Another question: ‘I really like the idea of grounding authority in real-world social relationships. Do you think your work in international development helped you recognize the importance of offline social scenarios?’
Well, yes, maybe. For sure.
00:54:17 · Question read aloud
I have a question here; let me translate. ‘Is it possible for an asymmetric PAKE to cause the introducer to be attacked?’
Do you mean the third party in this scenario? Like Bob, in this case? I'm not entirely sure—I might not have gotten a good translation of that question.
I think this is the question from that audience member: the introducer being attacked. Do you mean Bob being attacked? I'm asking because he seems not to have fully understood what you mean.
Hello? Is the person who asked that question there?
I'll answer…
Yes.
…the most recent question while we're waiting: ‘How many peers can collaborate using Keyhive and Subduction today?’
Scale and independent communities
I'm not sure what the limits are. But when we designed the parameters or requirements for Keyhive a couple of years ago, the target was to handle Wikipedia scale: the number of documents, users, and editors on Wikipedia.
It was very ambitious in terms of scalability. I'm not sure whether they've hit that target yet. But it's definitely much more scalable than my library was. It was completely rewritten in Rust, again by programmers much more skilled than me.
There's a response here. Okay.
Yes. Okay, there's a new question.
Yes, absolutely. That's definitely the hope here. In addition to being a better programming model that doesn't make us dependent on tech companies, it lets you build these communities from the ground up without depending on someone else's servers or resources. I think that's true.
Key rotation, identity conflicts and malicious members
There's a question about what happens if the scale is quite large. I think I would understand it as a Byzantine attack. [Unclear.]
Right. So, if someone resets their private key…
Mm-hmm.
What do you do if there's an identity conflict when the key is distributed? In my library, key rotation works like this: you have to be an admin to initiate a key rotation, or you can rotate the keys for your own devices.
I think in Keyhive, which has a much more abstract and elegant approach, if you have administrative rights over a group, you can rotate those keys, and nobody else can do so.
Mm-hmm.
Right. Sorry, I'm translating the chat.
Again, identity is defined this way: if Alice invites Bob, Alice is stating that the person she invited is Bob. The person who sends the invitation is the person who does the naming.
Once Bob accepts the invitation and supplies his own private key, we can use that private key to identify anything Bob has done. So, yes.
I suppose two people could each say, ‘This is Bob.’ The library doesn't treat that as a first-class concern. I think that's probably still an open area. Anyway, it's not a problem this library tries to solve—the question of ultimate identity.
I've seen other projects, such as DXOS, a library built on Automerge and Keyhive. It adds a layer using DIDs—decentralized IDs—tied back to, for example, the Bluesky or AT Protocol world. You give up a little decentralization by referring to some trusted store of identities. That's one solution.
With malicious behavior, I think it's up to the admins to remove bad actors from their group. That's the technological solution. Beyond that, there may be other ways to communicate, outside this system, that somebody is not to be trusted.
Identity definitely gets tricky: actually knowing somebody's real-world identity and agreeing on it. There are distributed solutions, and there are central-server-based solutions.
But the threat model behind Keyhive and localfirst/auth assumes that whoever invited a person has the authority to say who that person is. It doesn't deal with two people claiming to have invited the same person when they are actually different people. But that's an interesting problem.
Mm-hmm.
Okay. Any new questions? Does anyone have more questions?
Okay, if there are no other questions, then maybe… Oh, there's a new question.
Bulletin boards and identity revocation
The new question is: could we register a cryptographic signature or credential on a bulletin board in advance, and then, when needed, use it on the board to revoke that identity?
If you do that, you're presupposing that you have a central bulletin board that everybody trusts.
Mm-hmm.
That's essentially centralized public-key management. It's a legitimate solution, but it's a different problem space.
Peer discovery, sync and relay trust
There was a question about how devices find each other and sync without a central server, and whether you need to trust relay services.
There are ways to do that. Both my solution and Keyhive are network-transport agnostic, so they can work over whatever network protocol you have. If you have a trusted relay—or actually, the relay doesn't need to be trusted, because all the traffic is encrypted once you've established someone's identity.
You can also do it completely peer-to-peer using something like iroh. There are many solutions to the question of how to interact with each other. Once you've authenticated with someone, the sync server doesn't need to be trusted: it can't see the contents of anything it stores or forwards. Everything you put on it is encrypted, and it doesn't have any of the keys.
That's what Subduction is: a server and a sync protocol for encrypted documents whose contents the server cannot access or read.
Mm-hmm.
Reticulum's network… Yes, I'm not familiar with Reticulum, but yes.