🚨 WHITE NOISE LIVE DEMO! 🚨

Today is a big milestone. I'm now 100% sure that MLS messaging is going to work on Nostr! 🤙 I've been optimistic for weeks now but... you never know until you write that last line of code that ties it all together.

Personally, this project has stretched me way out of my comfort zone. I'm a web dev, not a cryptographer! I also didn't really know much about memory management or compiled languages before getting started on this project. Suffice to say, I've come a long way! 😊

It's not quite ready for use, but I'll have builds out very soon.

https://v.nostr.build/TNOG9ZGYjLEpeIlz.mp4

For those that don't know much about the project, I recommend finding my past MLS updates on Highlighter. Or just ping me here – I'm happy to answer questions.


So awesome! Bullish!

Ready for prime time in two weeks, right?


Coffie on me ☕


Pushing the limits


nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc pushing the limits 🔥 #MLS

nostr:nevent1qvzqqqqqqypzq9eemymaerqvwdc25f6ctyuvzx0zt3qld3zp5hf5cmfc2qlrzdh0qy88wumn8ghj7mn0wvhxcmmv9uq3xamnwvaz7tmjv4kxz7fwvcmh5tnfduhsqgz4x89nck2785y9m4zn9qhgp0ggygc8k234pljc6kpwjlsh5y59pv8pr0yn


Nice! Thanks for all of your hard work.🙏


Onward 🫡


LFG


MLS for large encrypted group chats is coming!
nostr:nevent1qqs92vwt83v4u0ggth29x2pwsz7ssg3s0v4r2rl934vza9lp0gfg2zcpzemhxue69uhhyetvv9ujumn0wd68ytnwv46z7q3qzuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsxpqqqqqqze7m60u


very stoked


:fire:


Two weeks™


I'm curious to know more, grazie!


:clapping:


About what in specific?


Excellent


Great, if i understand correctly, you send just one event for all group even with 10'000 partecipants?


Bzzzp 🤜🏻⚡🤛🏽


A facc ro’ cazzo! 🔥


Amen to that! 🫡


👀 👀 👀

nostr:note125cuk0zetc7sshw52v5zaq9apq3rq7e2x587tr2c96t7z7sjs59svwv0fj


Nice dawg can’t wait!


Just about MLS messaging, will have to dig around on Highlighter


Get rid of that NIP-04 support


exited for it 🔥

nostr:nevent1qqs92vwt83v4u0ggth29x2pwsz7ssg3s0v4r2rl934vza9lp0gfg2zcppemhxue69uhkummn9ekx7mp0qgspwwwexlwgcrrnwz4zwkze8rq3ncjug8mvgsd96dxx6wzs8ccndmcrqsqqqqqp5hh7n0


as an amateur cryptographer, this anti-nip-04 thing is completely nonsensical

chacha-poly-1080 in not stronger than AES 256 ... what is it CBC? ... no, AEAD... with no actual extra data btw, so it was pointless making it that anyway

the giftwrapping enables some degree of forward privacy but it also makes it complicated for clients to see messages the user wrote, and i notice this all the time clients are not seeing the messages

after making my relay really nice and easy to extend and work with one of my first priorities is making messaging work properly

like, seriously, do people not get it the reason why i am always talking about nip-42 auth all the time is so you can prevent access to these messages in the first place?

the right way to do things is to test and certify that relays are not allowing access to events they don't have proof of being in the conversation

