Re: [Tails-dev] Requirements for a Pidgin replacement
heya, ghostla...@autistici.org wrote (09 Feb 2016 00:05:38 GMT) : > I think I lost track of the original message that started referencing the > options > according to letters :) The thread starts there: https://mailman.boum.org/pipermail/tails-dev/2016-January/010113.html and the use cases letters were formalized there: https://mailman.boum.org/pipermail/tails-dev/2016-January/010121.html > I'd like to suggest an end alltogether of all-in-one communication clients. > It may > fit a Windows-style mode for use, but it contradicts one of the more elegant > and > sensible parts of the Unix philosophy, that being one application per task. I'm not convinced this works for end-users who need to learn more than one tool, but I have no strong opinion. Cheers! -- intrigeri ___ 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.
Re: [Tails-dev] Requirements for a Pidgin replacement
Hi! ghostla...@autistici.org: > Anyway what I'm getting at is in order to facilitate simplicity I think > it might be helpful to talk about these things in terms of protocols or > types of delivery that Tails wants to prioritize (rather than using > client examples as the article of dialogue), and then choose a discrete > and simple client for each, which will probably change of course as time > goes by; ideally the protocols Tails supports in one way or another > will not. Basically yes about simplicity and being able to change things, but I think the correct level of abstraction here is *use-cases* and not protocols or clients. This is also the level the "message that started referencing the options according to letters" was talking about. Some of the use-cases (A. and B.) map to protocols very directly. Others like "Public chatroom for Tails user support" do not though. I also don't believe that there should be one big communication-client, but the use-cases that IRC and XMPP satisfy are very similar, so one client for both might be a good idea usability wise. I am not sure. Please feel free to add your ideas to the blueprint: https://tails.boum.org/blueprint/replace_Pidgin! 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.
Re: [Tails-dev] Requirements for a Pidgin replacement
I think I lost track of the original message that started referencing the options according to letters :) I'd like to suggest an end alltogether of all-in-one communication clients. It may fit a Windows-style mode for use, but it contradicts one of the more elegant and sensible parts of the Unix philosophy, that being one application per task. Anyway what I'm getting at is in order to facilitate simplicity I think it might be helpful to talk about these things in terms of protocols or types of delivery that Tails wants to prioritize (rather than using client examples as the article of dialogue), and then choose a discrete and simple client for each, which will probably change of course as time goes by; ideally the protocols Tails supports in one way or another will not. Using this perspective, it looks to me as if there are really only a grand total of four clients needed here: SMTP, XMPP, IRC, and some form of serverless system. Is this thought disruptive in a good way or bad? It just doesn't seem like the hunt for an all-in-one client is going to be a good design choice in the long run, especially when individual clients can come relatively cheap size and code-wise. gl On 2016-01-27 10:01, intrigeri wrote: sycamoreone wrote (26 Jan 2016 22:03:00 GMT) : sajolida: intrigeri: 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. Yes. I see that it's been done already (with a new nomenclature), cool! > 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. I'm glad we agree on dealing with D separatedly. 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.
Re: [Tails-dev] Requirements for a Pidgin replacement
Would this be an acceptable point to introduce the suggestion of a serverless communicator of some kind being included? Uses should be obvious, but in case not, it eliminates some MITM options and reduces reliance on infrastructure outside the intended participants. Some examples: Tox - definitely isn't mature enough yet (hasn't had any external audits) Ricochet - very reliable/stable (though a bit stagnant) and made to work with Tor onion services exclusively Serverless chat in XMPP (xep-0174, no known mature implementations) Ring (from Savoir-Faire) - development in full swing with a large and active team Ring and Ricochet are the strongest candidates as far as I can tell, but people with better knowledge of ideal crypto implementation might want to look over their choices. In any case, I'd like to see it in Tails, even if it has to mean including two separate clients. gl On 2016-01-27 10:01, intrigeri wrote: sycamoreone wrote (26 Jan 2016 22:03:00 GMT) : sajolida: intrigeri: 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. Yes. I see that it's been done already (with a new nomenclature), cool! > 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. I'm glad we agree on dealing with D separatedly. 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.
Re: [Tails-dev] Requirements for a Pidgin replacement
sycamoreone wrote (26 Jan 2016 22:03:00 GMT) : > sajolida: >> intrigeri: > 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. Yes. I see that it's been done already (with a new nomenclature), cool! >>> > 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. I'm glad we agree on dealing with D separatedly. Cheers! -- intrigeri ___ 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.
Re: [Tails-dev] Requirements for a Pidgin replacement
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.
[Tails-dev] Requirements for a Pidgin replacement
Hi, Thanks for sharing this! sajolida: the list of properties is interesting. Great list. Communication tools like Trello and Slack are used by Microsoft and the like to make communication tools. Though their employees have zero privacy concerns (: Wordlife, Spencer ___ 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.
Re: [Tails-dev] Requirements for a Pidgin replacement
intrigeri: > sycamoreone wrote (22 Jan 2016 16:04:33 GMT) : >> there has been some desire to replace Pidgin with some other IM client >> (#8573). [...] >> In order to be able to decide when/if a client is a suitable replacement >> for Pidgin, it would be good to have a concrete list of requirements. I >> once started to collect some in a blueprint [...] > > Thanks a lot for raising this, and collecting requirements. > > I'd like to take a step back, since I wonder if we've defined the > problem in a way that we can realistically solve it. Something on the > blueprint suggests the same: "Would a pair of two separate client > (XMPP and IRC) also be okay, or are we only looking for a single > client that can do both?" > > My goal here is to *simplify* the problem to solve, and possibly to > split it into smaller, more reastically solvable problems, as needed. > My goal is definitely *not* to make the problem harder and discourage > those who are working on it already, or would like to join the fun. > > 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 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. > 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. ___ 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.
Re: [Tails-dev] Requirements for a Pidgin replacement
Hi, sycamoreone wrote (22 Jan 2016 16:04:33 GMT) : > there has been some desire to replace Pidgin with some other IM client > (#8573). [...] > In order to be able to decide when/if a client is a suitable replacement > for Pidgin, it would be good to have a concrete list of requirements. I > once started to collect some in a blueprint [...] Thanks a lot for raising this, and collecting requirements. I'd like to take a step back, since I wonder if we've defined the problem in a way that we can realistically solve it. Something on the blueprint suggests the same: "Would a pair of two separate client (XMPP and IRC) also be okay, or are we only looking for a single client that can do both?" My goal here is to *simplify* the problem to solve, and possibly to split it into smaller, more reastically solvable problems, as needed. My goal is definitely *not* to make the problem harder and discourage those who are working on it already, or would like to join the fun. 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. I'm not sure what to do with the E use case. In theory we support it, and I like our current design with random nickname generation a lot, except that it does not work (reliably). This situation has been showing up repeatedly for years, and we've not made great progress to fix it, so I don't know if we can honestly say it is a MUST. To be fair, we should compare other options for E to what we _really_ have had in the last few years, not to what our current implementation would give us in an ideal world. So, for example, I think I would personally be ready to drop the "automatically generated random nickname" requirement, and ask users to create themselves a XMPP account to join a tails@conference.some_xmpp_server multi-user chatroom: something like that, which is well documented and works reliably, would provide better UX than a simpler option that one can't count on IMO. And then, most likely a tool that addresses B + C would also work for this use case. And then, if we find another, user-friendly and safer, way to address B + C, then I guess that it could replace Pidgin, and A can be downgraded to a geeky option, for which everyone picks their preferred tool (irssi, Pidgin, whatever) and connection setup (SSH tunnel, SSH + remote client in screen/tmux, whatever). 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. Cheers! -- intrigeri ___ 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.
[Tails-dev] Requirements for a Pidgin replacement
Hi, there has been some desire to replace Pidgin with some other IM client (#8573). While this won't happen soon there are now at least two potential alternatives: the Tor Project's Tor Messenger (#8577) and the CoyIM client, based on agl's xmpp-client (#8574). In order to be able to decide when/if a client is a suitable replacement for Pidgin, it would be good to have a concrete list of requirements. I once started to collect some in a blueprint https://tails.boum.org/blueprint/replace_Pidgin/ but didn't come very far. I believe my personal requirements are not particularly representative (I dislike notifications for example) and I don't want to try to second-guess requirements of others. So, if you care about a particular feature in Pidgin, then it would be great if you could add these features to the blueprint or send them here! 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.
