Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP: Need to make this an option] Need to use the dagbp builder for a unixfs node #304

Closed
wants to merge 1 commit into from

Conversation

aarshkshah1992
Copy link
Contributor

@aarshkshah1992 aarshkshah1992 commented May 27, 2022

The unixfsnode.AddUnixFSReificationToLinkSystem(ls) dosen't work without this. A non dag pb node is rejected as a plain node by the UnixFS reirfier.

@willscott
Copy link
Member

note that there's context in ipfs/go-unixfsnode#27

@aschmahmann this is an example of why the IPLD side thinks that's important - when loading a node through the linksystem it will not always come through as dagPB, even when it is.

@aschmahmann
Copy link
Contributor

aschmahmann commented May 30, 2022

this is an example of why the IPLD side thinks that's important - when loading a node through the linksystem it will not always come through as dagPB, even when it is.

Yeah.... I don't think the way we currently enforce strictness (i.e. insist that UnixFS data follows the spec) is great. Using type checks is just bad (e.g. what if someone made a new dagpb implementation and chose to use that with the existing ADL?). This case is still meant to follow the spec though (e.g. it's being used to transport some UnixFS data via a CAR file and it should actually be UnixFS data).

Perhaps there is more precise tooling we can use for this kind of thing though so we don't need to use concrete type checks. I could also see how for this kind of thing allowing for "loose decoding" where the producer of the CAR says "I know what I'm doing" while the consumer of the blocks from the CAR uses strict decoding to ensure the data they're getting is actually UnixFS.

Interesting use case to consider though, thanks for the pointer.

@willscott
Copy link
Member

i think the less controversial immediate solution to this is in #305

@willscott
Copy link
Member

@aarshkshah1992 objection to close this and use the pattern from #305 ?

@BigLep
Copy link
Contributor

BigLep commented Jun 7, 2022

Closing given #305

@BigLep BigLep closed this Jun 7, 2022
@rvagg rvagg deleted the feat/unixfs-hack branch June 27, 2022 11:19
rvagg added a commit to ipfs/specs that referenced this pull request Jun 27, 2022
The strict coupling poses some problems for IPLD implementations that:

 1. do not retain codec information between the serialization and UnixFS (ADL)
    reification; and/or
 2. do not have a mechanism to strictly mandate that UnixFS data be _only_
    encoded in a particular codec.

A mandate in the specification that strictly defines the layering on top of
the codec makes it difficult to implement it as an ADL, which also presents
difficulty for using tooling that builds on IPLD lens-style layering.

Ref: ipfs/go-unixfsnode#27
Ref: #271
Ref: ipld/go-car#304
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants