It doesn't need to.
Discussion
then you can't read your sent messages either
and that's not even covering the fact that the secret key used in the encryption is a one shot and you don't store it so you couldn't even decrypt it if you only kept the npub on record
i think "giftwrap" is a dumb expression, because really it's a one shot secret key, the public key is the recipient's, and because of ECDH they can decrypt it because they know the secret to it, and the pubkey you generated one off
it should be called a one-shot encryption, i'd be willing to bet that there is even a proper term for it in encryption programming theory
https://github.com/indra-labs/indra contains code i wrote that extensively uses one-shot keys to wrap messages in multiple layers in the same way as it is done with lightning payments, but for carrying actual network packets
Ah ok - we're focusing on different things here. I think GWs are useful for wrapping messages in a disposable cover that allows you to obfuscate the message metadata over the wire. This is actually very valuable but isn't a solution to everything.
Proper encryption of DMs and Group messages is going to require clients to store the actual decrypted message contents (in an encrypted way locally).
It fundamentally isn't possible to build a messaging system that provides strong forward and post-compromise security, allows for asynchronous messaging via decentralized data stores, and also allows any client application to rebuild the full conversation history at any point. They are just incompatible goals. This is why, when you connect a new device on signal, the new device doesn't get the history of the conversation it's in. Just new messages from that point forward.
From your point of view, would you rather give up something on the other side in order to have that rebuildable conversation history?
when there is a repository storing data for you, you can have cross-installation state, what's the argument against using this part of the relay architecture? redundancy already easy to add just by storing it on other relays, it's encrypted to your own secret so it's not able to be breached by cryptanalysis, and the metadata is mostly worthless except to catch your activity cycle perhaps, and with auth those events can be restricted from non-privileged access and with cache management, a history and a limit on the number of historical versions
I'd thought about that some but then thought that it'd be better to leave it for now but you're right, as long as we had good encryption that was based on more than just your private key (additional password perhaps) and we had relays that wouldn't allow others to query for these backup blobs then yes, we could store those on relays and other clients could use those to backfill conversation data and other state.
Sounds like a NIP for another day though. It's more general than DMs and Group messages, for sure.
yeah, there is also the matter of services that do reverse proxy/vpn for you so you can run relays on your client PC from anywhere you are online that enables users to directly drop messages in your personal cache relay
this is unfortunately the key problem with the internet, and has been forever, and why i doubt they will ever fully deploy IPv6 - you wouldn't need third parties to run servers then... and add a decentralised name resolution service and none of those makeshifts would be required, people could communicate privately and without any means of disrupting it without massively disrupting the internet