frphank on Nostr: > What I don't quite follow - if the same key A is used to retrieve the messages how ...
> What I don't quite follow - if the same key A is used to retrieve the messages how it is any better than having queue ID from the perspective of correlating messages to the users?
You need to collect metadata over time to get some value out of it. SimpleX durable queue IDs help with that. His scheme somehow only has ephemeral per-message keys where I don't know where they come from. He may be alluding to https://github.com/nostr-protocol/nips/blob/master/44.md .
I suspect the idea is to post DMs to relays without a specific recipient coded into the message. A large number of *potential* recipients all download all DMs from the sender and attempt to decrypt them. This will succeed for those that were intended for them. The security comes from a large number of potential recipients connecting with their IP for download out of which the actual recipient is but one.
I doubt this will scale well, in line with nostr's overall hail mary approach to distributed systems architecture.
You need to collect metadata over time to get some value out of it. SimpleX durable queue IDs help with that. His scheme somehow only has ephemeral per-message keys where I don't know where they come from. He may be alluding to https://github.com/nostr-protocol/nips/blob/master/44.md .
I suspect the idea is to post DMs to relays without a specific recipient coded into the message. A large number of *potential* recipients all download all DMs from the sender and attempt to decrypt them. This will succeed for those that were intended for them. The security comes from a large number of potential recipients connecting with their IP for download out of which the actual recipient is but one.
I doubt this will scale well, in line with nostr's overall hail mary approach to distributed systems architecture.