+# CAR v2++Authors: @willscott++## What is the problem this project solves?+_Describe the status quo, including any relevant context on the problem you're seeing that this project should solve. Who is the user you're solving for, and why do they care about this problem? Wherever possible, include pain points or problems that you've seen users experience to help motivate why solving this problem works towards top-line objectives._ ++This project implements a second version of the Content addressed data ARchive format.+The goal is to provide a standardized way to take a collection of content addressed data, as currently exists in the car format, and be able to efficiently provide random access reads and appends to it.+We know through the carbs and carbon experiments that both of these are possible.++With this functionality we can avoid the need to take an existing car file and import it back into a blockstore like badger before being able to perform random access reads over it.++## Impact+_What goals/OKRs are being addressed (for w3dt, a specific program, etc.)? Why is this project important? What do we get with this project that we can't get without it?_++This project aims to impact the goals of:+- low latency retrieval from filecoin++These are core goals that the Bedrock program aims to address. ++## The idea+_Describe the proposed project solution, at a very high level. Stay at the level of the high-level requirements. Diagrams and interface descriptions can be useful, if you have any that help clarify and explain the idea._++As described in the [sharded dag store](https://docs.google.com/document/d/118fJdf8HGK8tHYOCQfMVURW9gTF738D0weX-hbG-BvY/edit?ts=60bf961f) design document we want a minimal format for carv2 consisting of

+# CAR v2++Authors: @willscott++## What is the problem this project solves?+_Describe the status quo, including any relevant context on the problem you're seeing that this project should solve. Who is the user you're solving for, and why do they care about this problem? Wherever possible, include pain points or problems that you've seen users experience to help motivate why solving this problem works towards top-line objectives._ ++This project implements a second version of the Content addressed data ARchive format.+The goal is to provide a standardized way to take a collection of content addressed data, as currently exists in the car format, and be able to efficiently provide random access reads and appends to it.+We know through the carbs and carbon experiments that both of these are possible.++With this functionality we can avoid the need to take an existing car file and import it back into a blockstore like badger before being able to perform random access reads over it.++## Impact+_What goals/OKRs are being addressed (for w3dt, a specific program, etc.)? Why is this project important? What do we get with this project that we can't get without it?_++This project aims to impact the goals of:+- low latency retrieval from filecoin++These are core goals that the Bedrock program aims to address. ++## The idea+_Describe the proposed project solution, at a very high level. Stay at the level of the high-level requirements. Diagrams and interface descriptions can be useful, if you have any that help clarify and explain the idea._++As described in the [sharded dag store](https://docs.google.com/document/d/118fJdf8HGK8tHYOCQfMVURW9gTF738D0weX-hbG-BvY/edit?ts=60bf961f) design document we want a minimal format for carv2 consisting of+- a magic byte sequence to cause previous car1 libraries to properly warn they aren't using a compatible version+- a fixed length header indicating features and offsets+- the exact bytes currently in a carv1+- an index compatible with carbs++A more complete spec is described [here](https://github.com/ipld/specs/pull/248#issuecomment-833141588)++## Success/acceptance criteria (optional)+_How do we know we're done with this project? How do we know we're successful? This field is OPTIONAL for the first draft of an MPP. Sometimes this field needs to be filled out once we have more detail on the shape of the actual solution._++Initial success/acceptance criteria:+- Can read and write carv2 bytes on disk as described+- provides an efficient read/write blockstore interface+- Can export the index of a carv2 to bytes for separate storage+- Can extract the carv1 bytes from a carv2+- Can combine a carv1 and a spearate index to get carv2 equivalent behavior (and to write to a carv2 if desired)+++## Detailed plans (optional)+_Link to more detailed project plans, e.g. product requirements documents (PRDs) and technical design docs, once they have been created for this project._++Ongoing work is in the [wip/v2](https://github.com/ipld/go-car/tree/wip/v2) branch of go-car.

+# CAR v2++Authors: @willscott++## What is the problem this project solves?+_Describe the status quo, including any relevant context on the problem you're seeing that this project should solve. Who is the user you're solving for, and why do they care about this problem? Wherever possible, include pain points or problems that you've seen users experience to help motivate why solving this problem works towards top-line objectives._ ++This project implements a second version of the Content addressed data ARchive format.+The goal is to provide a standardized way to take a collection of content addressed data, as currently exists in the car format, and be able to efficiently provide random access reads and appends to it.+We know through the carbs and carbon experiments that both of these are possible.++With this functionality we can avoid the need to take an existing car file and import it back into a blockstore like badger before being able to perform random access reads over it.++## Impact+_What goals/OKRs are being addressed (for w3dt, a specific program, etc.)? Why is this project important? What do we get with this project that we can't get without it?_++This project aims to impact the goals of:+- low latency retrieval from filecoin++These are core goals that the Bedrock program aims to address. ++## The idea+_Describe the proposed project solution, at a very high level. Stay at the level of the high-level requirements. Diagrams and interface descriptions can be useful, if you have any that help clarify and explain the idea._++As described in the [sharded dag store](https://docs.google.com/document/d/118fJdf8HGK8tHYOCQfMVURW9gTF738D0weX-hbG-BvY/edit?ts=60bf961f) design document we want a minimal format for carv2 consisting of+- a magic byte sequence to cause previous car1 libraries to properly warn they aren't using a compatible version+- a fixed length header indicating features and offsets+- the exact bytes currently in a carv1+- an index compatible with carbs++A more complete spec is described [here](https://github.com/ipld/specs/pull/248#issuecomment-833141588)