Just like your Confer messages, your folders are stored as encrypted blobs using keys that only you have access to. That makes ordering the folders slightly more complicated. In a normal application, reordering items is trivial. You store a sort index, update it when things move, and let the database handle the rest. But since Confer folders are encrypted blobs, the database can’t “see” a sort index.

Instead, the sort information is stored inside the encrypted blob. That works for something like folders, because the client can download all the folders, decrypt them, and sort locally without too much overhead.

But this creates a new problem. If the sort order lives inside encrypted blobs, what happens when you reorder a folder? In a traditional system with integer sort indices, moving folder C between folders A and B might require updating the indices of every folder after the insertion point. With encryption, each update means re-encrypting and re-uploading. Reorder one folder, re-encrypt and re-upload twenty.

Fractional indexing

Instead, we can use fractional indexing—a technique that generates sort keys which can always be split.

Instead of assigning folders indices like 1, 2, 3, we assign them opaque strings that sort lexicographically. The first folder might get “a”, the second “b”, the third “c”. If you move the third folder between the first two, we don’t update three indices. We generate a new key between “a” and “b”—something like “aV”—and only update the moved folder.

The main insight is that strings, unlike integers, have infinite room between any two values. Between “a” and “b” there’s “aV”. Between “a” and “aV” there’s “aK”. You can always find a midpoint. No matter how many times you reorder, you only ever update one folder.

In code, it looks like this:

function midpoint(a: string, b: string): string {
  // Find first character where strings differ
  let i = 0;
  while (i < a.length && i < b.length && a[i] === b[i]) i++;

  if (i < a.length) {
    // a has a character at position i
    const charA = a.charCodeAt(i);
    const charB = i < b.length ? b.charCodeAt(i) : 123; // 'z' + 1

    if (charB - charA > 1) {
      // Room between characters—use the midpoint
      return a.slice(0, i) + String.fromCharCode(Math.floor((charA + charB) / 2));
    } else {
      // No room—append a character after a's prefix
      return a.slice(0, i + 1) + 'n'; // 'n' is roughly middle of alphabet
    }
  }

  // a is empty or a prefix of b—append to a
  return a + 'n';
}

// Moving folder C between folders A (sortKey "a") and B (sortKey "b")
const newSortKey = midpoint("a", "b"); // Returns "an"

The midpoint function finds a string that sorts after the first argument and before the second. If there’s room between characters (like between ‘a’ and ‘c’), it picks the middle (‘b’). If not, it extends the string.

The beauty is that each reorder is O(1). One folder gets a new sort key, one encrypted blob gets updated, one request goes to the server. The server does not store any plaintext about what order your folders are in—that information only exists in decrypted form on your device.

Why this matters

This is a trivial detail, and folder organization seems mundane, but it’s a good example of why end-to-end encryption is often more complicated than just “encrypt everything.” The server isn’t just storing bytes—it’s providing a service. When the service requires structure (sorting, searching, filtering), and the structure must remain hidden, you have to think carefully about what leaks.

The answer here – fractional indexing inside encrypted blobs, sorted client-side – is nice because it hides everything. The server learns nothing about your folder names, nothing about their order, nothing about how often you rearrange them. All it sees is a collection of opaque ciphertexts and timestamps.

Some things are worth the complexity.

Try it out!

Confer works differently. In the previous post, we described how Confer encrypts your chat history with keys that never leave your devices. The remaining piece to consider is inference—the moment your prompt reaches an LLM and a response comes back.

Traditionally, end-to-end encryption works when the endpoints are devices under the control of a conversation’s participants. However, AI inference requires a server with GPUs to be an endpoint in the conversation. Someone has to run that server, but we want to prevent the people who are running it (us) from seeing prompts or the responses.

Confidential computing

This is the domain of confidential computing. Confidential computing uses hardware-enforced isolation to run code in a Trusted Execution Environment (TEE). The host machine provides CPU, memory, and power, but cannot access the TEE’s memory or execution state.

LLMs are fundamentally stateless—input in, output out—which makes them ideal for this environment. For Confer, we run inference inside a confidential VM. Your prompts are encrypted from your device directly into the TEE using Noise Pipes, processed there, and responses are encrypted back. The host never sees plaintext.

But this raises an obvious concern: even if we have encrypted pipes in and out of an encrypted environment, it really matters what is running inside that environment. The client needs assurance that the code running is actually doing what it claims.

