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.