Secure and private messaging - what properties do we want?

This post is one of several seed posts. It’s based on a lot of discussions, and in particular Jacek’s secure messaging compendium, Secure Ethereum messaging study compendium - HackMD, and related discussions.

In particular, we want to understand what properties we want support, and how we should go achieving those.

To start with:
Perfect Forward Secrecy
Plausible deniability is also nice, although arguably whisper already offers that, by explicitly setting the d flag when posting messages (although that’s fairly weak probably), or avoid signing the message altogether.

We should not forget the essentials - low latency and sufficient throughput for implementing more demanding communication modes such as audio and video.

Often these essentials are at odds with the rest of the requirements. For example, the lowest possible latency will be achieved with a P2P architecture similar to WebRTC, but this partially reveals your location to the other party due to the known IP address. The ISPs also get to see how is talking to who, which is undesirable. The solution may involve using Whisper, onion routing, creating fake random traffic or other measures that have various trade-offs. We need to think how many of these technical details are reasonable to expose as configuration options for our users.

Perfect Forward Secrecy seems pretty straight-forward compared to these other concerns.

Seems fair,

just to understand the scope of this discussion, I was under the impression that we were mainly talking about text messaging here, given the current state of the app, rather than audio/video as those are topics that probably needs to be explored in separate threads.
Should we clarify a bit better the scope of the discussion?

Video and audio chat are often expected in a “messaging app”, so it’s probably something we should at least have in the back of our heads, even if it isn’t the primary focus right now.

It could be that the protocols we use are completely separate and they have different guarantees. If so, we need to figure out how to communicate this to the end user. Or it could be that we choose not to do sync video chat. Or maybe a “Revolution mode” drops anything that doesn’t support dark routing.


@oskarth seems like it becomes difficult to discuss all of these in a single thread, just distilling the questions asked:

  1. Should we do video/audio
  2. Which security guarantees we want to provide for audio/video
  3. Revolution mode audio/video

I think we should discuss in different threads otherwise the scope is too broad (not arguing we should not discuss those, just having more streamlined conversations)

1 Like

I’d like to see image support. Users can send/receive images.

Resiliency to DoS and DDoS attacks.

I think audio and video are going to be important to mass adoption, so they should always be “in the back of the mind.” as oskarth said.

Must have. I am researching on this.

Any progress after one year?