11:14:44 <selsta> .merge+ 10648 10649
11:14:44 <xmr-pr> Added
19:47:52 <br-m> <jpk68:matrix.org> vtnerd: CDDL seems like a really cool idea
20:51:44 <vtnerd> yes, its easier to read than json-schema. the only real drawbacks of cbor are listed too, but I may come around to accepting htem
20:57:19 <br-m> <jpk68:matrix.org> I also feel like documentation for CBOR RPC will be substantially easier, considering its standarization and industry adoption
20:57:54 <br-m> <jpk68:matrix.org> Pretty sure Intel has their own CBOR library on GH, which might have SIMD support, I can't remember
20:58:49 <vtnerd> I don't see SIMD support would be helpful, there's no whitespace and you can't read multiple integers at a time due to the tag design
20:59:33 <vtnerd> cbor-rpc will not be substantially easier, except for maybe grokking cddl vs json-schema (which is what I'd use with msgpack)
20:59:56 <vtnerd> like in either case you've gotta transform bytes into data structures via some lib or custom code
21:00:15 <vtnerd> and both are well-defined. cbor is just more annoying with float16 and indefinite length items
21:00:32 <vtnerd> otherwise its practically the same thing
22:08:08 <selsta> gingeropolous: you might have an opinion regarding this, as it was your idea initially https://github.com/monero-project/monero/issues/10690
23:52:04 <vtnerd> ok, I just put together a cbor encoder in less than 3 hours, and its seriously bad-ass from the encoding side
23:52:33 <vtnerd> all signed/unsigned output can merge into one function easily, unlike msgpack
23:53:20 <vtnerd> the cache locality has to be better, but I'd have to do a valgrind run to verify (as my ryzen chip just crushes it)
23:53:49 <br-m> <syntheticbird> CBOR SUPPORT INCOMING IN MONEROD 2026 CONFIRMED
23:54:45 <vtnerd> the size between msgpack is really similar, and so is the timing (but integer keys are actually really close to viable)
23:56:26 <vtnerd> lol are you excited too?
23:56:36 <br-m> <syntheticbird> of course i am
23:57:41 <br-m> <jpk68:matrix.org> CBOR FTW