Description
Done Criteria
- 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
- key consumers of go-libipfs use boxo instead (e.g., Kubo)
- 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": Consolidate IPFS Repositories 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 Consolidate IPFS Repositories 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?
- "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.
- Similarity between the "box" and IPFS's "cube" shape.
- 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".
- "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
- Validate that github proxying works as expected
- Rename this repo
- Update dependencies
- kad-dht: chore: migrate go-libipfs to boxo libp2p/go-libp2p-kad-dht#832
- Lotus: chore: boxo: migrate from go-libipfs to boxo filecoin-project/lotus#10562
- Kubo: chore: migrate go-libipfs to boxo kubo#9746
- go-ds-crdt feat: upgrade to boxo go-ds-crdt#200
- ipfs-lite feat: upgrade to boxo hsanjuan/ipfs-lite#292
- ipfs-cluster chore: upgrade to boxo ipfs-cluster/ipfs-cluster#1901
- Find/replace go-libipfs in this repo