Tox.im

Dāvis Mosāns davispuh at gmail.com
Tue Jul 8 12:53:06 PDT 2014


I think it's unreal/unpractical and not worth going for and there's just no
benefits for it (just use proper binary serialization), JSON was meant as
human-readable serialization format and introducing binary format there,
then what was the point of using JSON in first place? Why not just some
proper binary serialization? (eg. Protobuf). It just really seems that
people throw a lot of stuff on JSON, XML and others even if it was never
intended to be used for those purposes. There are different tools each for
it's own specific purpose and people should not abuse them.

Current JSON parsers treat " as special token to separate strings, so if
you want to include " in JSON you've to escape, so it will be "\"" and now
with any binary encoding you're complicating this because either you've to
escape " or track whether you're inside binary data or not and it will
crash for non-binary aware parsers. Also what about NUL bytes? I bet most
parsers are implemented in C/C++ using typical char * null-terminated
string, how'll pass this JSON to someone? because well NUL...



2014-07-08 22:22 GMT+03:00 Cathal (Phone) <cathalgarvey at cathalgarvey.me>:

> Biggest FAIL in json is lack of binary. I think a quick extension to
> bencoding is in order: "u<len>" prefix for utf8, "b<len>" for binary. Other
> types are pretty generally useful as-is. Replace "d", "l" and "e" with
> curly and square braces for readability.
>
> Bencoding's structure and basic idea is nice as it's terse and
> understandable, but also easy to make security guarantees about: length
> prefix, and on parse errors just dump the input and error out. Minimal
> overhead for raw binary, which is what you want for crypto, file transfers,
> and VoiP streams. Trivial to write in any language so rapidly portable, and
> can be coded recursively with relative ease without sacrificing
> understandability or security (much).
>
> Thoughts? Bencoding 2.0?
>
>
> On 8 July 2014 17:05:22 GMT+01:00, "Dāvis Mosāns" <davispuh at gmail.com>
> wrote:
>>
>> 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 Google Protocol Buffers
>> <https://developers.google.com/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 <zen at freedbms.net>:
>>
>>> On 7/8/14, "Łukasz \"Cyber Killer\" Korpalski" <cyberkiller8 at 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.
>>>
>>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 6976 bytes
Desc: not available
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20140708/008456ed/attachment-0001.txt>


More information about the cypherpunks mailing list