[SirGiggles]

Wouldn’t the ETF (Erlang Term Format) suffice in this case?

IIRC it’s used in the desktop client and some community libraries (specifically JDA) have support for it.

There were some quirks regarding ETF usage with Discord’s Gateway but I can’t recall at the moment.

[jerf]

Erlang terms are, to a first approximation, the same as JSON for most relevant communication metrics.

To a second approximation it gets more complicated. Atoms can save you some repetition of what would otherwise be strings, because they are effectively interned strings and get passed as tagged integers under the hood, but it's fairly redundant to what compression would get you anyhow, and erlang term representations of things like dictionaries can be quite rough:

    3> dict:from_list([{a, 1}, {b, 2}]).
    {dict,2,16,16,8,80,48,
          {[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},
          {{[],
            [[a|1]],
            [[b|2]],
            [],[],[],[],[],[],[],[],[],[],[],[],[]}}}

Even with compression that's a loss compared to '{"a":1,"b":2}'.

Plus, even if you're stuck to JSON one of the first things you do is shorten all your keys to the point they're as efficient as tagged integers on the wire anyhow ("double-quote x double-quote" can even beat an integer, that's only 3 bytes). Doesn't take a genius to note that "the_message_after_it_has_been_formatted_by_the_markdown_processor" can be tightened up a bit if bandwidth is tight.

It isn't clearly a loss over JSON but it is certainly not a clear win either. If you're converting from naive Erlang terms to some communication protocol encoding you're already paying for a total conversion and you might as well choose from the full set of option at that point.

[SirGiggles]

Sorry I want to apologize, I made an error in my initial statement and meant Erlang _External_ Term Format instead of Erlang Term Format.

Does this change anything w.r.t your response?