RFC 0001: Text Peer Ids as CIDs

[lidel]

Important Note: this is the first RFC ever, following "option 2" from #198 and creating a template for future RFCs as a side-effect. The goal is to kick-off the RFC process. I am not a native speaker, feel free to tweak sentences that sound weird.

The RFC 0001 aims to modify Peer ID spec to alter the default string representation from Multihash to CIDv1 in Base32 and to support encoding/decoding text peerids as CIDs.

Changes

• Added RFC/0000-RFC-TEMPLATE.md the TEMPLATE every future RFC should follow
  • Removed the template as suggested by @jacobheun – we will add it in separate PR after this PR is finalized
• Added RFC/0001-text-peerid-cid.md the first RFC to test the process
• Modified peer-ids/peer-ids.md to reflect changes from the RFC

Feedback needed

• the process: does the template include everything we expect from this and future RFCs?
• the RFC: is the proposed change clear enough? anything missing?

cc ipfs/kubo#5287, multiformats/multicodec#130, libp2p/go-libp2p-core#41, https://github.com/ipfs/ipfs/issues/337

[lidel]

FYSA "inspect" link requires multiformats/cid-utils-website#14 to work correctly

[jacobheun]

A couple nits on the template but otherwise this RFC and the template looks good to me.

Before we merge the RFC we should pull the template out of this PR and merge that separately to avoid muddying the commit of the change.

[lidel]

I rebased this PR to remove template and make RFC-0001 easier to audit.
Will add it in a separate PR after this one is finalized and merged.

[yusefnapora]

This looks great to me 👍 Thanks for making the first RFC!

[lidel]

@raulk thoughts? :)

[raulk]

I think we need to mandate backwards compatibility with base58 encoded peer IDs string representations.

Implementations parsing IDs from text MUST support both base58 CIDv0 and CIDv1, and they MUST generate base32-encoded CIDv1, and optionally CIDv0 behind a flag.

We may want to provide a web tool to perform conversions, if we don't already.

In the future we can deprecate CIDv0, but if we don't do it this way, we may end up breaking the UX/DX of cross-language demos. May be worth the breakage, but I want us to be explicit about this.

[lidel]

@raulk CIDv0 is the same as current text representation (Peer ID being multihash in base58btc), making this a relatively safe change.

Existing CID libraries provide conversion methods and support old representation out of the box, but I've added explicit requirement to the spec in b621ac5.

Let me know if there is anything else blocking this.

[raulk]

Thanks for bearing with me while I got to this, @lidel ;-) LGTM now.

I appreciate your adherence to the unofficial RFC process -- good to do some test runs. Once we land a specific format for RFC docs, we'll retrofit this one if needed.

[Stebalien]

@raulk can we 🚢 this?

[raulk]

@Stebalien so we've locked in consensus for making the change. I'm not sure how to deal with change management across implementations, though. We haven't worked out the procedural details of how to coordinate the implementation of an RFC across libraries, and how to signal varying support in a matrix-like format :-(

In a nutshell, I want to avoid getting in a situation where go-libp2p spits out string representations of multiaddrs with CIDv1 peer IDs by default to stdout, and when users copy-paste those multiaddrs to an application powered by py-libp2p, it blows up.

I could be paranoid, though.

[Stebalien]

@raulk the first step is https://github.com/libp2p/go-libp2p-core/pull/41/files. That will add support for parsing cid-peer-ids but it won't spit them out by default.

I've created a tracking issue: #216.