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.