<j​effro256:monero.social> This is my petition to name the unnamed, undocumented on-chain binary format in src/serialization. I've got a few options: 1) "Cryptonote On-Chain Organized Binary Object" (COCOBO). 2) "MOneRo On-Chain Compact Object" (MOROCCO), or 3) "Cryptonote On-Chain Organized Archive: Binary, Easy, And Non-Self-describing" (COCOA BEANS)

<j​effro256:monero.social> Comment which one is your favorite

<j​effro256:monero.social> I *need* to give it a name though, since we use at least 6(?) different types of binary formats in the core codebase: epee binary, portable boost archive, non-portable boost archive, whatever we're calling src/serialization/binary_archive.h, protobuf, and the ⭐bespoke⭐ binary messages that wallet2 uses to communicate with other wallet2 instances.

<b​oog900:monero.social> I normally just call it consensus encoding, not as fun tho :)

<r​brunner7:monero.social> > and the ⭐bespoke⭐ binary messages that wallet2 uses to communicate with other wallet2 instances

<r​brunner7:monero.social> Huh? Care to elaborate?

<r​brunner7:monero.social> Out of your 3 naming proposals, my vote goes to *MOROCCO*

<s​pirobel:kernal.eu> maybe something similar to epee that sounds cute like ewee

<s​pirobel:kernal.eu> also short and easy to remember

<s​pirobel:kernal.eu> apparently someone made a theme song for it already youtube.com/watch?v=tXWiQ4zwIvY (that can help serve as an example on how to pronounce it)

<s​needlewoods:monero.social> I like COCOA BEANS

<j​effro256:monero.social> Like for exporting key images, outputs, and multisig messages. The binary data packets are just some handmade format prepended with a "magic string", not using of the aforementioned binary formats.

There should be a version in that magic string, you can make it use the chain format if you want. It seems too trivial to bother at the time.

<j​effro256:monero.social> This is true, wonder how hard it would be to refactor it as such

<r​brunner7:monero.social> Well, if you want to be nice, you have to support the old format in parallel for an indetermined time anyway, so the gains look a bit questionable

<j​effro256:monero.social> The precedent for these inter-wallet2 messages has been to *not* support old versions AFAIK

<r​brunner7:monero.social> You mean way back at a time where all Monero users could meet in a small restaurant? :)

<s​pirobel:kernal.eu> if it is not performance critical json is a good choice. the binary data can be named and turned into a hex string.

<j​effro256:monero.social> No i mean the last time that they were updated, so like 2018 ? Which tbf is still a long time ago in crypto-time