unixfs has a data type = 3 listed as metadata.
Is this data type in use by the any of standard functions of IPFS?
As far as IPFS utilization and implementation is concerned what is the intended use of this data type?
I’ll take the lack of any response as it is not in use and will also assume it means it has no intended specific use in IPFS and is open to adoption for use cases within IPFS by the ecosystem.
If I take the time I’ll search source and report back but since it is just a POC I am focused on right now I may not confirm, yet.
I looked and it might be used in unixfs 1.5 (i think that was what the unixfs update to support mode and mtime was called). https://github.com/ipfs/specs/blob/master/UNIXFS.md#metadata
1 Like
So yesterday I read over the spec really quickly and the metadata section is not about the metadata type.
The Type = 3 Metadata type is unused. Spec is undefined.
Now, I don’t think you should use it. Because the spec is undefined for this there is no guarantee that it won’t break things in some place. IPFS just does not expect unixfs nodes of this type, and probably nothing happens, but I cannot assure 100% that will be the case.
use cases within IPFS by the ecosystem
So what is your actual usecase? Because I am pretty sure there might be a better way to do it than cannibalizing an undefined part of the unixfs spec.
1 Like
That was above and beyond. Thank you. I wonder why I didn’t find or maybe I didn’t think to properly read the spec. Good catch!
And that was indeed the entire point of this query. To not bastardize the type . I knew it didn’t relate to the metadata fields added around directories but stood separate from them but other than that was at a loss. If it was not in use, but defined as open metadata where the data element would be populated by ipld etc. and was intended for expanding the usage then that was great. But being undefined by specification leaves lots of room for future problems from any casual adoption of its use.
My use case was to use metaadata typed blocks in a pub/sub style (not IPFS pu/sub) relationship to indicicate a state on the target block the metadata describes. Such as published to a known directory and collected by a known reader. (Really, it would be a pointer to an on chain transaction that timestamped that transaction)
BTW I propose that is generally how the metadata type should be specified.
Having no current core function but intended for adding metadata blocks that add to the meaning of linked blocks. This could be used by core protocol in the future and used by the larger ecosystem without conflict.
The data element would contain the structured metadata within itself
This falls in the land of UnixFS v1.x which at some point should be replaced by IPLD-native “thing”* (https://github.com/ipld/specs). The practical consequence is that for the time being no more efforts are put in the v1.x approach as it is almost considered legacy.
Since all unixfs protobufs are wrapped inside a merkledag-pb (which is actually the thing that can be referenced by CID and has links to other blocks), I wonder what happens if you add extra links to the merkledag-pb node that wraps the unixfs data type and those links point to your custom dag-cbor nodes with metadata. It might be a better approach.
*What I mean is that you can do what merkledag-pb+unixfs does using ipld-schemas and types etc in a better way.
1 Like
Let me study this last post, look at the source materials and parse all this. I think there is a lot more packed into the preceding response than might first appear. Good stuff. Thanks, Hector.