signal still leaks metadata to servers. Have you looked at SimpleX?

Reply to this note

Please Login to reply.

Discussion

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

Typo: *...a message for the receiver for it to get there...

I was under the impression that he was referring to more than metadata, but he wasn't. Either way... thank you.

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.

https://simplex.chat/#how-simplex-works

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.

https://wiki.bitmessage.org

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.

https://optoutpod.com/episodes/s3e02-simplexchat/

Three years old, yet I have never seen it brought up before, while the design spec sounds ideal. Does it have a catch? Haskell?

Doesn't scale well for large public group chats like telegram, which is ok, since it's privacy focused.

Listen to the lastest opt-out pod episode with the creator.

#[3]

Shit. Sorry, mate. Haha