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! _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.