karakoram2 on Nostr: "Could be a simple TLV format" -- I would caution against developing custom formats. ...
"Could be a simple TLV format" -- I would caution against developing custom formats. Many have tried to develop these formats and in almost all cases, it is far worse than the already standardized schemes such as avro/protobuf mainly cuz missed use cases or schema backward/forward compatibility issues. It is also hard for newbies to onboard on to these formats (although bitcoin chose custom formats but its history predated the standardized forms).
The only scheme/method that was different from previous standardized ones was flatbuffers by google-- they provided a way to decode without actually deserializing the entire payload at the expense of larger data payloads for big schemas.
If I were to do it, I'd just add an api to nostr that handles avro(for ex) and whether it is binary or json becomes merely a transport layer responsibility. It also standardizes and enforces at the schema level what fields are to be expected with what types.. etc,.
The only scheme/method that was different from previous standardized ones was flatbuffers by google-- they provided a way to decode without actually deserializing the entire payload at the expense of larger data payloads for big schemas.
If I were to do it, I'd just add an api to nostr that handles avro(for ex) and whether it is binary or json becomes merely a transport layer responsibility. It also standardizes and enforces at the schema level what fields are to be expected with what types.. etc,.