Sometimes you want to share a conversation you had with an AI by sending a link to a colleague or a friend. Maybe you worked through a tricky debugging session, or the model produced a useful analysis you want to pass along.

With existing chatbots, implementing a sharing feature isn't challenging because the provider sees the whole conversation already. But with Tinfoil Chat, the conversation is encrypted with a personal key that is never exposed to anyone. A naive solution is to let users copy and send the full conversation via email, but this is cumbersome and falls short of the one-click link-sharing experience people expect.

How non-private sharing works

With other (non-private) chatbots, the typical sharing flow looks something like this:

1. You click "share"
2. Your conversation gets copied to a database in cleartext
3. They generate a short link like chat.com/share/abc123
4. Anyone with the link can fetch the conversation from their servers

This approach does not work with Tinfoil because it would require you to share your personal encryption key with us or the person you're sharing the conversation with. This breaks the purpose of the unique encryption key used to encrypt your chats.

The URL Fragment Trick

A URL fragment is the data in the URL delimited by #, typically used by websites to store information that should only be accessible by the client-side JavaScript. Importantly, browsers never send the fragment data to servers.

When you visit example.com/page#some-data, your browser sends a request for /page to the backend server but keeps #some-data to itself. This makes it possible to share a link encoding the full conversation data in the fragment. We could take the conversation, encode it into a URL-friendly base64 format, and generate a shareable link like so:

Because the URL itself contains the entire conversation data, it can be "unpacked" by the receiving app of the person you're sharing the chat with. Note that this can be done without ever needing to provide your personal encryption key. Moreover, the personal chat is stored entirely in the fragment data, which means that only the browser sees the chat data when you paste this link. It's entirely decoded by the front-end application and no conversation data is sent over the internet when opening such a fragment-encoded URL. This ensures the conversation remains private from everyone but yourself and the person you share the URL with.

What about really long conversations?

The URL fragment trick works for relatively short conversations, but what happens with longer conversations? It turns out that URL fragments can be used to encode a surprisingly large amount of data. Chrome supports URLs that are up to 2MB in size and most other browsers support up to 1MB of data in the URL. Safari has virtually no limit on URL length.

But there are two problems: (1) conversations with images or documents can exceed 1MB and (2) the resulting links would be really long and cumbersome to share.

Additionally, the size limits of URLs are not just imposed by browser specs but could be imposed ad hoc by the medium via which you share the URL itself. Messaging tools like Slack truncate long URLs automatically, iMessage can mangle them, and other apps can cut off the URL after a few thousand characters.

Full solution using a throwaway key

Our final design combines URL fragments with encryption. We were inspired by Bitwarden Send, Mozilla Send, and Excalidraw, which use this technique for privacy-preserving file sharing. The idea is to first generate a throwaway encryption key that is independent of your personal Tinfoil key. The conversation is then (re)encrypted under this throwaway key and uploaded to Tinfoil. Because nobody but you has access to this throwaway key, neither Tinfoil nor anyone else can see the raw conversation data.

The shareable link contains the conversation ID in the path and the throwaway key in the fragment:

Tinfoil servers only see that something was shared, and roughly how big it is, but have no way of reading the content. Only the person receiving the shared URL can recover the conversation.

When you delete a conversation you've shared, we delete the encrypted blob too. Anyone who clicks the link afterward cannot retrieve it anymore, even though they have the throwaway secret key.

Conclusion

This sharing feature is a small example of a principle we keep coming back to at Tinfoil: designing a system where privacy is structural rather than promissory and achieving this without sacrificing user experience. We built our sharing system so that when we claim "Tinfoil can't read your shared conversations", anyone can verify this fact at the architecture level.