On 7/8/14, "Łukasz \"Cyber Killer\" Korpalski" <cyberkiller8@gmail.com> 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.