Will

I think somewhere else we tracked progress by knowing the total length of the reader and tracking how much had been read so far. Can you do it that way?

would there be a way to avoid this extra layer of bufio copies for cases where the backing ReaderAt passed to the car library is already a memory buffer?

As long as we have a recommendation between the two in comments on the two function, i think it's fine to move forward here

There's a first pass at documentation at https://ipld.io/specs/transport/car/carv2/#index-format In practice, we've ended up basically only using the 'MultihashIndexSorted' variant because we do want to be able to use the index...

noting that `Advance` on a Traverser will get hard if there's an ADL involved

We do have a case for selectors over ADLs still, which is "give me the blocks that make up this hamt" or more importantly "give me the blocks that make...

yep, happy to dupe, maybe this is more trying to indicate that this remains one of our expected performance bottle necks that we shouldn't lose track of

can we not attempt to see if there is a `.Representation()` method on the passed in node and encode that in the codec unless explicitly told otherwise?

i think this will remain a caltrop. i feel like the default thing when i encode a node is that i want the representation encoded as i expect. the debug...

We hit this again in the indexer wire format. The times one is supposed to call `.Representation` continue to be non-obvious and lead to hard-to-understand errors