Re: [Tails-dev] Requirements for a Pidgin replacement

Borrar esta mensaxe

Responder a esta mensaxe
Autor: intrigeri
Data:  
Para: The Tails public development discussion list
Asunto: 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@???_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