I humbly request that the term “secure channel” never be shown to users. It’s scary, and vague, and a non-technical user will have no idea what it means. It’s vague for a technical user, too, because “secure” doesn’t mean anything specific, it’s qualitative.
Perhaps something along the lines of “public” vs “private” instead of “secure” vs “insecure”? It’s equally qualitative but may have more resonance with a non-technical user because it’s about people, not technology.
I’m also curious why first messages cannot be “secure”? Can’t you encrypt them with the receiver’s public key and be done with it? Or is that not PFS?
I feel like the friction of having to request someone as a contact before being able to talk to them is extremely painful and brings you more into the “social network” category and away from the “universal messenger” category. An analogy would be having to exchange names and phone numbers before being able to talk to someone at a bar, or at the bus stop. Conversations are not always between people who know each other, or want to know each other.
@patrick personally I’d rather not wait until ENS goes live as it adds dependencies across initiatives, also we don’t really have a solution for non-stateofus.eth if we ever want to support it.
I still see value even if we don’t need the ux in 6 to 12 months, as it would have served its purpose, but I am all for more ux research if needed.
@noman thanks for the input, I will only address the technical points here:
I feel like the friction of having to request someone as a contact before being able to talk to them is extremely painful
mind that only in a few scenario (which will be the minority of the cases), this user-flow is required (namely copying and pasting an ethereum public key, which will be discouraged, and using ENS, which is not live yet)
I’m also curious why first messages cannot be “secure”? Can’t you encrypt them with the receiver’s public key and be done with it? Or is that not PFS?
That is what we are currently doing now and does not have PFS properties (the compromise of your private key would allow an attacker to decrypt past sessions), the initial message (contact request) is exchanged using public key, we use Diffe hellman to decrease the possibility of a compromise, but still does not guarantee pfs.
I’d just like to say that I love that at Status anything less than perfect forward secrecy is considered insecure enough to warrant a user warning. I’m all for it.
Thanks again @cammellos for going through all the explanations. So it sounds like we will always have this use case for when Alice tries to contact Bob using a public key? Sorry if I misunderstood this point.
I’m all for the approach and thanks as well to @denis and @maciej for putting together designs so quickly. To follow up on Hester’s question:
what does Chad see as long as the contact request has not been accepted?
Do we allow Chad to continue the conversation with a clear icon/visual indicator + text that this is an nonsecure channel? Or not allow Chad to chat at all? Which is probably not desireable.
I would also go for this, to keep inline with our principles we don’t want to allow user to send messages through “unsecure” channels, keeping in mind that this is only if the user adds a public key (discouraged, contact code will be used instead), or ENS (support is not in the app yet)
Also, this is the source file I’m working on, so it will always be up-to-date and reflect my latest work. You can leave comments there directly and browse all Chat specific designs on other pages. Selecting objects on canvas will give you all of their properties required for implementation.
I’m all for it.