Nostr Web Client

CBOR

you see, there is a problem, i don't like cbor after dealing with it in my work with bluesky

so why do you love it so much? why do you prefer it compared to msgpack or protobuf or flatbuffers or capnproto?

keep in mind this needs to connect together apps written in go, rust, javascript, java, c, c++ and maybe at least reasonable support for python and c#

from what i've seen, and it's been a while since i've looked that close, protobuf was the most well and fully-supported across all of these languages

personally, i would want to use flatbuffers, and currently the Go version of this protocol encoding is shitty, but i could imagine myself reworking it in a month or two into something that is really natural to use with Go, because i have already in fact written an on-demand protocol buffer encoder, twice, in fact, simple TLV thing that was based on ad-hoc dynamic interface array message descriptors

Reply to this note

Please Login to reply.

Discussion

Rand 1y ago

frphank 1y ago

CBOR is RFC standardized, protobuf is Google's personal pet project and with their schemas usually also too complicated.

DETERMINISTIC OPTIMISM 🌞 1y ago

🎯

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

as someone who works with interfaces and not variants i don't like any protocol that doesn't have static typing and i honestly don't see the point of complex rpc specification compilers when it's just a friggin function call

about 10% of cases, partial failures can happen that should really return an error and a partial value (eg, a result being an array of fields from an array of inputs) but nope, can't do that with typical C++/Rust error handling idiom

this forces you to design APIs as single shot rather than batched which is a pretty rigid and performance limiting way to do things, especially when it is easy to aggregate queries to be handled by for example databases with concurrent queuing (especially distributed ones where the processing can be fanned out to multiple servers)

i say, if you make the client and build out a relay interface go ahead, make your hipster CBOR encoder API

but for the love of God do not make up your own fancy new RPC API if you do not intend to support a sufficient range of common language bindings, NATIVELY... just take the json and binary encode it, don't fuck around

Silberengel 1y ago

Yeah, protobuf is gRPC standard, like nostr:npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzuskcqsyn suggested.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

i think in all this debate people just need to make a relay/client pair that understand the new protocol and done

Silberengel 1y ago

I don't understand why they want to standardize this. Different devs will want different protocols and it's irrelevant to core interoperability because you can always communicate over json.

Tim Bouma 1y ago

All I really care about is signed events that I can parse and verify with a npub. Plus a few conventions around kinds. If signed events can be serialized for more efficient transmission, great, but that’s icing on the cake.

MichaelJ 1y ago

Yup! Cryptographic identity and standardized data shapes are the most fundamental parts of Nostr. It's too hard to get devs to agree on everything else, so implementations will vary widely. If we keep to that core, though, we'll retain basic interoperability.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

that's why i say make a binary encoder and runtime format for it like the ones i have designed

https://github.com/mleku/nostrbench

there is no way that anyone can make it faster than what i have done short of writing it in assembler, and it's such a short piece of code that it should be possible to implement it in any language

i am pretty sure that even javascript can deal with the binary 32 and 64 byte fields in the encoding so similar dramatic improvements in performance as you can see in those benchmarks should be possible, while also enabling a pure binary encoding and a binary detached hash and signature associated with it

just like fiatjaf made nostr json a custom thing instead of jsonrpc2 like bitcoin uses for RPC, we should have a custom binary codec just like what chain data uses on bitcoin

the hard part is going to be people who insist on javascript and python or the necessity of it for web apps, but even there, i am pretty sure you can make my codec into wasm modules and done

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

https://github.com/mleku/realy/blob/dev/event/binarymarshal.go and https://github.com/mleku/realy/blob/dev/event/binarymarshal.go are the in and out for the format, containing the ID and the signature of the json form

it's faster than fiatjafs and it's what i use in my database implementation