Attestation

Confidential computing solves this with remote attestation. When a confidential VM boots, the hardware generates a signed quote—a cryptographic statement containing hashes of the kernel, initrd, and command line. These hashes are called measurements, and they uniquely identify the code running inside the TEE.

For Confer, we extend the measurement to cover the entire root filesystem using dm-verity. This builds a merkle tree over every byte of the filesystem and embeds the merkle root hash in the kernel command line. Since the command line is measured, any change to any file changes the attestation. The measurement now covers everything.

But a measurement is just a hash. To verify it, someone needs to be able to reproduce it.

Making the attestation verifiable

The Confer proxy and image are built with nix and mkosi to produce bit-for-bit reproducible outputs. Anyone can clone the repository, run the build, and get the exact same measurements.

Each release is also signed and published to a transparency log that is easily searchable. The log is append-only and publicly auditable, which means we can’t quietly publish a different build for different users.

Now we have an intuition for how these parts can come together.

The connection

When you open Confer and start a conversation, your client initiates a Noise handshake with the inference endpoint. The TEE responds with its attestation quote embedded in the noise handshake.

Your client verifies the quote’s signature, confirming it came from genuine TEE hardware. It checks that the public key in the quote matches the one used in the handshake–this binds the encrypted channel to the TEE, preventing interception or replay by anything outside it. It extracts the measurements and confirms they match a release in the transparency log.

Once verification succeeds, the handshake completes. Your client now has cryptographic assurance that it’s talking directly to verified code running in hardware-enforced isolation.

All traffic to the inference endpoint is then encrypted with ephemeral session keys that provide forward secrecy: even if a long-term key were later compromised, past conversations remain protected because the ephemeral keys no longer exist.

A different model

Confer combines confidential computing with passkey-derived encryption to ensure your data remains private.

This is different from traditional AI services, where your prompts are transmitted in plaintext to an operator who stores them in plaintext (where they are vulnerable to hackers, employees, subpoenas), mines them for behavioral data, and trains on them.

We think Confer is how AI should work.

At the heart of this friction is a simple truth: cryptography turns data security problems into key management problems. It’s now straightforward enough to encrypt something before backing it up to the cloud, but how do you “back up” the key used for the backup encryption?

This is one reason why, despite its power, end-to-end encryption has historically been impractical for the web. Web pages are designed as ephemeral views, not durable applications. So even once we were able to generate strong encryption keys in the browser, we’ve lacked a reliable way to keep them – securely and seamlessly – for ongoing use across devices and sessions. Without any other options, we’ve been stuck with marginal, often user-hostile solutions.

For Confer, we face the same core dilemma: we want users to seamlessly access their chats from any device, including a web browser, while ensuring those chats are end-to-end encrypted so no one else—not even us—can access them.

Passkeys: not just for passing

The WebAuthn standard allows websites to authenticate users by proving possession of a private key. A user visits a site, generates a keypair, registers the public key with the website, and subsequently authenticates by proving possession of the private key (signing a challenge). On modern platforms, this happens fairly seamlessly, leveraging built-in security features like Face ID or Touch ID for key storage and authentication.

Incidentally, this means modern browsers and devices provide a mechanism to:

• Generate a per-service keypair.
• Store that key securely on the device.
• Authenticate access via biometrics.
• Synchronize the key across a user’s devices using secure, platform-specific mechanisms.
• Extend access to native applications via app-site association.

That sounds… useful. If we have a persistent, biometrically-protected, cross-device key, what if we could use it to do arbitrary cryptography rather than just authentication?

As it turns out, we can. The WebAuthn PRF extension – while still relatively new – is now beginning to see fairly wide support:

It has browser support in the most recent versions of Chrome, Safari, and Firefox. And it has platform support in the most recent versions of macOS, iOS, and Android. It still isn’t built into Windows, so requires an “authenticator” (like a password manager) to be installed there. Even if it isn’t fully supported on every platform right now, it does look like where the puck is going.

This extension to passkeys allows a client to derive “PRF output”—a 32-byte secret—from the underlying private key. This output is deterministically derived from the long-term key associated with the website, which means it is durable.

This is how the UX looks in Confer:

With a single tap and Face ID or Touch ID on any authorized device, the client has durable key material! That is a much better user experience than being shown 12 random words to write down and “store securely.”

