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

Reply to this note

Please Login to reply.

Discussion

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

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.