> Bitcoin is compact because the data is immutable and has to be stored by all nodes. Nostr only has to store data where people need it — size is not as important when eliminating redundancy is cheap and pipelined, adding mere microseconds of latency.

I get your point, and for the size of the network it's probably not that important. But I would argue that all resources from a design point of view should be considered to be at a premium at all times. Squeezing everything you can out of a resource is good. Efficiency is good. It's why the standard fuel economy of light vehicles has now reached 25 MPG. This is in line with the Bitcoin point of view, and I think it applies to everything.

> I'm not disagreeing in principle with the benefits of binary encoding. But between SIMD hex codecs and hash functions, flate compression, and the broad support without any of the complexities that gRPC/protobuf ties you to as a developer, I would argue to skip the "use a good existing format" step.

Fair enough. Though, I disagree with the notion that there are complexities in protobufs. Paying careful attention when designing formats actually avoids future complexities like the ones we're talking about right now. The formats are immutable, and only need to be compiled once per target language.

> Signature verifications, however, are problematic. A canonical encoding used to create the signature is necessary, no matter how you wire- or disk-encode it. It's the biggest friction point for Nostr moving to a better, binary format.

But that's the crux of my argument. Everything is downstream from here. Everything would be simpler and more efficient if that was designed correctly. It avoids having to have conversations at all about lookaheads in JSON codecs. It would abide by the principle that the simpler mechanism lasts longer. As I'm sure you're aware too, transforming formats isn't really possible when signatures are involved without having to do work the other way for verifications.