"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,.
karakoram2 / Karakoram 2
npub1xx…qjx03
2023-04-15 16:13:33
in reply to nevent1q…jxa7
Author Public Key
npub1xxg8w6g5xkmftz5wrpr24t43u9x48faumat9ag3jndes05u74rmq9qjx03Published at
2023-04-15 16:13:33Event JSON
{
"id": "f611f208fb348a1be4795c1c2da4cd79102f802bce726f9133dab362137d988c",
"pubkey": "319077691435b6958a8e1846aaaeb1e14d53a7bcdf565ea2329b7307d39ea8f6",
"created_at": 1681568013,
"kind": 1,
"tags": [
[
"e",
"9d89ef468ec690f2177635b8c0fd589aca840de1a749a08a44de5b148654bb49",
"",
"root"
],
[
"p",
"32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245"
]
],
"content": "\"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).\n\nThe 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.\n\nIf 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,. ",
"sig": "4853cdc8cc8792c1342797d00f17be2169e024b5086c89666aabdc09f5196cc99e2a5a310a679179c08025f818eb4cac7863f212f75ec91a79d33cb6e0789586"
}