Giters

ipfs / boxo

A set of reference libraries for building IPFS applications and implementations in Go.

Home Page:https://github.com/ipfs/boxo#readme

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Rename go-libipfs to boxo

BigLep opened this issue · comments

commented

Done Criteria

  1. go-libipfs the repo is renamed to boxo in such a way that existing consumers aren't broken when they dependended on an explicit version of go-libipfs
  2. key consumers of go-libipfs use boxo instead (e.g., Kubo)
  3. public docs in this repo that use the term "go-libipfs" have been updated to say "boxo"

Why Important

A project's name can set expectations on what a project provides to consumers. We don't want someone to think that they need to use go-libipfs if writing an IPFS implementation in Go. It may be helpful, but it isn't required. Worked started in lead up to IPFS Thing 2022 and is ongoing (ipfs/specs#381 ) to drive the message home that IPFS compatibility is very broad. For example, they must support addressability using CIDs and expose operations (e.g., provision, retrieval) on resources using CIDs. IPFS implementations don't need to support all the functionality of Kubo or all the functionality that is possible with go-libipfs.

Why are we doing this now?

"boxo" has had this history about its name:

  • 2021Q4: project pitched and experimented with in "ipfs/go-libipfs": ipfs/kubo#8543
  • 202211: started making active effort on it in an incremental fashion. In that process, we renamed "go-libipfs" to "libkubo", but reverted back to go-libipfs because we found it "to be even more confusing since its intention is to have code that is reusable and not Kubo-specific" (see ipfs/kubo#8543 (comment))
  • 202303: @ipfs/kubo-maintainers got feedback from @jbenet on how the "go-libipfs" name can cause confusion about what constitutes an IPFS implementation or set expectations about this repo that we don't want (i.e., that one needs to use this repo for one's IPFS implementation written in go).

Renames aren't free, but it's better to do it now before even more start depending on it as part of #196.

Why was this name chosen?

  1. "boxo" is physical toolbox vendor. "boxo" the project is intended to be a toolbox of modules, tools, and examples that can aid one in their go-based IPFS implementation.
  2. Similarity between the "box" and IPFS's "cube" shape.
  3. Audible resonance with "kubo", which is the archeologically-rich soil from which "boxo" has sprouted from and "kubo" is at least currently one of the significant consumers of "boxo".
  4. "boxo" is short.

Why wasn't the community given input into the name?

The request for a name change came late while we were part way through #196. That work was already drawing on and impacting other work. Team resolve to be in limbo was low 1) given current situation and 2) having done a lot of renaming last year with go-ipfs and Kubo, and the name was compelling enough for the reasons listed.

Tasks

commented

@ipfs/kubo-maintainers :

  1. Issue description updated with more details here. Feel free to correct.
  2. I updated #196 to add this to the list.
  3. I updated the FAQ with a TODO to extract portions from here: #190
  4. Added some extra requirements for the migration tooling here: #181

Thanks @Jorropo for leading the charge.

commented

@Jorropo : Congrats on merging #220 🎉 🎉 🎉 .

I'm reopening this issue because there are still a couple of tasks that aren't completed in the checklist above.

commented

2023-04-06 maintainer conversation: we will close this when the Lotus side is in. We're not going to block on Cluster given @hsanjuan is out currently (unless @guseggert learns of someone else who can review/approve there).