Comments (9)
Unless I am missing something obvious (always possible) getting the prefix of a Cid() is the only way to get the Version of the cid, although we could add a Version() method fairly easily.
Other than that I am not sure and would need to check everywhere Prefix is used.
from go-cid.
I think the real problem is we are using Prefix for two different things which I think should be separated.
(1) To get information about an existing CD
(2) To create a new CID
I think we should separate these two concerns. This is espacally relevant now as I am trying to think how to add support for automatically creating Identity hashes. I am tempted to hack on support with the existing Prefix structure but will only make things worse.
Instead I propose we use two different structures one to get information about a Cid and another to be used to actually generate a Cid, the first will have a Bytes() method but no Sum() method, and a unsigned MhLength; the latter will not have a Bytes() method, but will have a Sum() method, and a signed MhLength. The latter will also be extended to support creating identity hashes.
The only thing is what to call to two structures, should we use CidInfo
and Prefix
(where the first is for getting info on a Cid and the later for creating them); or maybe Prefix
an CidOpts
; or maybe rename both to CidInfo
and CidOpts
; or maybe something else as I am horrible and thinking of good names for things.
Thoughts?
from go-cid.
I agree, Prefix is trying to do too many things. However, is Prefix
really useful except as a way to create new CIDs? As far as I know, that's the only way we really use it. We may be able to just deprecate Prefix and then create a new Format
type (or something like that).
from go-cid.
For me, the most confusing part is that I don't find the Prefix
in the CID specification so I don't know what to expect of this structure. From the code it seems that Prefix
has pretty much the same information as Cid
minus the digest. It seems to be used for this double function as @kevina mentioned,
(1) To get information about an existing CD
(2) To create a new CID
to the point where the ProtoNode
structure has both a Prefix
and a Cid
(where some information is taken from the first structure and other from the second).
So I think the priority is to first decide at the specification level what role does the prefix play so the user has a clear mental model of it, and later discuss how the code should implement it (if at all) to avoid potential sources of confusion like
cid1.Bytes() == cid2.Bytes()
does not implycid1.Prefix() == cid2.Prefix()
.
The -1
in the Mhlength
is just an example of this, where the Prefix
duplicates the MhLength
of the Cid
's Multihash
but declares it as a signed integer and employs a -1
signal that is not part of the multihash specification (which I personally had much trouble spotting the difference while working in ipfs/kubo#5019).
With this I don't want to undermine the Go implementation but (from what I'm understanding from the IPFS model) the specification should always precede the implementation (to avoid having go-cid
being the reference implementation and being just one implementation).
from go-cid.
FWIW, the JS implementation of the prefix
is worth looking at, where it is just a derivation (as a function, not a separate structure) of the CID.
from go-cid.
So I think the priority is to first decide at the specification level what role does the prefix play so the user has a clear mental model of it, and later discuss how the code should implement it (if at all) to avoid potential sources of confusion like
I strongly disagree with this. The specification is about the format, not the API. Prefix is an implementation detail.
from go-cid.
If part of the confusion is that the Prefix
structure has a Bytes()
method I think we should just remove it as I am not sure how much utility it has.
from go-cid.
And maybe we should just eliminate the use of the word Prefix
for this.
I like using CidInfo
for a struct that is just about the information in a Cid (and doesn't have a Bytes() method) and Format
for a struct used to create new Cid's. This way the user doesn't try to match up the word Prefix
which how it is used in the spec.
from go-cid.
The specification is about the format, not the API. Prefix is an implementation detail.
That's fair, we may have different expectations of what a specification does. In my experience specifications (e.g., RFCs, what IPFS specs aspire to) tell me more, not just the format but the functions that interact with it, the main components involved, how they interact, the terminology they use, etc. They don't draw the blueprints down to the last level because that's were implementation specific details come up but it's certainly not a black box in terms of what to expect from it.
Anyway, thanks for the feedback, this is an interesting discussion (that exceeds this issue) about what to expect from IPFS specifications (I'll try to submit an issue at the specs repo about it).
from go-cid.
Related Issues (20)
- Implement 'K'-encoding (base36 cids) HOT 2
- Inaccurate godoc comment for uvarint HOT 1
- Possible to calculate cid using Writer interface instead of reading full file into memory? HOT 3
- add CidFromReader HOT 9
- cid Undef cannot be marshalled HOT 3
- Support parse (github.com/ipfs/go-path).Path HOT 16
- Provide an efficient API to check whether a CID has `IDENTITY` multihash code HOT 3
- CodecToStr and Codecs in v0.3.1 could cause data corruption HOT 3
- CidFromReader wraps valid io.EOF in ErrInvalidCid HOT 1
- Bloom filter backed version of Cid.Set HOT 1
- Extract non-core functionaly into new package HOT 5
- LRU cache HOT 3
- protobuf vs dag-pb HOT 2
- Should the JSON represenetation of CID always be formatted as links. HOT 6
- Generated CIDv0 differs from the one generated by IPFS HOT 13
- Proposal: Moving CID to multiformats Org HOT 1
- Prefix.Sum creates bad inline CIDs
- Qm hash identifiers duplicated within the IPFS ecosystem HOT 1
- Harden varint encoding. HOT 1
- Support for reading concatenated CIDs
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from go-cid.