Vitor Pamplona (npub1gcx…nj5z) Thanks for the suggestions. We did indeed consider various ideas about how to reduce the persistence queue ID, but the to rotate the queues to another server periodically seemed simpler and providing better metadata protection. The current approach also allows some basic protection from resource exhaustion attacks.
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? Wouldn't it still identify the user any better, and now instead of mapping IP addresses to queues, the server could map IP addresses to the messages... Maybe I don't understand what you propose?
The ideas we considered were about trying to avoid any persistent IDs entirely, e.g. via some kind of DHT tables, and something like this might happen in "v3" of the protocols (we are currently still moving to "v2").
simplex / SimpleX Chat
npub1ex…7d828
2024-02-12 19:30:40
in reply to nevent1q…m2v0
Author Public Key
npub1exv22uulqnmlluszc4yk92jhs2e5ajcs6mu3t00a6avzjcalj9csm7d828Published at
2024-02-12 19:30:40Event JSON
{
"id": "7a64c414e90385e7012515421eee19aade80e10557c448af8bfad43296cb1494",
"pubkey": "c998a5739f04f7fff202c54962aa5782b34ecb10d6f915bdfdd7582963bf9171",
"created_at": 1707766240,
"kind": 1,
"tags": [
[
"p",
"460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c",
"",
"mention"
],
[
"e",
"a6a64dba84382cbc7f678ffe2f3d3e0ef8945b0c655f957a5972de365f3faf30",
"",
"root"
],
[
"e",
"446eca5d390f6272965d375c7e3d9e38a4f4ff50311dbaa7e32aa3c93148e74c",
"",
"reply"
],
[
"p",
"50d94fc2d8580c682b071a542f8b1e31a200b0508bab95a33bef0855df281d63",
"wss://vitor.nostr1.com/",
"calle 👁️⚡👁️"
],
[
"p",
"38b405e49614835c083ae103398c510315c3a0366cfa27115995e79e92451058",
"wss://vitor.nostr1.com/",
"JohnyDoor"
],
[
"p",
"47be0b2a89faaa66bc57f5c679203486da45660295cb3db3c2f38f4be8d8816e",
"wss://vitor.nostr1.com/",
"frphank"
]
],
"content": " nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z Thanks for the suggestions. We did indeed consider various ideas about how to reduce the persistence queue ID, but the to rotate the queues to another server periodically seemed simpler and providing better metadata protection. The current approach also allows some basic protection from resource exhaustion attacks.\n\nWhat 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? Wouldn't it still identify the user any better, and now instead of mapping IP addresses to queues, the server could map IP addresses to the messages... Maybe I don't understand what you propose?\n\nThe ideas we considered were about trying to avoid any persistent IDs entirely, e.g. via some kind of DHT tables, and something like this might happen in \"v3\" of the protocols (we are currently still moving to \"v2\").",
"sig": "f5b438f67f01d01a5291b2b1d443ea294a4267a31a62e0319754d03a62c89ab5cbafd4c003b4a54d87701a98d2e1f7e730cdda81b3c5b6b62b51e64900ca8887"
}