Replies (68)
👀
Big talk!
Awesome, look forward to seeing what comes of this!
🤣🤣🤣 💯
And action. Have you seen how complex the MLS spec is?!
NIP 137
NIP 209
NIP 333
NIP 666
NIP 9000
... #lol #nostr
Stepping up the game.
them ostriches are multiplying! 😂
A nostr based signal like app would be so cool. To just use my nsec to login instead of making an account…
Signal and users of others have to beg to get people to move messengers… if we all just had a nsec and logged in… would be great
Will they be undeletable too?
Wow, sounds fantastic!
👀
Keychat.io uses signal protocol
Excellent, can't wait!
🫡
You lost me at "E2EE" - the false advertising there is basically gaslighting people about backdoors such as the closed-source firmware in almost all consumer electronic devices
What? So "the world is fucked and any attempt to unfuck it is futile" thats a good approach to life
RIP NIP-17. Long live NIP-104!
If you think false advertising and gaslighting are attempts to unfuck the world, rather than what is fucked about it, go fuck yourself
How is updating to this spec different to any of the previous ones from nip-04?
thank you for putting the work in!
🔥
Well let's say a new fully open source hardware device with open source firmware comes about. We would need this software to run on it, right?
Major League Soccer is trash!
Too early considering NIP04 is still there 🤣
I was just wondering how this works currently! Awesome that you’re working on this! Keep hammering 🔨🔨🔨
This software probably also requires an OS and you might as well make your own messaging software while you're making the OS
I didn’t know that a Ratchet Tree was something missing from my life until just now
The major difference is that this support secure groups.
The other major benefit over NIP-17 (which is still very good for DMs) is that you get forward and post compromise security with this, meaning your messages aren't all leaked if your identity key leaks at some point in the future.
I think that NIP-17 is still a really good spec. It's just that it doesn't handle groups or give you any forward or post-compromise security. Meaning if your identity key leaks, then all your conversations for all time have leaked.
But, it's very easy to show messages across multiple devices and clients with NIP-17 which is nice for simple clients that might not need high security.
It doesn't quite work like that. The messages that are sent in the DM or group chat are decrypted on the client that has access to the group. Once the message is decrypted the client throws away the decryption key (for forward secrecy). But keeps a separately encrypted log of the chat.
This is what happens with Signal, Whatsapp, etc. Each device keeps a copy of the transcript but at no point are they trying to rebuild the conversation from past messages (because they no longer have the cryptographic state to do that).
Make sense?
It's definitely a trade off with this sort of approach; security for convenience in using lots of devices or different clients.
That's 100% the plan. The ability to use your main Nostr identity OR create disposable identities at will to join groups will be game changing.
Private Messaging is probably solved for a long time without needing any centralized intermediary.
🫂
🫡
GM Nostr! 🌞
In case you missed it...
View quoted note →This looks very promising... but probably hard to implement
Yes!! So excited for this. I think Nostr Messaging could be the killer use case for nostr if done well. When most messaging options are compromised.
it'll be implemented in key libs by gigabrains for the pleb devs to use.
I agree! I can't wait to get started on the client that implements this.
This is why I've spent so much time working on and understanding the OpenMLS library. It's a really solid open source implementation of the MLS spec that I think most client devs will use to implement this NIP.
Of course, once this NIP gets some feedback and settles down I'll start work on implementing it myself and adding the necessary abstractions to NDK (and other nostr libraries) to make it easy on client devs.
That said, it's quite different to the way that people think about DMs so far. Each client keeps it's own chat transcript and has it's own set of keys and state so it's less "syncable" than something like NIP-04 or NIP-17 DMs.
Right on dude
can't wait to securely slide into DMs
Would personal servers (with relays running on them) solve the "less syncable" issue? That is, rather than the edge device / client having the chat transcript, an always-on personal server would have this and mediate your chats for you, hydrating your various edge devices with a single chat state
Perhaps optionally. Like modes for "just keep it on this device" and "keep it on this device but I'm a server and will provide it to other devices when asked".
Assume a secure connection between the personal server and all one's edge devices such that clients act more like remote controls for the "main agent" on the server.
what is it going to be called? please tell me it won't end with "str"
What's upstr
Signalstr
Telegramstr
Hell yeah. Building the future that you want to see.
🤣
No str.
Yup. This is definitely an option for syncing chat transcripts. And it would be implemented at the client/application layer.
I am not sure I got the last part. You mean I won’t be able to move my conversations between clients ?
Strignal lol
So, each client counts as a distinct member of the group. Which means that you have to individually join the group from each client that you want to use.
On the surface, this sounds annoying, but it's the same thing that you're doing with Signal or Whatsapp when you connect with the desktop app. You're just inviting your new client to the chat and then that client has it's own set of keys and state and goes forward as an independent client.
The app itself makes sure that your messages from those distinct clients show up as from the same person. And the app itself could have the ability to sync your chat transcript between the two devices but that's not handled at the spec level here, it's handled at the application level.
Does that clarify?
Jeff hell of a write-up. It seems like the key management for group messaging might be tricky when trying to jump from one client to the other, but not sure this can technically be made simple due to the inherent nature of MLS.
So on the spec level there is a group of keys that are authorized to the conversation and on the app level some of the keys are the same person and need to be displayed that way?
Yes.
Thanks! Yes, that’s true. It’s certainly not as easy as pulling a bunch of events from relays and decrypting them.
Thankfully the mls implementations do a great job of managing most of the state. Clients that want to implement this need to think about secure storage of the prekeys (but this is pretty much the same as looking after someone’s nsec).
Ok, that seems to work well. I’m not familiar with MLS and how that’s performed by the client. So neat. Bravo on the DEEP proof of work putting this all together, Jeff!
sounds bullshit
Thank you brother! 🙌
LET'S FUCKING GO!!!
A ferragosto al posto che fare la grigliata con gli amici pubblichi queste cose! Sei proprio un nerd! 💙
🤣🤣 eh si. Dopo qualche settimana di ferie avevo tanta voglia di lavorare. La grigliata l’abbiamo fatto questo weekend.
client based chat transcript 🤔🤔🤔
I have to read more to think about the pros and cons.
But thanks for the work
