> White Noise stands out by merging Nostr’s decentralized network with advanced encryption.
How does White Noise address criticisms surrounding Nostr's implementation[1]:
> While nostr offers the ability to send encrypted DMs to user pubkeys, the metadata of these messages are broadcast publicly via relays. This is the same as a bitcoin transaction being viewable on the public ledger. The contents of the direct message will be encrypted, but other metadata like the sender and recipient can be viewed by anyone.
Even assuming if metadata is encrypted, does WN's implementation broadcast messages across public relays?
If you can map out social networks based on publicly available data, can tell if one user messages another, or correlate when messages were sent to/from whom, I would not call that private.
There was a project called Bitmessage which solved this problem by not having a recipient field. Your client would just try to decrypt everything, and when it succeeds, that means the message is for you.
The then immediate issue is routing becomes very inefficient since every node now needs to receive and attempt to decrypt every single message. Which they solved by having channels to split up the network and only require decrypting of every message on the same channel as your address.
(fwiw, I'm not the creator of this, but am a casual user of Nostr...)
tl;dr: the answer you're looking for is probably in the explainer doc [1].
At its core, Nostr is simple: it's "just" JSON over WebSockets. But there are dozens of optional proposals to add additional functionality. And a few of those proposals are related to encrypted DMs, specifically, NIP-04 [2], and NIP-17 [3]. Most of the online criticism of encrypted DMs on Nostr is about NIP-04 (which is why it's deprecated.)
White Noise is using a different encryption standard: MLS (Messaging Layer Security) [4]. They explicitly say in their docs: "White Noise is an implementation of the NIP-EE spec." [5]. The NIP-EE proposal itself is on GitHub [6]. The explainer doc [1] I first mentioned is linked to from the proposal [6].
This is all to say: given all the links I posted here, an AI chatbot could probably give you a better answer using the prompt:
"How is NIP-EE (Messaging Layer Security for Nostr) different or better than NIP-04 or NIP-17?"
(I'm a little surprised that wasn't already in the FAQ for the project.)
Lol, nostr metadata leak was a criticism of NIP-04 , which has long been considered obsolete NIP-17 messages addressed this long time ago, but it was not scalable to large groups. MLS solves this problem so we finally have, scalable, private, decentralized messeging on the internet, all these specs are public, the very fact that you did not understand this, means no one will be able to make you understand with a comment.
As someone who used to be in the Secure Scuttlebutt community an now works on OpenMLS, I wonder how they (you?) deal with concurrency of Commit messages. I spent quite some time thinking about ways to detect and resolve forks, and the current iteration of MLS doesn't really have good answers here.
As much as I love the idea of these secure messaging apps, until I see how a company responds to government intimidation I am always wary of being too invested and trustworthy of the marketing.
i admit i havent looked at the app, but i assume is centrally run.
firstly: i think the only way secure p2p messaging can work is if its decentralised. no 3rd parties to communication, how this would be done i have no idea. maybe like email but without the server?
secondly: you'd need to ensure a secure os on each end that you can trust to not take screenshots and send to hq before transmission or after reception.
since its not possible to use the internet without a source ip. its almost provably insecure (in terms of privacy), no matter what protocols are dreamed up. a 3rd party will have to be trusted to distribute packets. and thats the weak point. (unless you force the source IP to be 0.0.0.0 or something before it goes out)
couldnt we just use dns to point to recipients, force zero the source ip and send udp packets directly?
> i admit i havent looked at the app, but i assume is centrally run.
I don't mean to be rude, but why comment then? Your core premise was incorrect, which could have been resolved within 5 seconds of reading the headings on the page linked.
The file/image storage concept using whats called "Blossom server" needs to be explained publicly somewhere. I don't know anything about this concept of "storing private files on public servers" and it immediately screems at me as unsafe.
Looks super interesting. I am waiting for the App Store release since TestFlight is full. I like the idea of not requiring a phone number - the only thing makes Signal lose some points in my eyes... well, I guess if the company goes down that might be another reason for open protocols over apps.
Software advertising itself as "A truly secure and private messenger" raises my skepticism. It might be truly secure. Its creators might believe it is and have zero doubt that they've made no errors and there are no flaws. Or it is neither and they want me to think it's those things. The only thing definite is that it claims to be truly secure.
heavyset_go|7 months ago
How does White Noise address criticisms surrounding Nostr's implementation[1]:
> While nostr offers the ability to send encrypted DMs to user pubkeys, the metadata of these messages are broadcast publicly via relays. This is the same as a bitcoin transaction being viewable on the public ledger. The contents of the direct message will be encrypted, but other metadata like the sender and recipient can be viewed by anyone.
Even assuming if metadata is encrypted, does WN's implementation broadcast messages across public relays?
If you can map out social networks based on publicly available data, can tell if one user messages another, or correlate when messages were sent to/from whom, I would not call that private.
[1] https://ron.stoner.com/nostr_Security_and_Privacy/
SchemaLoad|7 months ago
The then immediate issue is routing becomes very inefficient since every node now needs to receive and attempt to decrypt every single message. Which they solved by having channels to split up the network and only require decrypting of every message on the same channel as your address.
heavensteeth|7 months ago
shark_laser|7 months ago
I haven't looked into the White Noise code, but Gift Wrapping is just one way this issue was solved a long time ago: https://nips.nostr.com/59
hugs|7 months ago
tl;dr: the answer you're looking for is probably in the explainer doc [1].
At its core, Nostr is simple: it's "just" JSON over WebSockets. But there are dozens of optional proposals to add additional functionality. And a few of those proposals are related to encrypted DMs, specifically, NIP-04 [2], and NIP-17 [3]. Most of the online criticism of encrypted DMs on Nostr is about NIP-04 (which is why it's deprecated.)
White Noise is using a different encryption standard: MLS (Messaging Layer Security) [4]. They explicitly say in their docs: "White Noise is an implementation of the NIP-EE spec." [5]. The NIP-EE proposal itself is on GitHub [6]. The explainer doc [1] I first mentioned is linked to from the proposal [6].
This is all to say: given all the links I posted here, an AI chatbot could probably give you a better answer using the prompt: "How is NIP-EE (Messaging Layer Security for Nostr) different or better than NIP-04 or NIP-17?"
(I'm a little surprised that wasn't already in the FAQ for the project.)
EGreg|7 months ago
abhsag|7 months ago
hiimkeks|7 months ago
As someone who used to be in the Secure Scuttlebutt community an now works on OpenMLS, I wonder how they (you?) deal with concurrency of Commit messages. I spent quite some time thinking about ways to detect and resolve forks, and the current iteration of MLS doesn't really have good answers here.
miloignis|7 months ago
https://github.com/nostr-protocol/nips/blob/001c516f72943081...
ktallett|7 months ago
abhsag|7 months ago
sak5sk|7 months ago
globalnode|7 months ago
firstly: i think the only way secure p2p messaging can work is if its decentralised. no 3rd parties to communication, how this would be done i have no idea. maybe like email but without the server?
secondly: you'd need to ensure a secure os on each end that you can trust to not take screenshots and send to hq before transmission or after reception.
since its not possible to use the internet without a source ip. its almost provably insecure (in terms of privacy), no matter what protocols are dreamed up. a 3rd party will have to be trusted to distribute packets. and thats the weak point. (unless you force the source IP to be 0.0.0.0 or something before it goes out)
couldnt we just use dns to point to recipients, force zero the source ip and send udp packets directly?
what about pgp through a tor relay?
botanical76|7 months ago
averageRoyalty|7 months ago
I don't mean to be rude, but why comment then? Your core premise was incorrect, which could have been resolved within 5 seconds of reading the headings on the page linked.
abhsag|7 months ago
shark_laser|7 months ago
Nostr can run over TOR.
SeriousM|7 months ago
shark_laser|7 months ago
Run your own fork if you don't trust this one.
esafak|7 months ago
high_priest|7 months ago
I've only been able to find this coverage on the Blossom thing: https://www.nobsbitcoin.com/blossom-intro/
sak5sk|7 months ago
STELLANOVA|7 months ago
https://arxiv.org/pdf/2002.04609
skeptrune|7 months ago
patchtopic|7 months ago
hackernudes|7 months ago
I started my reply thinking it was still using Tauru but apparently things change fast!
wrftaylor|7 months ago
journal|7 months ago
gblargg|7 months ago
untitled2|7 months ago