So I keep seeing suggestions from people on how NIP-04 is bad and how to fix it by tweaking small things. Why wouldn't it be better to copy the Signal protocol though?
Discussion
signal still leaks metadata to servers. Have you looked at SimpleX?
Does it really? Source?
Signal servers know all message metadata (timestamp, hash of participants ID, message size), the only thing they don't know is message content. If that model is ported to nostr, relays would know all metadata and if they don't restrict who can query it, any user can know all metadata.
You can't directly port it, but does it make sense to come up with a totally new protocol, instead of extending signal to these capabilities?
It already exists and it's already working, it's not a science experiment.
Signal is extended to nostr?
I meant that a new more private working protocol exists (simpleX), not that it was ported to nostr.
Do you have a link to the protocol description?
It's built into the protocol, and frankly, a somewhat inherit part of how most social networks work. You have to know an address for the sender for it to get there, if that is encrypted, than no one will know where their message is (unless every client is attempting to decrypt metadata for *every* message ever sent).
However, Signal has taken some exotic steps to reduce their ability to see those messages, namely leveraging enclave tech like SGX: https://signal.org/blog/building-faster-oram/
There are ways to obfuscate the identity of the sender/receiver, but that metadata still must be present unencrypted to allows messaging protocols to work. Maybe there's some crazy way to do it with quantum tech, but we're still a ways from that :D
Can you explain it in 4 lines?
To deliver mesages, instead of user IDs used by all other platforms, SimpleX uses temporary anonymous pairwise identifiers of message queues, separate for each of your connections — there are no long term identifiers.
You define which server(s) to use to receive the messages, your contacts — the servers you use to send the messages to them. Every conversation is likely to use two different servers.
This design prevents leaking any users' metadata on the application level. To further improve privacy and protect your IP address you can connect to messaging servers via Tor.
Only client devices store user profiles, contacts and groups; the messages are sent with 2-layer end-to-end encryption.
Wow, that kind fixes everything then. Why can't we abandon the idea of doing a Nostr-native messaging system and just embed Simplex clients inside Nostr apps?
The biggest hurdle would be interopability.
I don't know if it's feasible to integrate it or not, just brainstorming ideas.
SimpleX also works with relays in a similar model to nostr so maybe these can be the same?
Isn't it possible to implement a social network on top of SMP? Isn't that something they were planning on doing?
It had challenges, however bitmessage was pretty interesting.
I’ll checkout SimpleX.
If I understand the SimpleX protocol, this program translates the concept to nostr. The sender creates a new conversation key and directs recipients to a relay of their choosing.
https://gist.github.com/davestgermain/12974fef590fc1edf12e9a25b9dfa7b5#file-safe_dm-py-L82
Is something like this scalable? I imagine it's like a nightmare.
For a longer discussion about SimpleX you can listen to the latest opt out episode.
Three years old, yet I have never seen it brought up before, while the design spec sounds ideal. Does it have a catch? Haskell?
Part of the answer (and also why I don't like most of the ideas people have given on how to fix NIP-04) is explained in this commen#[0]ilger: https://github.com/nostr-protocol/nips/pull/306#issuecomment-1447563490
"There is a conflict between the user wanting no metadata, and the relay wanting to know who to charge or whether to bother hosting the event."
"If public relays are gracious enough to host these, there would be an incentive to game that by storing massive data under these events, and then relays would stop hosting these. I cannot see a way out of this pickle."
Signal still leaks metadata to servers (it even stores your phone number!) but I mean just the encryption and forward-secrecy stuff and whatnot. I just wonder why no one has suggested that. Isn't that the "industry standard"?
I am also thinking about the same! Why to reinvent the wheel?
What is not ideal in signal?
* you need a phone number
* you can't use any server
* might not be fully non-trusting for servers
* Might leak some meta, but I saw even ideas to circumvent that, so maybe this is not the case anymore.
The last point I am still checking, so don't take it as granted.
But otherwise it is
* end-to-end encrypted
* has forward secrecy
* uses ways to mitigate the risks of a key compromise
I think first point is easy.
The second and third point relates, which is the hardest part.
Also hard to keep the motivation of relays to support fully encrypted no-meta leaking messages
I think it is possible to do an adapted version of the Signal protocol using a special kind of relay and a special kind of message. The targeting and querying wouldn't use public keys, but single-use blind tokens that the relay servers wouldn't be able to associate with any entity (unless, of course, to an IP, but we can work around that later) but would still be able to account for, charge money for or use other forms of whitelisting.
This wouldn't be Nostr properly, instead it would be a different protocol, very similar to Nostr, but optimized for private communication. This way Nostr can be left as a public broadcasting service, which is what it excels in.
Anyway, if you have an idea of how this could work please talk about it or do something (as I said, I have a rough idea of how this could work, but it's not fleshed out and I don't give it a very high chance that I am correct on my hypothesis).
I see value in doing secure messaging over nostr rather than a separate network. With a network dedicated to secure messaging, you lose the effect of blending in with other types of use and thus leak more information to your network provider about your types of activity.
I do in fact see the public nature of relays as a potentially good thing for the core design of secure message delivery, as you're forced to minimize the trust in put in relays. The issue of trusting relays with traffic information (who sends and receives what) can be solved with separate solutions, used by users/clients that want better anonymity without affecting messaging compatibility with other users/clients.
I wouldn't see the issue of relays wanting to know the identity of its users specifically as a hindrance to secure messaging on nostr, but rather a problem that should be solved in and of itself. And as I mentioned in https://github.com/nostr-protocol/nips/pull/306 I think it can be solved with anonymous tokens based on blind signatures.
I'm using SimpleX, no ids, no metadata, relays based. Still under dev, messages work fine but no audio call.
Interesting, I was thinking how Signal should get rid of their shitcoin and leverage web5 but relaxing Nostr DM is nice too, with zaps:)
btw what’s your thought on the UK online safety bill’s impact on internet privacy and on Nostr?
https://www.internetsociety.org/resources/doc/2022/iib-encryption-uk-online-safety-bill/
I agree; also I'd add that rather than broadcasting the DM on multiple relays the user should have only 1 selected (in their NIP-0) for recieving messages to. PUSH only, don't store the content on the server after it has been recieved (like Whatsapp, not like telegram). Making it economic to host these relays for free.
Also I'd add, allow a binary node to node Noise communication protocol (even Wireguard is fine), so I can message someone via my own node who forwards it on to their selected node on my behalf. So I don't leak IP metadata when communicating to someone on a unique node. It can be done without Noise/binary but it considerably improves scalability to do it this way. Can be simple still - super simple but scalable would be Wiregard + BSON (binary json)
Your post is receiving a lot of attention.
Added to the https://member.cash/hot feed
I was under the impression that the Signal protocol won’t work in a system with decentralized identity because it assumes there is a sovereign identity provider (for Signal it’s the telephone system) and a keypair isn’t that. But I would love to be wrong about that.
At Planetary we’ve had our eyes on MLS, although it doesn’t do metadata encryption which is really important. https://en.wikipedia.org/wiki/Messaging_Layer_Security
You can copy it — but the part about hiding metadata while letting users still find their messages still has to be added.
About the incentives issue, you could leak only sender but use a “fake” receiver generated in a way the original receiver can identify.
Or you can use a throw away sender and “fund” it with a small per post payment.
Yet another way is revealing the actual sender only to the relay — but not publicly in the event itself. The public author for the event would be masked in a way only the receiver can identify.
There’s a “sealed sender” thing in Signal I don’t understand that might be useful though.
I recently proposed a minimal improvement just for the sake of being easy to implement — not to discourage better solutions.
I think one “problem” is that there are just so many ways of doing it with different tradeoffs, including different protocols to draw from, that it’s hard to see what would be best