I think he means that relays would auth you before they would respond to any request for DM or gift-wrap event kinds.
Discussion
Yes, this part I got 💹 .
Is there more gating that he is / you are imagining?
currently most relays just give you everything if you send a filter with only kind 4, 1059, 1060 and many clients add tags when you mention other users that are visible in the clear (wtf?) this is why nostr:npub1m4ny6hjqzepn4rxknuq94c2gpqzr29ufkkw7ttcxyak7v43n6vvsajc2jl is getting people seeing messages that appear to be from her when they have actually just got her npub tagged!
and only send you ones that contain the authed npub
also i'm sure you realise this means that sent messages is a problem with giftwraps, since only the recipient appears in them
storing state in application specific data blobs would help there
Lol, this sort of stuff makes me question the need for GiftWraps every time 😉.
Simple solution, maybe not the best, but you can just send a copy to yourself as well?
Explain why this is an issue? Of course the recipient has to show up in the tags of the GW event. But that's the only data in the clear.
how does your client recognise you as the author when the npub in the event is not yours?
It doesn't need to.
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
Storing state in Nostr is a recipe for disaster. You'll never be able to keep that state synced properly across relays.