In code, it looks like this:

  const assertion = await navigator.credentials.get({
    mediation: "optional",
    publicKey: {
      challenge: crypto.getRandomValues(new Uint8Array(32)),
      allowCredentials: [{ id: credId, type: "public-key" }],
      userVerification: "required",
      extensions: { prf: { eval: { first: new Uint8Array(salt) } } }
    }
  }) as PublicKeyCredential;

  const { prf } = assertion.getClientExtensionResults();
  const rawKey  = new Uint8Array(prf.results.first); 

From there, we have root key material that we can derive subkeys from and encrypt/decrypt entirely on the client. The root key material is derived from your passkey secret, which we (the provider) never have access to.

This means you can conveniently access your Confer chats and data from any of your devices in a way that feels as seamless as logging into a website, while we remain completely unable to access your data.

Try it out!

In our next post we’ll talk about how we do private inference with this private data.

The core idea is that your conversations with an AI assistant should be as private as your conversations with a person. Not because you’re doing something wrong, but because privacy is what lets you think freely.

I founded Signal with a simple premise: when you send someone a message, only that person should be able to read it. Not the company transmitting it, not the government, not anyone else on the internet. It took years, but eventually this idea became mainstream enough that even Facebook adopted end-to-end encryption.

These days I spend a lot of time “talking to” LLMs. They are amazing. A big part of what makes them so powerful is the conversational interface – so once again I find myself sending messages on the internet; but these messages are very different than before.

The medium is the message

Marshall McLuhan argued that the form of a medium matters more than its content. Television’s format - passive, visual, interrupt-driven - shaped society more than any particular broadcast. The printing press changed how we think, not just what we read.

You could say that LLMs are the first technology where the medium actively invites confession.

Search trained us to be transactional: keywords in, links out. When you type something into a search box, it has the “feeling” of broadcasting something to a company rather than communicating in an intimate space.

The conversational format is different. When you’re chatting with an “assistant,” your brain pattern-matches to millennia of treating dialogue as intimate. You elaborate. You think out loud. You share context. That’s a big part of what makes it so much more useful than search – you can iterate, elaborate, change your mind, ask follow-up questions.

One way to think about Signal’s initial premise is that the visual interfaces of our tools should faithfully represent the way the underlying technology works: if a chat interface shows a private conversation between two people, it should actually be a private conversation between two people, rather than a “group chat” with unknown parties underneath the interface.

Today, AI assistants are failing this test harder than anything ever before. We are using LLMs for the kind of unfiltered thinking that we might do in a private journal – except this journal is an API endpoint. An API endpoint to a data lake specifically designed for extracting meaning and context. We are shown a conversational interface with an assistant, but if it were an honest representation, it would be a group chat with all the OpenAI executives and employees, their business partners / service providers, the hackers who will compromise that plaintext data, the future advertisers who will almost certainly emerge, and the lawyers and governments who will subpoena access.

None of this is entirely new, exactly. We went through the same cycle with email. In the early days, people treated email like private correspondence. Then we learned that our emails live forever on corporate servers, that they’re subject to discovery in lawsuits, that they’re available to law enforcement, that they’re scanned for advertising. Slowly, culturally, we adjusted our expectations. We learned not to put certain things in email.

Advertising is coming

What is new is that email and social media are interfaces where we mostly post completed thoughts. AI assistants are a medium that invites us to post our uncompleted thoughts.

When you work through a problem with an AI assistant, you’re not just revealing information - you’re revealing how you think. Your reasoning patterns. Your uncertainties. The things you’re curious about but don’t know. The gaps in your knowledge. The shape of your mental model.

When advertising comes to AI assistants, they will slowly become oriented around convincing us of something (to buy something, to join something, to identify with something), but they will be armed with total knowledge of your context, your concerns, your hesitations. It will be as if a third party pays your therapist to convince you of something.

Making the interface match the way the technology works

Confer is designed to be a service where you can explore ideas without your own thoughts potentially conspiring against you someday; a service that breaks the feedback loop of your thoughts becoming targeted ads becoming thoughts; a service where you can learn about the world – without data brokers and future training runs learning about you instead.

It’s still an early project, but I’ve been testing it with friends for a few weeks. Keep an eye on this blog for more technical posts to follow. Try it out and let me know what you think!