giftwraps is a word that hides the fact that what it means is it uses a one time key to send it, using NIP-4 DM encryption, and the recipient is visible in the tag but the sender is not, it is part of the content field inside the encryption
this means that clients can't see them after sending them unless they store those one time keys, and that precludes cross-device accessibility
it's only half a solution for the metadata leak problem... the whole solution requires both sides to be online, which is impractical for many reasons
an equally half solution would be for relays to ALL require NIP-42 and only give out DMs and other privileged messages to users whose key appears in the event either sender or tagged receivers or mentions
neither solve the problem that only being online simultaneously solves, and no, simplex et al don't solve this problem, they cache the messages in a middleman situation and they additionally don't have multi-device capability so actually the problem is not wholly solvable, but devs making relays are not doing anything about making what solutions CAN be made, ie, NIP-42, and on the client side, the situation is just as bad
and almost in no case can you count on having even one end of a connection actually capable of inbound connections... wireguard VPNs would solve this problem also, and could be bundled with a paid relay service to further increase privacy
you simply cannot have an async message delivery system without a middle man, and that is a privileged position that cannot be avoided without direct connection and the internet's routing setup still doesn't allow direct connections to be established from all points on the network - most users are behind routers that do not automate giving out port forwards to clients and so there has to be rendezvous services for all peer to peer systems that don't have at least one side able to listen for inbound connections
because there's not a lot we can do about this, we are stuck with the also half-solution of using Tor network, which is an absurdly low bandwidth system and just like this problem with DMs in nostr, clients that support actual p2p direct connections via hidden services basically don't exist and there used to be one called torchat but they changed the API and nobody was funding the maintenance of the project so it was abandoned
it's a big problem, and we are still stuck with trusting someone
i'd trust a nostrich and bitcoiner any day over google and amazon, and i'd trust a little data centre in the boondocks that accepts bitcoin long before i'd trust those cloud providers, and this is possible, right now
i'm not a "means to an end" kinda guy nor am i complacent about the fact that the situation is shit but there is things we can do about this, and the apathy is appalling
#whinge #devstr #security #privacy
mleku / mleku ✝Ⓐ☯︎
npub1fj…mleku
2024-03-30 09:51:21
Author Public Key
npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmlekuPublished at
2024-03-30 09:51:21Event JSON
{
"id": "82a7669b4b58453c70fae5ac00c54f87b3e43cb0dff2f10c30241f6712c767bd",
"pubkey": "4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f",
"created_at": 1711792281,
"kind": 1,
"tags": [
[
"t",
"whinge"
],
[
"t",
"devstr"
],
[
"t",
"security"
],
[
"t",
"privacy"
]
],
"content": "giftwraps is a word that hides the fact that what it means is it uses a one time key to send it, using NIP-4 DM encryption, and the recipient is visible in the tag but the sender is not, it is part of the content field inside the encryption\n\nthis means that clients can't see them after sending them unless they store those one time keys, and that precludes cross-device accessibility\n\nit's only half a solution for the metadata leak problem... the whole solution requires both sides to be online, which is impractical for many reasons\n\nan equally half solution would be for relays to ALL require NIP-42 and only give out DMs and other privileged messages to users whose key appears in the event either sender or tagged receivers or mentions\n\nneither solve the problem that only being online simultaneously solves, and no, simplex et al don't solve this problem, they cache the messages in a middleman situation and they additionally don't have multi-device capability so actually the problem is not wholly solvable, but devs making relays are not doing anything about making what solutions CAN be made, ie, NIP-42, and on the client side, the situation is just as bad\n\nand almost in no case can you count on having even one end of a connection actually capable of inbound connections... wireguard VPNs would solve this problem also, and could be bundled with a paid relay service to further increase privacy\n\nyou simply cannot have an async message delivery system without a middle man, and that is a privileged position that cannot be avoided without direct connection and the internet's routing setup still doesn't allow direct connections to be established from all points on the network - most users are behind routers that do not automate giving out port forwards to clients and so there has to be rendezvous services for all peer to peer systems that don't have at least one side able to listen for inbound connections\n\nbecause there's not a lot we can do about this, we are stuck with the also half-solution of using Tor network, which is an absurdly low bandwidth system and just like this problem with DMs in nostr, clients that support actual p2p direct connections via hidden services basically don't exist and there used to be one called torchat but they changed the API and nobody was funding the maintenance of the project so it was abandoned\n\nit's a big problem, and we are still stuck with trusting someone\n\ni'd trust a nostrich and bitcoiner any day over google and amazon, and i'd trust a little data centre in the boondocks that accepts bitcoin long before i'd trust those cloud providers, and this is possible, right now\n\ni'm not a \"means to an end\" kinda guy nor am i complacent about the fact that the situation is shit but there is things we can do about this, and the apathy is appalling\n\n#whinge #devstr #security #privacy",
"sig": "a9f97e059bde825975e5e7a7f0c6c6aeff4f749ef9ea06c376c16b1374d721cb5346c37bbd39cbcc450313672bb109157291212fdf36c0ecf5ef0ee5c20f3533"
}