Conversation
|
|
||
| ## Design | ||
|
|
||
| The Sharded DAG Index will gain a `blocks` property - a list of blocks "inlined" in the index. See [#66](https://github.com/storacha/RFC/pull/66). |
There was a problem hiding this comment.
question: Do we actually need a blocks property at all? We'll already have a root CID that we're looking up, and we'll get the index back from the indexer. That's already a CAR. Can we just include that block in the CAR, and not link to it from the index block?
There was a problem hiding this comment.
You could, but that block might not round trip serialization/deserialization since there's nothing linking to it.
There was a problem hiding this comment.
Ah, right: indexes are rooted at a block that's given as a root in their CAR. The CAR is the transport, it's not the index itself. I'm thinking of shards, which don't have roots and where the CAR itself is the shard.
Yeah, they should be linked into the DAG and reachable from the root. But maybe we should call them nodes:? That's the more UnixFS-specific terminology. We don't expect arbitrary blocks here, right? And if we needed them, we might link to them under a different key?
|
@frrist is this ok by you? |
frrist
left a comment
frrist
left a comment
There was a problem hiding this comment.
lgtm.
I have some concerns wrt passthrough from the upload service/s3 facade to the storage nodes, but that's probably more of an implementation detail.
3 participants
📖 Preview