IRC channel logs

<Zarutian_iPad>been mulling on using CBOR as the serialization format for ocapn

<Zarutian_iPad>and it looks like we only need two cbor tags, one for ocapn Selectors and ocapn records

<Zarutian_iPad>the former envelopes utf-8 strings (or even cbor tagged standins for such) and the latter envelopes an array with the record items in that records typedef order

<Zarutian_iPad>i am thinking 77 (dec) for the selectors and 76 (dec) for the records as the cbor tag nrs

<Zarutian_iPad>sorry!

<Zarutian_iPad>s/dec/hex/

<Zarutian_iPad>so 0x77 and 0x76

<Zarutian_iPad>why those? cause they arent taken and fit in a byte so only cbor tag indicator byte plus this one id needed, so two bytes

<Zarutian_iPad>unrelated but needed: in uTP we should use "ocapn" as the start string in place of "bittorrent" (both without the quotes)

<Zarutian_iPad>for uTP netlayer

<Zarutian_iPad>back to cbor

<Zarutian_iPad>I like it as various cbor tagged data structures make easier to deal with say typed arrays like in js and such

<Zarutian_iPad>I like cbor also as one can use jump table based recursive decent parsing 'line-eater' style

<Zarutian_iPad>but it is also easy to parse in memory using something akin to Forth bytestrings (which is starting address and length) to keep the bytes uncopied

<Zarutian_iPad>basically bytevectors in Scheme iirc

<Zarutian_iPad>for cbor tag nr 0x77, ocapn selectors, we should also allow as the data item to be cbor 0x19 (dec 25) string ref to allow for semi-ccompression or frequently used string like desc:* or op:*

IRC channel logs

2025-01-29.log