it also applies to application specific data events too, which are encrypted, by some clients, but not by others (looking at you #nostrudel )


Coffee on me ☕


I don't need demo code. I need a white paper and auditing.


seriously, has anyone actually thought through the problem of implementing clients to pull messages that contain no reference to a user without leaving them wide open for anyone to read?

first rule of signals intelligence is don't send a signal you don't want to be noticed for its mere existence, or at worst, exposing you to a potential plaintext attack if the encryption has a flaw

i honestly don't think that anyone else in nostr dev really understands the problems they are trying to solve with nip-04, nip-44, and the rest


Nice work man!


JeffG, you are a rockstar!


Aloha 🌈


The main issue is that nip-04 leaks way too much data not only to the relay, but to the public in general. On top of that, the encryption procedures of NIP-04 are laughable. The lack of padding alone is a major problem. Imagine saying "Hi" on a DM and that gets converted to 4 encrypted chars. Besides letting everyone know your message is small, how hard is to break the encryption of a 4 char cipher text? Not that hard.

If you repeat GMs around, now you have 100s or 1000s of 4 char encrypted messages. How hard would it be to recover your shared key knowing all those little messages? Not that hard.

With enough shared keys, how hard would it be to figure out somebody's nsec? It gets in the realm  of "possible" with today's available computing power.


Is there a tool to request deletion for all sent nip4 dms? Asking for a friend😂


nostr:npub1ltwg5grjyz2xallh6qyxl9mxcsnucfzej04xe75xmn25had5z65qvfsala probably we have hope get rid of that DM monitor bot 🫣


Onward 🫡


i'm not sure you understand the function of encryption nonces, they ensure that for every message the secret is effectively a new one... there is zero chance of a plaintext attack in this, so long as the quality of the entropy of the nonce is adequate

i agree that there should be padding but i don't think it should be the stupid "pad out to next power of 2" of nip-44 is retarded

it should just be a random amount extra and you just put a zero byte at the end of the actual string and fill the rest with garbage... i've written what i think is an adequate message length obfuscation method on indra

so, yeah, no, there is zero risk of a plaintext attack even if people keep saying "hi" over and over again in their messages

the nip-44 scheme is seriously wasteful of data size with its power of two scheme, and doesn't really help anything, and it doesn't matter if the padding is noise or spaces because it's already obscured by the combination of the shared secret combined with the nonce

auth and not letting users see other people's messages solves way more problems than this retarded complicated nip-44 scheme, that is also wasteful of data size


Huge, great work Jeff!


this is why i'm so mad about people not understanding the point of nip-42 and it's centrally about the fucking DM privacy!!!!

plaintext attacks are not a real threat

not being able to read your own messages is a real threat to usability

verifying that relays are properly gating access to DMs is easy and cheap and is easy to stop any attempts to game this and appear that you are not giving them away

yes, relays have privilege to see them of course, but this is far better than opening up the whole world to see it

nip-44 is not solving any real problems for DMs compared to having auth


Feel free to offer better padding. Padding was discussed at length before and after nip44 and directly audited by the firm. No one has proposed anything better yet.

I strongly disagree with your "zero risk of plain text attack". There are folks here, with money, whose sole goal is to break our encryption.


🙏 Thank you!


🚨 WHITE NOISE LIVE DEMO! 🚨

Today is a big milestone. I'm now 100% sure that MLS messaging is going to work on Nostr! 🤙 I've been optimistic for weeks now but... you never know until you write that last line of code that ties it all together.

Personally, this project has stretched me way out of my comfort zone. I'm a web dev, not a cryptographer! I also didn't really know much about memory management or compiled languages before getting started on this project. Suffice to say, I've come a long way! 😊

It's not quite ready for use, but I'll have builds out very soon.

https://v.nostr.build/TNOG9ZGYjLEpeIlz.mp4

For those that don't know much about the project, I recommend finding my past MLS updates on Highlighter. Or just ping me here – I'm happy to answer questions.


not that i know of, we should really be sending DMs with expiration tag set


the leak to the public is because of relays not implementing auth

at minimum, they should implement auth to access DMs

if everyone's relay did this, that problem goes away

it's never a better solution to use obfuscation when you can instead simply not send out the signal


any repository link


Yes, once you in the group, you only need to publish a single event that all members of the group can then decrypt and view.

The largest event is actually the welcome/invite event because it has the whole tree/group state included in it. It doesn't start to become an issue until the group is ~150 (based on the max size of nostr events) but there are a few ways I've thought about to get around that so it's not that concerning.


Here's a link https://highlighter.com/jeffg.fyi


the public leak is because relays are not implementing auth and until recently almost no clients did either

this is a really small change that prevents this leaking, the main threat

users can control their use of relays and if it is discovered a relay is run by spooks, then people can avoid it

it's not rocket science... don't allow access to DMs without auth. end of.

making complicated obfuscation schemes are not going to help, because "giftwrap" just means the receiver is mentioned not the sender

how does a client migrate this data across to other clients the user is using if they then have to literally search for other people's DMs that *might* have been sent by them

you really need to think a lot more about what the actual problems are instead of wrapping it in more and more complicated encryption schemes


Going to replace it with NIP-17 😂 But yes, it's going for sure.


awesome work jeff! 👏👏


zero risk of plaintext attack it's an encryption algorithm that has been in use everywhere for more than a decade that has not been broken

it's only retarded clients not providing good entropy, that has been the only vulnerability that has ever been demonstrated, and not just for symmetric encryption, but also for signing as well, as was found with a number of bitcoin wallets in past years that didn't use good entropy for the signatures, enabling the discovery of the secret keys

not only that, senders don't have to use their actual key as their public key for the message, only the receiver's public key has to be the actual one used by the receiver

so, good quality nonce, good quality random new private key to use the encryption, i mean, really, how can there be a plaintext attack if there is two quality obfuscation factors and the only constant is one out of three?

even, clients can refuse to send DMs to a relay that doesn't demand auth for access to DMs, as far as actually protecting the users without adding cognitive burden

putting a fancy lock on a door made out of cardboard isn't going to change the easy way to access - in this case - the metadata

compared to a strong door (auth) that doesn't give you any information about the existence let alone the actual content of messages that are privileged


Thanks!


We can't control how implementers code. This is nostr. There is weird stuff everywhere. There are evil relays tracking users, evil clients tracking users, relay devs not knowing any better, clients not knowing any better. Most of the nostr code out there doesn't even think about privacy. We can't design a protocol expecting that everyone will have good entropy, good code or an authed service. All we can do is to offer primitives that makes sense even if everything else isn't there.

Everything you said has been said during the NIP-44 debates and they culminated with NIP-44, NIP 59 and NIP17. But feel free to offer an updated variant of all of the above.


LOVE FROM UTAH 🧡


yeah, this is an essential feature, and nobody is prioritising it as they should be

it's like putting a big fancy padlock on a shitty wood and cardboard gate, to add all this obfuscation to the messages when you could just have auth and not send out messages that don't relate to an authed user pubkey

really, you can't solve that problem any other way

the relay is acting as an untrustworthy intermediary when it doesn't have controls to prevent strangers reading your private messages


you are never going to solve this problem while you let stupid people building shitty clients (and not you, or hzrd or hodlbod, you all have implemented auth) you can't protect users from bad shit without at least providing your own system with teh right best practices implementation

if you let other people's bad designs impact your engineering decisions and in doing so reduce the security of your users, that's on you, you can't palm that off to the dumbasses who don't do it right... clear up your understanding of what you CAN do and stop talking about difficult problems that are much harder puzzles


I red you asked about max kind size, does the group state change each add/remove a member? or are there other cases?
Thanks


Onward 🫡


yeah, it's simple enough to have clients require auth to access DMs, then you put pressure on the relay operators and devs to make that a priority feature

it's not really a technical problem, more of an education problem


BIG DOG


Great post 👍


The group state does change with each add/remove but those are handled via commit messages that only make delta changes and don't require the full group state to be sent around.


👀

nostr:note125cuk0zetc7sshw52v5zaq9apq3rq7e2x587tr2c96t7z7sjs59svwv0fj


Cool


Great Job man!


Built a (basic) CLI tool, https://github.com/f321x/nip04-wiper, seems like a bunch of relays ignore the delete request though.


⚡⚡/A\  |R)  \V/  |I|  |N|⚡⚡


