This is really cool. I see exactly what you're saying now.
This (as I think you said earlier) could just be a simple optional NIP that relays could signal support for and they'd handle the data however they want on their side right?
https://github.com/mleku/realy/blob/dev/event/binarymarshal.go
this is my binary encoder and this is the benchmarks for it:
https://github.com/mleku/nostrbench
goos: linux
goarch: amd64
pkg: github.com/mleku/nostrbench
cpu: AMD Ryzen 5 PRO 4650G with Radeon Graphics
BenchmarkEncodingEasyJSON-12 687991 1790 ns/op 1631 B/op 6 allocs/op
BenchmarkDecodingEasyJSON-12 676521 1777 ns/op 1413 B/op 16 allocs/op
BenchmarkEncodingGob-12 184216 5982 ns/op 4872 B/op 43 allocs/op
BenchmarkDecodingGob-12 55344 21500 ns/op 10061 B/op 236 allocs/op
BenchmarkEncodingFiatjafBinary-12 99108 11383 ns/op 73789 B/op 1 allocs/op
BenchmarkDecodingFiatjafBinary-12 1370816 863.9 ns/op 769 B/op 10 allocs/op
BenchmarkMlekuMarshalJSON-12 1000000 1149 ns/op 0 B/op 0 allocs/op
BenchmarkMlekuUnmarshalJSON-12 609270 1951 ns/op 684 B/op 13 allocs/op
BenchmarkMlekuMarshalBinary-12 2982892 402.2 ns/op 600 B/op 2 allocs/op
BenchmarkMlekuUnmarshalBinary-12 1571326 767.5 ns/op 1096 B/op 14 allocs/op
as you can see, it is as fast as it can be and you can see reading the encoder that it's 250 lines of code to implement it
you can also see that my custom made JSON codec is only about 3x slower and faster than the easyjson that has a massive 1000 lines of generated source code to enable it
when you understand those numbers there you can see why i am skeptical there is really any need for it, it's the least expensive operation
but what i will point out is that between the json and my binary encoding, part of the reason why it is so fast is because my runtime encoding also uses binary instead of hex, there is only a hex en/decode step to go to the wire
Discussion
We can have a version field also.
Version 1: just normal Nostr events, signed as usual
Version 2: fields can now contain non-UTF8 content, new signing scheme
yeah, i think add a field to nip-11 info that gives a codec name
the other thing to be attended to is the websocket negotiation, possibly a new field in the header would be useful such as a mimetype, if it's upgrade and json, then json, if it's upgrade and cbor, it's cbor, etc
i think better we don't tamper with the API though - retain the envelopes, just in a different encoding
i also have been saying for some time it would be useful to add a negation operator to filters so a client can request to not see events from authors or events it already has... a lot of what negentropy does is working around this problem also
and maybe a new variant of req that only returns event ids instead of whole events
anyway, now i'm going off on tangents
er, i mean list of codecs