"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,.

Reply to this note

Please Login to reply.

Discussion

Flatbuffers and protobuf are meant for generic data formats that evolve over time. Nostr is a fixed data format, protobuf is overkill.

Even lightning uses TLV. Works great and is simple.

40 years.

😏

I agree TLV seems fine if you’re just encoding a stable schema. worst case is you’re incrementing types and clients have to add another case to their switch statement… which we already do with ‘kind’ today.

I'm curious what javascript/typescript library do you recommend to play around nostr apis?

I’m not much of a JS/TS guy but even I have been able to be successful with nostr-tools:

https://github.com/nbd-wtf/nostr-tools

exactly

But new NIPs might introduce new tags. Should we consider this as well?