good work


Awesome! Feels good man .jpg


awesome


Cool, great progress Jeff!


Thanks!


Nice one Jeff. Congrats! 🤗


Great work Jeff, highly anticipated and super exciting developments. Thanks for your efforts and keep up the good work!


neat script !

i don't see a specific reason why they'd ignore it, it looks correct to me

but i guess some relays are just really shitty about that
they'd ignore expiration tags for sure, too


This will get ideas flowing for other use cases as well. Keep thinking outside the box.  Well done Jeff!

nostr:nevent1qqs92vwt83v4u0ggth29x2pwsz7ssg3s0v4r2rl934vza9lp0gfg2zcpz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzq9eemymaerqvwdc25f6ctyuvzx0zt3qld3zp5hf5cmfc2qlrzdh0qvzqqqqqqy6cs9xd


🚨 WHITE NOISE LIVE DEMO! 🚨

Today is a big milestone. I'm now 100% sure that MLS messaging is going to work on Nostr! 🤙 I've been optimistic for weeks now but... you never know until you write that last line of code that ties it all together.

Personally, this project has stretched me way out of my comfort zone. I'm a web dev, not a cryptographer! I also didn't really know much about memory management or compiled languages before getting started on this project. Suffice to say, I've come a long way! 😊

It's not quite ready for use, but I'll have builds out very soon.

