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.
