there is nothing stopping it, it's really easy to implement, at least in #golang i could have a gRPC/protobuf version of the protocol working in a matter of a week or two
the only minor hassle is that checking signatures on events requires converting them into a special format of json array, to get the id hash, but for lazy checking you can just enforce a uniqueness invariant on the ID (bake it into the key value store) and just check the signature matches the ID and pubkey, a single time on receiving an event you might have to actually construct the canonical form and validate the hash matches the ID, technically that's it - match the hash, hash to the signature, validated, it's a shortcut but it's secure
i would love to do this task btw, i would make actual distinctive sentinels for the two types of count and auth envelopes, so they don't have to be scanned ahead as they do in json
Thread collapsed
At first I thought gRPC/protobuf is not a transport protocol. Then I see that WebSockets has data framing and messaging. Is gRPC/protobuf light weight, though? What about Cap'n Proto? Or what about plain old UDP? I already see the bulk of relays have <50% connection success, so we're not expecting reliable transport are we? I guess UDP would mean reinventing some stuff. Again, I am speculating as an aloof user.
grpc is lightweight, pretty fast, more universally supported than capn proto for other languages including javascript! and and gRPC's default transport is QUIC which is a UDP based replacement for TCP which aims at fixing "head of line" contention
if there is any candidate for an augmentation to nostr protocol it's gotta be grpc/protobuf
protobuf is the encoding, grpc is the protocol, it handles the request/response flow
If the use for a second protocol is non-browser non-JavaScript non-JSON then there is no need to support JavaScript. If the goal is to fully replace WebSockets/JSON, then yes, it would need to be something with wide support such as gRPC.
Thread collapsed
Thread collapsed
Thread collapsed