Using SimpleX messaging for DM instead of NIP4

[paulmillr]

This was discussed several times, and the idea that we can integrate SimpleX https://simplex.chat as a backend for direct messaging on the platforms.

In this thread I will evaluate SimpleX and the amount of work required to integrate it.

All facts, positive & negative (work in progress...):

• Boldly claims to be better than Signal on their website
• Had security audit by Trail of Bits
• Founded by Evgeny Poberezkin. He've created JSON schema validator 8 years ago, now 92M weekly downloads on NPM. UK resident, he worked at MailOnline for ~5 years. linkedin cv.
• Typescript API helper for CLI (not the implementation itself) is 2400 lines of code

[earonesty]

simplex is "trust me bro we'll delete your messages" to get forward security. it also doesn't handle mitm/identity issues, so we will still need to use nostr public keys.

it's not actually nostr. requires spinning up a new server.

encrypting and signing with the shared secret on nostr gets you dm's that work, are free of metadata leaks and are plausibly deniable, and free of spam, we will continue to do this for private dm's.

contacting "trail of bits" to see how long it would take them to review this single-line change to nip-44 for security

[earonesty]

it's not actually possible to handle mitm without a second verification. nostr public key handle this by having a social aspect to them (it's easy to know you're following the right person... over time, and you can build trust). i talked about this with simplex devs, and they said they don't really handle identity. indeed, they recently added the ability to "email someone a link".

[earonesty]

in additon the "ratchet" protocol will break any clients that want to load old dm's. simplex dms are ephemeral by design. so you will lose your history. with nostr, you can specify if you want your events to be ephemeral, or even give them a duration.

[paulmillr]

I think DMs should be ephemeral. Why would you argue against it?

[earonesty]

a user could be able to access their historical dm's when they log in to a new client. if that's not a requirement, cool. use simplex (or just build a ratchet on nostr... it's not actually very hard - you can use the same one simplex does). but for us, it's a problem if all the user's dm's disappear when they load their private key into a new app.

[paulmillr]

It's possible to preserve messages in ephemeral protocol.

It's not possible to "lose" messages in persistent protocol.

[earonesty]

trusting that a server is going to delete your message and that nobody intercepted it for later analysis..is I guess okay?

[earonesty]

I don't see that particular feature as being so valuable as to make a protocol so much more complicated though

[earonesty]

But I'm not opposed to using simplex. not very much at least. If everybody starts switching to it then we would just add support I guess. We would have to add some sort of nostr signing of the simplex key because they're not compatible

[epoberezkin]

Hey. Evgeny here. Happy to answer any questions.

On forward secrecy, it’s not related to relays deleting or not deleting messages - it’s about cryptographic guarantees of key agreement protocol.

On identity - SimpleX has no identity, it’s established by the users out of band (where the user got the link from defines the contact identity for a given user, but not for the network). Identity linked with public keys has the downside of non-repudiation, which is undesirable for DMs, but given Nostr already provides this identity layer it can be used of course, as long as these keys are not used to sign the messages, but only to connect.

[epoberezkin]

blog post

cool!

The first question to answer though, is which protocol should we use

The real choice is between using agent protocol and chat protocol - using low level SMP protocol would require a lot of work elevating the unidirectional queue mechanism to duplex communication with double ratchet. Agent protocols and implementations solve lots of these problems, so chat doesn't need to touch networking or encryption.

The trade-off is between interoperability with SimpleX Clients and independence of SimpleX Chat product decisions that are codified in the Chat protocol. Worth looking deeper into these decisions. The argument I've seen somewhere that JSON is wasteful doesn't really apply with fixed 16kb block sizes - they are much more wasteful than JSON...

17k lines of

The whole simplexmq is about 25, but will be less if you drop iOS notifications and XFTP for files...

Using SimpleX's chat protocol would also limit the message types we'd be able to encrypt.

Not a real concern, it's easy to extend with arbitrary messages in your own namespace. All protocol messages start with x. exactly to allow easy extension without namespace conflicts.

Another wrinkle is that the SimpleX protocol is AGPL v3 licensed, meaning proprietary software would not be able to interoperate

I think we all should see it as upside, no?

SMP has the same attack vector

I commented above, the trust model is very different. You could also adopt Tor approach of mitigating MITM between the clients and relays btw.

channels will be bootstrapped out of band

Nostr accounts are good for that, as I wrote above.

[staab]

I think we all should see it as upside, no?

A lot of projects in nostr are MIT or un-licensed, making it hard to incorporate stronger copyleft. I understand why you guys chose AGPLv3, it just makes it a little tricky.

Thanks for the comments. Do you have thoughts on group scaling? I'm hoping to build a groups implementation that uses a shared key in order to avoid signing/sending thousands of redundant messages. My personal target is about 3k people, but it would be nice to accommodate up to a million people in a group.

[epoberezkin]

thoughts on group scaling

lots of thoughts, but no final design. Current is a fully connected graph, in livestream I have presented the model with hosting members which has up/downsides, and this doc describes another approach to dissemination based on roumor-mongering protocol.

In the end, it all is about somehow deciding who should be connected to whom, and if the interests in the group were symmetric, it would have been easy, but they are not - large groups inevitably suffer from "celebrity problem" and moving from the model when everybody incurs size penalty (now) to the model where only "celebrities" incur it seems wrong, but celebrity posts should create more overall traffic in the group, but not more for celebrity itself...

[epoberezkin]

what do you think about light touch integration?

[staab]

A middle ground between timestamps and DAGs is vector clocks, that could help fix message ordering. Currently, nostr only uses timestamps, but vector clocks will likely be introduced at some point for messaging use cases. You can see my draft for groups on nostr at #706 — obviously more naive and management in centralized. What do you mean by light touch integration?