🚨 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.
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.
Replies (20)
on top of that, it doesn't make any sense to have a client that has fixed most of those issues make worse versions available to the user.
Users will just use the worse versions if it is available.
Talk to your relay operators. They can do this easily.
Huge, great work Jeff!
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.
Most people are not using authed relays for DMs. And likely they never will. The DM solution we made was explicitly designed for that in mind.
Agree. With it's not just AUTH as defined in NIP-42. It's AUTH + a p-tag filter based on the logged in user. Virtually no relay does this.
But even if it does. The relay itself SHOULD NOT be able to track anyone else but the user that connected.
Going to replace it with NIP-17 😂 But yes, it's going for sure.
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.
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
Nice one Jeff. Congrats! 🤗
Great work Jeff, highly anticipated and super exciting developments. Thanks for your efforts and keep up the good work!
This will get ideas flowing for other use cases as well. Keep thinking outside the box. Well done Jeff!
View quoted note →I think in many cases relays simply haven't implemented it
well done
I need a spec first
Congrats on the milestone! Your enthusiasm is infectious! 💪✨
Read the MLS spec then read the NIP-104 PR.
But that would be work! I demand an audiobook!
