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!
