I’ll DM you an explanation for my idea that will end up never finished soon. 😂

don't need the ID there at all in the wire format, and it's only needed as an index in the database

you would have vitriol too if you looked too close at the code to see how much the politics influences the architecture in a very negative way

also, you would also have vitriol if people respond by focusing on the person instead of the engineering, so, please, keep it on topic

and answering the technical part of it

- compressing hex is, you know, rather simple, 50% if you know the field is hex

- a fixed ordering of fields instead of field names like in the JSON eliminates the need for labeling, it's literally just a set of offsets and length prefixes

- where you know the field is going to be binary, you can encode it as binary, in the expected length, i have used this in my runtime and database formats in my code - and there is a lot of places with this, field 2 in e and p tags, the decimal:pubkeyhex:string of a tags, the ID (which can be omitted) and the pubkeys and signatures all can be sent over the wire as binary, without any length prefix if they obey the ordering

bringing your opinions about programming languages and this RFC and that RFC is stupid we have options here we don't need to hitch our horse to some anonymous committeit over in Buffalo or Antwerp we are building our own protocol and we can easily come to agreement on the performance characteristics and limitations of implementations thanks to our diversity

fiatjaf was right in the way he designed the scheme pretty much, except on a few small points like why send the event in object format when you could have just sent the canonical form that means you literally can hash it on the spot and get the ID? verify the signature and two steps just got eliminated

i kindly invite you to go inspect the protocol specification of Bluesky and come back to me after you have digested the abomination for your opinions about teh use of CBOR