https://v.nostr.build/TNOG9ZGYjLEpeIlz.mp4

For those that don't know much about the project, I recommend finding my past MLS updates on Highlighter. Or just ping me here – I'm happy to answer questions.


There is definitely a narrative that nostr event should be permanent which I guess some relays enforce. Guess that's the most "delete" we can get😃


:purple-heart:


Onward 🫡


Amazing work man!! Will there be windows or a web version some time down the line?


I think in many cases relays simply haven't implemented it


sats at ya 🏌


It’s been slow going because I’m building it to be native multi platform out of the gate. MacOS, windows, linux, android, and iOS.


That was quick! Congratulations sir 🫡

Will this be the first production-ready MLS protocol client?


Wow that's some effort your putting in man. Hats off to you!


some relays literally don't have it implemented

it requires some extra pieces to work, you have to keep tombstones of the event id to prevent it coming back, and that necessarily implies an eventual need for garbage collection in general

and yeah... expiry... i'd implement that on my relay if i knew of a client that i want to use that has it, because that's a cool feature, especially for DMs... it can also function like a dead-man switch too, as part of a system to enable stale follow npubs to be removed (because those damn follow lists seem to be like ratchets, only going in one direction, bigger, because if people don't post they don't see and don't think of deleting


it won't be that way forever... something i want to do with my relay is have it actually propagate delete events when it receives them so everyone who might actually do it can find out it is requested


congrats ser! very impressive


No there are a few centralized services like Wire and one of the Cisco products. As far as I know this is the first fully federated/decentralized one though.


it's that kind of "everything must be permanent" blockchain mindset that held me back from even trying nostr for a long time

it makes sense for public declarations and publishing, but not for day to day private life social media stuff, and even less so for DMs


Aloha 🌈


This sounds very useful, i also imagine part of the problem is just getting the delete event distributed. For now I used a blaster relay but they also only send to the X biggest relays. Would be cool if clients would rebroadcast important events like delete too.


Lezgoo 👊


This is all I can find, but maybe  nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc has a spec, someplace, with some second-party reviews.

https://habla.news/u/jeffg.fyi/MLS-over-Nostr-Oct-4-2024-ugrsvw


Great post 👍


fuck U money


Nice post! 😁


Brrrilliant


Incredible!


hand on a second.. it was thursday yesterday?

Today is friday. friday is demo day 😂


Amazing bro. Big lift! Well done!

Also, great name 🤌🤌🤌


🐝 Self-custodial zap straight from my Alby Hub 🐝


Amazing 🔥


You should be very proud. This is a big deal.


Pay for the audit then, be the change you want to see


🚨 WHITE NOISE LIVE DEMO! 🚨

Today is a big milestone. I'm now 100% sure that MLS messaging is going to work on Nostr! 🤙 I've been optimistic for weeks now but... you never know until you write that last line of code that ties it all together.

Personally, this project has stretched me way out of my comfort zone. I'm a web dev, not a cryptographer! I also didn't really know much about memory management or compiled languages before getting started on this project. Suffice to say, I've come a long way! 😊

It's not quite ready for use, but I'll have builds out very soon.

https://v.nostr.build/TNOG9ZGYjLEpeIlz.mp4

For those that don't know much about the project, I recommend finding my past MLS updates on Highlighter. Or just ping me here – I'm happy to answer questions.


No Stronly 🫡


Nice POC man 🔥🤝

This is exciting!


yeah, i think it would be really cool if clients would also send out all of a thread you reply to to all of the configured relays so everything stays in context


Onward 🫡


Wow! Amazing work!


well done


Additional context for this here:

'The Past & Future Of DMs And Private Group Chats On Nostr', a presentation by Jeff
https://www.youtube.com/watch?v=PWKd9aoZ-Cg
nostr:note125cuk0zetc7sshw52v5zaq9apq3rq7e2x587tr2c96t7z7sjs59svwv0fj


Nice!


An important step forward! Thank you!


this is a big one!


Great work


More 🌽 for you


LFG🔥


I need a spec first


Congrats on the milestone! Your enthusiasm is infectious! 💪✨


Thank you 🙏


Read the MLS spec then read the NIP-104 PR.


Excited for this! Thanks for all that you do!


Bullish on all the new #nostr apps!!!


This update marks a major milestone for the project. I know, with certainty, that MLS messaging over Nostr is going to work. That might sound a little crazy after so many months working on the project, and I was pretty confident, but until you’ve got running code, it’s all conjecture.

Late last week, I released a video of a working prototype of [White Noise](https://github.com/erskingardner/whitenoise) that shows the full flow; creating groups, inviting other users to join those groups, accepting invites, and sending messages back-and-forth. I’m thrilled that I’ve gotten this far but also appalled that it’s taken so long and disgusted at the state of the code in the app (I’ve been told I have unrelenting standards 😅).

If you missed the video last week...

nostr:note125cuk0zetc7sshw52v5zaq9apq3rq7e2x587tr2c96t7z7sjs59svwv0fj

## What's Next?
In this update, I want to cover a few things about how I'm planning to proceed and how I’m splitting code out of the app into libraries that will help other developers implement MLS messaging in their own Nostr clients.

First off, many of you know that I've been building White Noise as a Rust app using the [Tauri](https://tauri.app) framework. The [OpenMLS](https://github.com/openmls/openmls) implementation is also written in Rust (with bindings for many other languages). So, when you hear me talking about library code, think Rust crates for now.

The first library, called [openmls-nostr](https://github.com/erskingardner/openmls-nostr), is an extension/abstraction on top of the openmls implementation of the MLS spec that helps Nostr clients interact more easily with that implementation in a way that feels native to Nostr. Mostly this will be helping developers interact with MLS primitives and ensure that they’re creating, validating, and serializing these objects in the right way at the right times.

The second isn’t a new library as a big contribution to the already excellent [rust-nostr](https://github.com/rust-nostr) library from nostr:npub1drvpzev3syqt0kjrls50050uzf25gehpz9vgdw08hvex7e0vgfeq0eseet. The methods that will go in rust-nostr are highly abstracted and based specifically on the requirements of NIP-104. Mostly this will be helping developers to take those MLS primitives and publish or query them as Nostr events at the right times and to/from the right relays.

Most of this code was originally written directly in the White Noise library so this week I've started to pull code for both of those libraries out and move it to its new home. While I’ve been at it, I've been writing some tests and trying to document things.

An unfortunate offshoot of this is that the usable builds of White Noise are going to take a touch longer. I promise it’s still a very high priority but at this point I need to clean a few things up based on what I've learned thus far.

Another thing that is slowing down release is that; behind the scenes of the dev work, I’ve been battling with Apple for nearly 2 months now to get a proper developer team set up so that we can publish the app via TestFlight for MacOS and iOS. I’ve also been recently learning the intricacies of Android publishing (oh my dear god there are so many devices, OS versions, etc.).

With that in mind, if you know anyone who can help get me up to speed on CI/CD, release pipelines, and multi-platform distribution please hit me up. I would love to learn more and hopefully shortcut some of the pain.

Thanks again so much for all the support over the last few months! It means a lot to me and is a huge part of what is keeping me going on this. 🙏

This is a long form article, you can read it in https://habla.news/a/naddr1qvzqqqr4gupzq9eemymaerqvwdc25f6ctyuvzx0zt3qld3zp5hf5cmfc2qlrzdh0qqxnzdenxqeryvpjxuenvvf597jwps


Thank you for putting in the work, I feel like the payoff could be huge. 🙏


But that would be work! I demand an audiobook!


Onward 🫡


Looks dope!


🤯

nostr:nevent1qvzqqqqqqypzq9eemymaerqvwdc25f6ctyuvzx0zt3qld3zp5hf5cmfc2qlrzdh0qqs92vwt83v4u0ggth29x2pwsz7ssg3s0v4r2rl934vza9lp0gfg2zcd5mup2


Great post 👍