Potential Serialization Flaws
=============================

The structure has a couple immediately obvious shortcomings.

First, the maximum message size is 4,294,967,260 bytes (not including
compression and metadata). It could well be that in the future there will be
more data to send in a single message. But equally so, a present-day attacker
could use this to halt sections of a network using this structure. A short-term
solution would be to have a soft-defined limit, but as has been shown in other
protocols, this can calcify over time and do damage. In the end, this is more of
a governance problem than a technical one. The discussion on this can be found
in :issue:`84`.

Second, there is quite a lot of extra data being sent. Using the default
parameters, if you want to send a 4 character message it will be expanded to 123
characters. That's ~29x larger. If you want these differences to be negligible,
you need to send messages on the order of 512 characters. Then there is only an
increase of ~22% (0% with decent compression). This can be improved by reducing
the size of the various IDs being sent, or making the packet headers shorter.
Both of these have disadvantages, however.

Making a shorter ID space means that you will be more likely to get a conflict.
This isn't as much of a problem for node IDs as it is for message IDs, but it is
certainly a problem you'd like to avoid.

Because the reference implementations support all of these potential resolutions
(excepting environment variations), this means that the overhead will drop away
after ~500 characters. Communications with other implementations may be slower
than this, however.