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