Background

“IPFS” is an ambiguous term in part because multiple “things” are called “IPFS”, including the Go and JS reference implementations of the “IPFS bundling” that were sponsored by Protocol Labs being named “go-ipfs” and “js-ipfs”. Protocol Labs wants to make space for additional implementations to be made, including in Go and JS. PL found with the Filecoin protocol that the “one protocol multiple implementations” conversation was helped when implementations didn’t use “filecoin” in the name. This is why the original “go-filecoin” implementation was renamed to “venus” and the mainnet reference implementation was named “lotus”, even though it also is written in Go.

In addition, IPFS nodes have varying levels of compliance among them. For example, the ipfs.io gateways can be considered to have two types of content routing: the IPFS Public DHT, and peering agreements with Pinata, Infura, Textile, etc. This leads to user confusion when a partner’s data loads on the gateways but not via Brave's local go-ipfs node. We believe it’ll be useful for users to be able to say that a provider’s nodes are not X (a TBD name) compliant since they do not advertise their data in the IPFS Public DHT, and Brave nodes currently only support X compliant data providers.

Problems To Solve

1. Identify new names for go-ipfs and js-ipfs.
2. Identify a name for the “public IPFS DHT” so we can say that “$implementation nodes are $X compliant data providers.

Proposed Method

Create 2 separate GitHub discussions in https://github.com/ipfs/ipfs:

1. Renaming go-ipfs
2. Naming the “public DHT”

The discussions will link to this document explaining the purpose and rationale. Anyone who wants to propose an idea, can start a discussion “answer” following a template like:

*Name:* 
*Reason it’s great:* 
*How it reads in multiple sentences:*
*Callouts concerning recognition, pronunciation, spelling, length, and/or SEO:* 

Submissions should be in by EOD Wednesday, 2021-11-03, so can vote Thursday and Friday.

Others can then:

1. comment on the “answer” if they have things to add to it and/or
2. “thumbs up“ 👍 if they’re in favor

Many naming idea can be seeded from Sheet of IPFS-related Names.

We’ll announce after Lab Week in the discussions the decided names and the timeline for making the repo/doc naming updates.

FAQ

What is the scope here? Are we renaming binaries, repos, etc.?

The exact scope/plan of renames (particularly with regard to go-ipfs) is TBD. We need to think through the implications on the community of changing these things. There is non-trivial work to:

1. Rename the ipfs/go-ipfs repo given there are some who consume go-ipfs as a library and likely scripts that hit that path.
2. Rename the ipfs binary as this is strewn throughout docs, scripts, etc.

The beachhead to start is to pick a name for the current "go-ipfs" IPFS implementation. For examples, let's call it "banana". At the top of the of the ipfs/go-ipfs repo, we'd have a note that says something like:

This repo is for the "banana" implementation of IPFS. It was formally called "go-ipfs". You can find other IPFS implementations in Go and other languages here.

Because of non-trivial work, we haven't changed the name of the repo or the binary. The progress of that work can be tracked here.

In addition, until the renaming work above is completed, any CLI reference in the ipfs.io docs for the "ipfs" binary should also map to this "banana" implementation.

We have picked the name "banana" now even without doing the full rename to ensure we don't add more that needs to be renamed in the future. It allows us to start referring to this specific IPFS implementation that was originally sponsored by Protocol Labs with clear communication. For example, the team of maintainers for "banana" can refer to themselves as the "banana maintainers" and name their support channels as such.

"banana" is expected to take a direct dependency on the to-be-written go-lib-ipfs project (see ipfs/kubo#8543). We aren't propagating the "banana" name to go-lib-ipfs because there isn't banana-specific choices in that repo. banana-specific code like banana's configuration system (which currently lives in ipfs/go-ipfs-config) will move into the banana repo directly. Future implementations of IPFS that are written in go (e.g., ipfs/rainbow) can choose to use go-lib-ipfs or not. This is similar to how anyone making an IPFS implementation in go can choose to depend on go-libp2p or not.

What order will the rename happen?

Per above, there are different layers to the rename. The order/timeline is still TBD, but needs to account for:

1. Public chat/discussion channels
2. Docs
3. GitHub repo
4. binary

Why do this on GitHub?

1. It’s visible to the community and easily discoverable
2. GitHub allows a user to thumbs up/ multiple items, but only one “thumbs up” per item.
3. It gives visibility to who voted for certain items (so can make sure are picking an option that has up votes from multiple parties)

Why don’t we use the GitHub “upvote” functionality?

We’re not proposing to use the official “upvote” functionality because it doesn’t give visibility to the voter.

Why now?

Protocol Labs is kicking off Lab Week where it and other partners in the ecoyostem are gathered to discuss “PLv8” and its principles around scaling our networks and doubling down on ecosystem growth & agency. In this context, actually getting decisions made and a plan made for a rename in 2021 seem appropriate.

What about renaming “js-ipfs”?

This will likely happen as well, and we’ll be having conversations on 2021-11-03 about the the different parts of js-ipfs, which parts are reusable, and which parts should get a new name. For reference, js-ipfs has:

1. a CLI (ipfs-cli)
2. a programmatic interface based on the CLI (ipfs-core)
3. an HTTP API based on the CLI (ipfs-http-server) and a client for that API (ipfs-http-client)
4. a gRPC-over-websocket API server (ipfs-grpc-server) and client (ipfs-grpc-client)

The HTTP interface mirrors the current go-ipfs HTTP API, and we will talk through how renaming elements on the go side should affect the JS side.

What about naming the “spec for an IPFS client”?

If someone wanted to implement a new IPFS client and still maintain network compatibility, where might they might look and how they might refer to "network compatibility"? There's nothing today stating that all nodes must be able to communicate via TCP + Noise + Mplex (the most widely supported libp2p combination) whether directly or via some proxy. Similarly, there's nothing saying nodes need to support protocols like identify or Bitswap. We believe it might be helpful to have a spec + name for the thing most people implicitly think of when they're talking about "the network" which is the minimal subset of protocols that a greenfield IPFS client would need to implement to be compatible with existing clients in a growing way. That said, this “spec + name” is not in the current renaming effort, but we’ll have a parallel conversation about this during Lab Week 2021.

Actions

• Get agreement on whether using GitHub discussions or another mechanism
• @BigLep enable GitHub discussions on ipfs/ipfs repo.
• @BigLep create 2 discussions for the votes to do the week of 2021-11-01.
• New name for go-ipfs #471
• Name for the "public IPFS DHT" #473
• @BigLep schedule time to discuss JS naming
• @BigLep schedule time to determine whether to spec/name “an IPFS client””
  - [ ] @momack2 or @BigLep solicit votes/nominations during LabWeek.
• @BigLep Outline sequence of events for the actual renaming
• @BigLep Do 202201 version of nominating/voting, including surfacing better in public (Matrix/Discord, discuss.ipfs.io)
• @BigLep Setup something like https://Ipfs.io/implementations to make clear "go-ipfs" is only one of many