Will

I believe this is partially implemented as `car ls --unixfs baga6ea4seaqab7qam2an2mkzssn7vioorrcxhaxxszz6k4t6mscwnhvfjj4hoaq.car`

* what is the problem we're solving here? * One of the pain points i've heard against car / unixfs preparation is that having to do something more than streaming...

Maybe worth comparing this to a variant where the data is uploaded / downloaded fully as raw bytes (maybe as file-delineated objects in a car?) and the ipld references can...

is this wrong? a file, especially if it's a big file, will often be made up of many chunks of multiple cids

you can also look at the verbose flag to print out the types of the different CIDs, and I believe that will print out the items in a unixfs directory...

@SethDocherty - is what you want a machine parse-able listing of all of the unixfs 'named' items in a car? do you want the raw block cids within the unixfs...

@SethDocherty see if https://github.com/ipld/go-car/pull/514 does what you need

In trying to understand the proposal here I'm struggling a bit to understand the consumer that we're building this for. I think the interface you propose above is the direct...

you end with > Just so you know I'll make thoses changes to github.com/ipfs/boxo/car and provide a lighter API does this mean this decision of work has already been made...

## 1 * Apologies - I didn't mean to discount linux2ipfs * I am not opposed to adding a block-based writer to go-car. * I'd probably advocate to add it...