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

Well, first. I will be submitting a C "reference" library for all nostr cryptography operations including nip44 to paulmillr hopefully in the next few months, that maybe they can include in the repo.

Yes I agree the nip44 spec can be quite confusing, and build heavily assuming managed runtime with extensive libraries are used. I found it difficult to translate the operations into binary and allocation free, (I would like to target hardware signers in the future)

I think I'm missing your concerns. Are you arguing mainly for the lack of privacy that encrypted messages could theoretically be distributed to whoever asks a relay nicely. Then yeah, concern for me to, but I believe that's the intention of the network at the moment. I believe you also are concerned with "metadata" regarding the nip-01 "wrapper" message containing the PM?

Finally, would have to think some more, but I would argue removing the relay portion would remove the "nostr" part altogether. I don't believe we intend to assume nostr PMs are meant to be ultimately private, but rather a reliable and ideally uncensored way to get private message content to others. I'd argue there is very little privacy in the entire nostr protocol, it's not in the design yet.

I agree nip42 is just trusting the relay. Not a good solution for end-user privacy. I want more privacy but man I can barely keep up as it is. I'm generally a low/no dependency dev, I get nervous when discussing technically complex solutions as wrappers. It allows for easy mistakes and common configuration errors. I think if we come up with a "solution" it should be part of the protocol, not relying to heavily on other "complex" oss communities. I know that sounds bad, but lately imo awesome lists are probably 60-70% abandon-ware and it's getting sad out there for oss. I've had to overhaul plenty of projects in just the past 4 years because I used a "popular" library that became abandoned. Seems way more common in front-end.

Reply to this note

Please Login to reply.

Discussion

No replies yet.