Switch to System.Format.CBor

[drasticactions]

Peter.Cbor is an excellent library, but System.Format.Cbor is built into the runtime and would require one less dependency to run FishyFlip. The API is vastly different from Peter.Cbor, but it would probably be worth changing the code over to use the runtime version.

[TimBurga]

Curious if anyone has taken a stab at this yet. I tried putting together a POC and I cannot parse anything beyond t and op. I don't know if I'm using it wrong or if it doesn't handle the structure correctly or what.

Update: solved! When initializing a new CborReader pass true for allowMultipleRootLevelValues.

[TimBurga]

It looks like there's a significant delta between Peter's solution and what the native library offers.

The library only handles the most basic fundamentals like iterating a byte stream and reading out the value at that position. It doesn't provide any of the next-level features like parsing key/value pairs or maps or arrays.

Making this switch would involve reinventing all that logic. While I'm always in favor of reducing dependencies, I don't think dotnet is there yet.

[drasticactions]

FWIW I'm not against doing a simple implementation of that logic specifically for this. The CAR files are well defined, so needing to slice bytes and reading values out is not too hard. And it's not all or nothing: Replacing it would be an iterative process, so starting with one class and slowing going over until it's all gone.

But in general, yeah, right now we're in a good position with what we have. Peter.CBOR does throw a trimming error but I think it's in logging code if I recall correctly, for our needs it works great with NativeAOT. And while there have been some thrown issues with decoding CAR files from the library, it's more likely I'm screwing something up or not setting something than the library itself. It seems perfectly stable for this need.