Graph Agnostic

[Stebalien]

So, it would be kind of nice if we could treat links as truly transparent. Basically, in London, we discussed the fact that paths don't care about link boundaries so, really, our datastructures shouldn't either.

Now, the primary downsides are:

1. We need to replace CIDs with paths. That is, we need to support path-links in addition to CID links.
2. Not all files would have CIDs.

However, giving every file and it's own CID is already a bit of a performance nightmare and we cant feasibly announce every CID to the network so we already need to start talking about files with paths instead of just CIDs.

[magik6k]

Why not use inline CIDs for this?

[mikeal]

Can you give an example of a change to the current draft specs that this would change?

[Stebalien]

Why not use inline CIDs for this?

We may want to inline "large" things. Technically, we can put these in CIDs but, really, we should never expose massive CIDs to users.

Can you give an example of a change to the current draft specs that this would change?

This one: #13. That is, it wouldn't require that the second entry be a link.

[mikeal]

This one: #13. That is, it wouldn't require that the second entry be a link.

Just trying to make sure we're on the same page. By "second entry" you mean

[
  [ [0, 1024], Link /* <-- second entry */ ],
  [ [1025, 1002], Link ]
]

Are you proposing that this second entry be a path or simply that the raw binary would be in-lined instead of being a link? I'm struggling to figure out what a path would point to.

[Stebalien]

Just trying to make sure we're on the same page. By "second entry" you mean

Yes.

Are you proposing that this second entry be a path or simply that the raw binary would be in-lined instead of being a link?

Both? But they're two different issues.

1. We can currently only point to CIDs, not paths. This makes it difficult to point into existing objects. It would be nice (although not necessary) to be able to point to blocks within an existing file. On the other hand, this really is a separate issue.
2. Under this proposal, Unixfs would expect either (a) raw binary (b) a sharded blob (using your "file data representation" spec) or (c) a link to either.

[rvagg]

closing for archival