yeah I agree that using XML was bad idea in XMPP design, there's no
   good reason to use it, but XMPP is already thought out unlike any new
   protocol. But actually I think could use same XMPP protocol and just
   map on different encoding. What is XML?  basically it's just a language
   for data mapping (an encoding) and it would be perfectly possible to
   use same XMPP protocol concepts and map them on different data
   structure. And this is the thing I think should be pursued for. Which
   encoding to use is debatable. I would say using [1]Google Protocol
   Buffers are perfect for network protocols. I haven't investigated how
   good is MessagePack, but it could be usable too. Only about JSON and
   similar I don't like that they're "type-less", they have just some
   basic data types like String, Number etc and you loose information that
   way, say you've uint32 and you store and transmit that with JSON and on
   other end it will be probably int64 because that CPU is 64bit, of
   course you could find shortest fitting type, but that's not practical
   because you don't know limits of this field, maybe next message it will
   be bigger. In Protobuf there's types for everything int32, unit64 and
   so on.

   2014-07-08 11:25 GMT+03:00 Zenaan Harkness <[2]zen@freedbms.net>:

   On 7/8/14, "Łukasz \"Cyber Killer\" Korpalski"
   <[3]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: [4]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.

References

   1. https://developers.google.com/protocol-buffers/
   2. mailto:zen@freedbms.net
   3. mailto:cyberkiller8@gmail.com
   4. http://msgpack.org/