Thread

And action. Have you seen how complex the MLS spec is?!

🤣🤣🤣 💯

NIP 137 NIP 209 NIP 333 NIP 666 NIP 9000 ... #lol #nostr

them ostriches are multiplying! 😂

🫂

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.

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.

What? So "the world is fucked and any attempt to unfuck it is futile" thats a good approach to life

If you think false advertising and gaslighting are attempts to unfuck the world, rather than what is fucked about it, go fuck yourself

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?

This software probably also requires an OS and you might as well make your own messaging software while you're making the OS

Too early considering NIP04 is still there 🤣

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.

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.

it'll be implemented in key libs by gigabrains for the pleb devs to use.

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.

I am not sure I got the last part. You mean I won’t be able to move my conversations between clients ?

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?

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.

I agree! I can't wait to get started on the client that implements this.

what is it going to be called? please tell me it won't end with "str"

What's upstr Signalstr Telegramstr

🤣

No str.

Strignal lol

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.

Yup. This is definitely an option for syncing chat transcripts. And it would be implemented at the client/application layer.

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!

Thank you brother! 🙌

🤣🤣 eh si. Dopo qualche settimana di ferie avevo tanta voglia di lavorare. La grigliata l’abbiamo fatto questo weekend.