Optional ipfs daemon --agent-version-suffix= #7898
Labels
kind/bug
A bug in existing code (including security flaws)
kind/feature
A new feature
need/community-input
Needs input from the wider community
need/maintainers-input
Needs input from the current maintainer(s)
need/triage
Needs initial labeling and prioritization
topic/config
Topic config
topic/dht
Topic dht
topic/libp2p
Topic libp2p
Milestone
I propose we add support for running
ipfs daemon
with optional--agent-version-suffix=
parameter.This would enable vendors that bundle go-ipfs binary to customize
AgentVersion
(listed inipfs id
and announced to other peers) without the need for creating a fake libp2p protocol just to tell one cohort ofgo-ipfs
nodes from another.The first users of this would be Brave browser and IPFS Desktop:
--agent-version-suffix=brave/1.19.85
→go-ipfs/0.9.0/brave/1.19.85
--agent-version-suffix=desktop/0.14.0
→go-ipfs/0.9.0/desktop/0.14.0
Rationale
This would be opt-in, so does not introduce any new tracking vector, it simply aims to make things easier for vendors and to introduce common convention that preserves version number of go-ipfs.
In the current situation, where vendor can rebuild go-ipfs binary and change agentVersion, but then we lose information about % of different go-ipfs nodes on the DHT. By making it a suffix, and making it work without rebuild, we will decrease the number of opaque AgentVersions, making it easier for us to track upgrade dynamics etc.
CLI param, ENV or Config?
No preference atm – all will work for Brave.
IPFS_AGENT_VERSION_SUFFIX
(similar toIPFS_PATH
) is good enough tooipfs daemon
would be preferred, because it has added value if user has multiple go-ipfs nodes running on same localhost (eg. ipfs-desktop and brave). It enables things likeps aux | grep brave
to quickly identify specific daemon instance.cc @andrew @bbondy
The text was updated successfully, but these errors were encountered: