-
Notifications
You must be signed in to change notification settings - Fork 412
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
feat: multiaddresses #1364
feat: multiaddresses #1364
Conversation
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @DannyS03 added a few comments
|
||
# Understanding Multi-Addresses in IPFS | ||
|
||
A [multiaddr](https://github.com/multiformats/multiaddr) encodes multiple layers of addressing information into a single "future-proof" path structure. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion (with a question):
Since this is the first time "multiaddr" is used on the page, would it make sense to use the term "Multi-address" since that's used in the tile of the doc? Most readers will probably infer that multiaddr is short for multi-address, but I don't think we should assume. So it would read
A [multi-address](https://github.com/multiformats/multiaddr) (multiaddr) encodes multiple layers...
Also, is it "multiaddress" or "multi-address"? I'm unsure from https://github.com/multiformats/multiaddr
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, what do we mean by "future-proof"? In other words, why is a multiaddr future-proof? Would be good to include the context if we are going to keep that description in the doc
(Trying to out myself in the shoes of the reader here. We / the engineers might implicitly know what "future-proof" means, but the reader probably won't)
A [multiaddr](https://github.com/multiformats/multiaddr) encodes multiple layers of addressing information into a single "future-proof" path structure. | ||
|
||
It is a self-describing format that allows multiple protocols encoded in a single string. This allows for flexibility in addressing and routing network traffic in a decentralized system like IPFS. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: could consolidate these two points and remove the phrase "future-proof". Also, I think there is a grammar error here:
A multi-address (multiaddr) is a self-describing format that allows multiple protocols to be encoded into a single string. This allows for flexibility in addressing and routing network traffic in a decentralized system like IPFS.
|
||
Where `<protocol>` is the name of the network protocol being used, and `<address>` is the address of the node on that network. | ||
|
||
For example, a multiaddr for an IPFS node with the IP address `192.0.2.1` and listening on port `5001` would be: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You describe the mutliaddr example twice, so I'd suggest deleting the note (>
) and consolidating
For example, this multiaddr indicates that the node uses the IPv4 protocol, has the IP address 192.0.2.1, and listens on TCP port 5001.
> Each file or piece of content is identified by a unique [content identifier (CID)](content-addressing.md) that is generated based on the content itself. The CID is a base58-encoded string that users can use to retrieve content. | ||
> In addition to the CID, IPFS uses a multi-hash concept to ensure the content's integrity and authenticity. A multi-hash is a hash of the content generated using multiple hashing algorithms. This allows IPFS to support a variety of hashing algorithms and also provides a level of redundancy to ensure the accuracy of the hash. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few notes here:
- The markdown shows two
>
's, one on line 31 and one on 32. Did you mean for this two be two separate notes one after another? On the staging site, this renders like it's one large note (see screenshot) - would suggest
:::callout
instead of>
if you're going to use notes here. It renders more visibly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- that being said, I'm not sure that you need notes here. I get what you're trying to do here, which is give context for those terms (which I totally agree with) but I think that you could minimize duplication of content / condense the copy here by doing away with the notes and instead linking to the glossary instead so that folks can find the definition of what a CID and multi-hash are if they don't already know. So, you'd delete 31 and 32, and be left with line 30 as
The [CID](../../concepts/glossary.md#cid) and [multihash](../../concepts/glossary.md#multihash) can be included in a multiaddr to specify the location of a specific piece of content on the network.
Context
Latest preview
Please view the latest Fleek preview here.