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
[email protected]
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
[email protected].

Reply via email to