[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tox.im
On 7/8/14, "Å?ukasz \"Cyber Killer\" Korpalski" <[email protected]> wrote:
> W dniu 07.07.2014 16:55, rysiek pisze:
>> Dnia poniedziaÅ?ek, 7 lipca 2014 16:06:47 DÄ?vis MosÄ?ns pisze:
>>> I don't agree, I think XMPP could be good solution, while yes attack
>>> surface is quite large but it will be in any case, because even if you
>>> create the very minimalist chat protocol possible (let's say basically
>>> use
>>> asymmetric cryptography for messages which are plaintext without any
>>> features) you still can have bugs in cryptography library, network
>>> stack,
>>> OS/kernel. This part will be same no matter what messaging protocol you
>>> use.
>>
>> Exactly. And that's an argument for NOT minimizing the attack surface
>> beyond
>> these problems... how exactly?
>>
>> I mean, your argument is basically: "don't wash your hands, as there might
>> be
>> salmonella in the eggs anyway". Dafuq?
>
> I'm going to defend XMPP too, but on the grounds that it's an already
> established and widely used protocol, the overhead is minimal looking
> from a modern point of view (even when not using the potentially
> privacy-risky elements) and it was designed to be extendable. These are
> imo good arguments to use xmpp instead of creating something new (again
> :-P ).
As has been said over the decades: start correct, 'good' easy
to maintain code, secure of course, and optimize later,
eg 1-1 mapping from XMPP (XML I assume?) to say msgpack:
MessagePack: http://msgpack.org/ - a fast, binary replacement for JSON
Such optimizations ought be behind a library anyway!
(From user app point of view.)
As someone else said, think of the stack, separate the concerns:
IP, user addressing, persistence of ids, persistence of addresses,
crypting, dht, distributed storage, libs, user apps.
For impatient programmers wanting instant gratification,
work on one layer in the stack.