sajolida:
> intrigeri:
>> > sycamoreone wrote (22 Jan 2016 16:04:33 GMT) :
>> [...]
>> > I see five main instant messaging use cases that I would want Tails to
>> > support to some extent:
>> >
>> > A. Contributing to Free Software projects that use IRC chatrooms
>> > (and won't switch to anything else any time soon)
>> >
>> > B. Contributing to Free Software projects that use non-IRC chatrooms
>> > (e.g. we are switching to XMPP, not sure what else is around)
>> >
>> > C. One-to-one chat that is compatible with currently widespread practice
>> >
>> > I think that means XMPP + OTR, nowadays.
>> >
>> > D. One-to-one chat that protects metadata end-to-end
>> > (that is: "who is chatting with whom")
>> >
>> > This suggests Ricochet or similar.
>> >
>> > E. Public chatroom for Tails user support
>> >
>> > Currently, Pidgin addresses B + C, and not D. In theory it also
>> > addresses A + E, except that connecting to e.g. OFTC directly is not
>> > reliable, so a more geeky setup is needed in practice.
>
> Good point!
>
> Still, I'm afraid of mixing up here stuff that Pidgin is doing already
> or is intended to do (A, B, C, and E) and stuff that Pidgin was never
> meant to do (D) if we're talking here about "simplify the problem of
> replacing Pidgin".
I am also for keeping D separately. But the blueprint should document
the use-cases A, B, C, and E that Pidgin and its potential replacement
should address. And also the use-case D that it need not.
> I could think of other instant messaging use cases or properties that
> are still not in your list (private group chat, search and archive past
> public communications, offline-friendlyness, etc.)
>
> For more a nice list of properties people are playing with, check
> https://dymaxion.org/essays/pleasestop.html. Whether or not you like the
> message and the style, the list of properties is interesting.
Yes, the problem here is not even the clients, but designing the
protocol and deciding which (often contradictory) properties it should
have in the first place.
There are other interesting takes on this, that also look at how one
could implement the desired features, at what we currently *can do* and
what we *can't do* with cryptography, and at existing approaches.
The best resources I am aware of are
* Leap's The big seven hard problems in secure communication
https://leap.se/en/about-us/news/2013/the-big-seven
* The "SoK: Secure Messaging" survey article, with a more academic
flavor, which tries to bring some order into the many protocol
properties people have thought of.
http://www.jbonneau.com/doc/UDBFPGS15-IEEESP-secure_messaging_sok.pdf
Fortunately we are *just* looking for an XMPP/IRC client with
OTRv2/OTRv3 support.
>> > I don't know of any tool that provides D _and_ another one among A,
>> > B and C. So for the moment, I think that D should be solved separately.
>
> Exactly.
Yes. Another blueprint maybe at some point? There are not many options
out there yet (Ricochet and Pond basically?), but this is a very active
area of research right now and I am sure that more clients will emerge
in the next years.
Cheers!
