Skip to content
This repository has been archived by the owner on Sep 6, 2022. It is now read-only.

feat: support encoding/decoding peer IDs as CIDs in text #41

Merged
merged 3 commits into from
Dec 10, 2019

Conversation

Stebalien
Copy link
Member

@Stebalien Stebalien commented Jul 15, 2019

What:

  1. Supports decoding CIDs (of libp2p keys) as peer IDs.
  2. Continues to encode peer IDs as base58 multihashes by default.
  3. Adds functions for converting between peer IDs and CIDs.
  4. Deprecates IDB58{Decode,Encode}, replacing them with {Decode,Encode}.

Why:

  1. We need to support multibase somehow so we can put peer IDs in domains.
  2. This makes peer IDs fully self describing. That is, the CID itself indicates that it's a hash of a libp2p public key.
  3. It's much easier to upgrade wire protocols than text. This change punts
    pids-as-cids on the wire down the road but that's something we can revisit if it ever becomes relevant.

See libp2p/specs#111 for context.

Deviations from that issue:

  • This retains the current peer ID inlining of ed25519 keys. That turned out to be a nightmare, one I'd like to punt a bit more down the road.
  • Likewise, this punts the question of embedding the multi-hash algorithm in the public key.

Alternative: Hack this into go-ipfs and make it only valid in /ipns links. Honestly, we can do that first and then merge this later.

@hsanjuan
Copy link

Continues to encode peer IDs as base58 multihashes by default.

Why don't we change this default now already?

@jacobheun
Copy link

This change makes sense to me. If we change the default now we wouldn't give the network any time to upgrade. This would cause the node to announce its peer id as a cid hash wouldn't it?

One question, right now we're using the libp2p-key multicodec. Would we get any benefit for being more granular with this to know what type of libp2p key it is?

@Stebalien
Copy link
Member Author

@hsanjuan

Why don't we change this default now already?

Compatibility.


@jacobheun

This would cause the node to announce its peer id as a cid hash wouldn't it?

We're not changing the wire format, just the format in text.

Would we get any benefit for being more granular with this to know what type of libp2p key it is?

The key already specifies that internally. libp2p-key just means that we're pointing to a protobuf with the structure {type: int, data: [bytes]}.

@jacobheun
Copy link

Great, thanks for clarifying. 👍

@hsanjuan
Copy link

hsanjuan commented Jul 23, 2019

Compatibility.

OK, but is there an upgrade timeline? It says in the future which is not super helpful... also there does not seem to be a way to enforce CID-encoding (other than going manual with ToCid().String() so it is hard to test if anything breaks.

If we are supposed to move from IDB58Encode to Encode all over our code, and libp2p will one day flip the switch for us, then it may just flip the switch now in the Encode function. Why not making the move from IDB58Encode to Encode should be actual opt-in to work with CIDs?

@Stebalien
Copy link
Member Author

This is a two step upgrade:

  1. Add support for decoding CIDs as peer IDs everywhere.
  2. Flip the switch and start encoding them that way. When we do that, I'd like to make IDB58Encode also encode peer IDs as CIDs. The only reason I'm deprecating it in favor of Encode is that the function name IDB58Encode will be incorrect.

If we start encoding as CIDs now, peers using the old version won't be able to understand peer IDs encoded by the new version. This won't break the network but it will confuse users.

OK, but is there an upgrade timeline?

Sure. How about 3 months after the last libp2p implementation upgrades and releases?

@lidel
Copy link
Member

lidel commented Aug 19, 2019

PSA: proposed change to libp2p specs to default text representation to CID in Base32:

@Stebalien Stebalien force-pushed the feat/parse-cid-as-pid branch from 4cc27af to 0bdeee6 Compare October 2, 2019 15:45
@@ -155,10 +158,66 @@ func IDHexDecode(s string) (ID, error) {
}

// IDHexEncode returns the hex-encoded multihash representation of the ID.
//
// Deprecated: Don't raw-hex encode peer IDs, use base16 CIDs.
func IDHexEncode(id ID) string {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should really remove these. But that's a breaking change and we can do that later.

Copy link
Member

@raulk raulk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Just two nits about usage of acronyms which I'd like addressed. Since these two methods are in the public API, let's try to be as idiomatic as possible.

// ToCid encodes a peer ID as a CID of the public key.
//
// If the peer ID is invalid (e.g., empty), this will return the empty CID.
func ToCid(id ID) cid.Cid {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: go style is to capitalise acronyms. We should create an alias cid.CID => cid.Cid.

Suggested change
func ToCid(id ID) cid.Cid {
func ToCID(id ID) cid.Cid {

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@raulk I don't think we should introduce new convention here.
All our codebases already use things like NewCidV1 and FromCid.

If we choose to change them to use capitalization, that needs to happen across all repos (in separate, coordinated PRs), otherwise we just introduce noise by mixing conventions.

}

// FromCid converts a CID to a peer ID, if possible.
func FromCid(c cid.Cid) (ID, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
func FromCid(c cid.Cid) (ID, error) {
func FromCID(c cid.Cid) (ID, error) {

@Stebalien
Copy link
Member Author

I'm fine with those changes but they are inconsistent with the rest of go-ipfs/go-libp2p which we're not going to change as following a style guideline isn't worth the confusion of having two ways to do the same thing.

@lidel
Copy link
Member

lidel commented Dec 9, 2019

@raulk Would it be ok to rebase it on master and merge as-is? 🙏
I believe we want to keep PRs related to CID changes small and on topic.
See my note in #41 (comment)

@raulk
Copy link
Member

raulk commented Dec 9, 2019

Go ahead!

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
@lidel
Copy link
Member

lidel commented Dec 10, 2019

@raulk @Stebalien I am missing permission to push to this branch – mind adding me, or rebasing and applying below fix yourself?

ERROR: Permission to libp2p/go-libp2p-core.git denied to lidel.
fatal: Could not read from remote repository.

The only conflict with master is go version in .travis.yml, the fix is:

-   - 1.12.x
+   - 1.13.x

@Stebalien
Copy link
Member Author

Stebalien commented Dec 10, 2019 via email

@lidel lidel changed the title feat: support encoding/decoding peer IDs as CIDs _in text_ feat: support encoding/decoding peer IDs as CIDs in text Dec 10, 2019
@lidel lidel merged commit ba9101b into master Dec 10, 2019
@lidel lidel deleted the feat/parse-cid-as-pid branch December 10, 2019 16:51
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants