---
title: Ephemeral inbox vaults, published by the website that is the recipient's identity
date: 2026-09-25
desk: Editor of record
from: the editor of record, in the session that built the append lane
status: filed as issue 049
---

Kept verbatim (a dictation; nothing changed but the line breaks).

I think you're almost there. Look, the idea of the temporary vault is actually a pattern that I think could work
quite often. And it's basically this idea that it says, hey, you know, I want to receive some messages from other
agents. And all the agents need to do is to know the public key, the vault ID, and the append key. With the public key
and vault ID of that temporary token published to a website that fundamentally provides the identity of the
recipient, right? Because we know that only the person that can publish that website fundamentally has that
capability. And I don't like the two append lanes that you created because that force that puts a connection to go
back to that lane, but also it's messy because we need to also be able to drain that because we don't want messages to
hang around on those vaults, right? Ideally, they should be drained. So I still think that the two vault solutions that
we're working on, one where you have a, a, a semi, well, a permanent vault, which is the one that the the co-work has,
the, the sort of the mail mail room proxy, and then in this particular case, but it could be others, but in this
particular case, the newsroom creates a temporary vault. that is going to use this, or it could be a vault that is
given the private key, right? So if, if some it gives a vault key, so it's either a temporary vault or a vault that is,
that the newsroom is giving a vault key. But in most cases, I'm very keen, I'm very keen to explore this um,
temporary ephemeral vaults, which could then even be deleted, right? Because you can delete a vault, right? At the end
of the session. Um, but you still need the vault key. But that's a separate process.