Kubo v0.28.0 版本解析DHT 清理、Gateway 去 API 化与 Object API 移除的迁移指南【免费下载链接】kuboIPFS implementation in Go: a daemon that stores and serves content-addressed data, with a CLI, HTTP Gateway, and RPC API项目地址: https://gitcode.com/GitHub_Trending/ku/kuboKubo v0.28.0 是一次以清理遗留接口、收窄攻击面、提升内容可达性为核心的版本升级它彻底移除了 Gateway 端口上遗留的/api/v0子集、删除了 2021 年起便已废弃的 Object API 命令与 RPC 客户端中的 DHT 命令同时不再在 WAN/LAN DHT 上记录私网与回环地址并让 pin 根 CID 在 reprovide 时获得优先广播。本文以 v0.28.0 变更日志为主线结合仓库源码与 配置文件文档逐条说明破坏性变更的成因、受影响场景与迁移路径帮助运行旧版 Kubo 的节点运营者平滑升级。v0.28.0 变更总览v0.28.0 的主要变更集中在五条高亮条目中前三条属于破坏性变更Breaking Changes后两条属于行为优化类别变更内容影响面破坏性RPC 客户端移除废弃的 DHT 命令依赖client/rpc的二次开发者破坏性Gateway 端口上/api/v0子集完全移除依赖 Gateway 端口调用 RPC 的遗留软件破坏性移除废弃的 Object API 命令使用ipfs object cmd的脚本与用户优化不在 LAN/WAN DHT 上记录回环/私网地址单机多节点测试场景需关注testprofile优化Pin 根 CID 在 announce 时优先广播使用默认 reprovide 策略的节点配套的版本依赖升级包括go-libp2pv0.33.0 → v0.33.2、go-libp2p-kad-dhtv0.24.4 → v0.25.2、boxov0.18.0 → v0.19.0以及 Go 工具链升级至 1.22见 v0.28.md 中的ci: upgrade to go 1.22。其中go-libp2p-kad-dht的 v0.25.0 引入的filter local addresses (for WAN) and localhost addresses (for LAN)正是本版本 DHT 地址清理行为的底层来源。RPC 客户端移除废弃的 DHT API统一走 Routing API变更内容Kubo 的 Go RPC 客户端库client/rpc中一组早已标记废弃的 DHT 命令被删除。变更日志明确指出请改用 Routing API。对应的 PR 为client/rpc!: remove deprecated DHT commands。在 client/rpc/routing.go 中可以看到 Kubo 客户端当前对外暴露的 routing 能力RoutingAPI接口提供Get、Put、FindPeer、FindProviders、Provide等方法对应 HTTP API 的POST /api/v0/routing/...端点内容路由相关操作统一走routing命令族而非旧的dht命令族。迁移指引对于二次开发者将代码中对client/rpc内废弃 DHT 方法的调用替换为 RoutingAPI 上语义等价的方法FindProviders、FindPeer、Provide等底层 HTTP 端点从/api/v0/dht/*迁移到/api/v0/routing/*若你的应用直接通过 CLI 或 HTTP API 调用ipfs dht findprovs等命令请改用ipfs routing findprovs。需要注意的是本仓库当前版本的 core/commands/routing.go 与 core/commands/dht.go 仍同时存在但 dht 命令族已在 CLI 与 RPC 层面持续收窄新代码应一律以 routing 命令族为准。Gateway/api/v0完全移除RPC 与 Gateway 端口职责分离变更内容自 v0.28.0 起通过 Gateway 端口默认8080暴露的遗留 RPC 子集被彻底删除对应的提交为core/corehttp!: remove /api/v0 from gateway port。此前 Kubo 一直允许在 Gateway 端口上以/api/v0/...前缀访问一部分 RPC 端点主要是只读的数据访问类命令这一行为自废弃后现已完全下线遗留问题详见 ipfs/kubo#10312。这一变更的源码依据可以在 core/corehttp/commands.go 中看到commandsOption通过ServerOption显式挂载 RPC 命令处理链到 API 端口而 Gateway 端core/corehttp/gateway.go仅注册网关自身的处理器/ipfs、/ipns、/api/v0前缀的 RPC 转发逻辑已被移除。迁移方案反向代理同端口共存如果你有依赖此行为的遗留软件希望在同一个端口上同时提供/ipfs内容服务与/api/v0RPC官方给出的做法是在 Kubo 前面架设反向代理把 Gateway 与 RPC 挂载到同一端口# 示例Nginx 将 /api/v0 转发到 RPC 端口5001其余请求转发到 Gateway 端口8080 server { listen 80; location /api/v0/ { proxy_pass http://127.0.0.1:5001; # 见下方安全提示 } location / { proxy_pass http://127.0.0.1:8080; } }⚠️安全警告把 RPC 暴露到公网或任何非受信网络会带来严重安全风险。Kubo 官方强烈建议在这种部署形态下为 RPC 配置访问控制。具体的做法是设置API.Authorizations见 config/api.go仅允许受信来源调用 RPC例如{ API: { Authorizations: [ { Type: basic, User: admin, Pass: …, AllowedPaths: [/api/v0/, /webui] } ] } }此外更安全的替代方案是直接使用 RPC 端点的 socket 鉴权IPFS_API_AUTH环境变量 /api.authorizations不要对公网开放裸 RPC。对运维的影响若你的脚本只使用默认 Gateway 端口调用/api/v0/block/get、/api/v0/cat等命令升级后必须改为调用 RPC 端口默认5001的对应端点或按上述方式配置反向代理检查是否有第三方应用硬编码了http://node:8080/api/v0/...的地址此类调用在 v0.28.0 将直接返回 404从本次变更起Gateway 端口与 RPC 端口的职责已彻底分离Gateway 只服务内容/ipfs、/ipnsRPC 只服务管理面/api/v0。移除废弃的 Object API 命令变更内容自 2021 年起被标记废弃的 Object API 命令对应ipfs object subcommand家族在本版本中大部分被移除提交为core/commands!: remove deprecated object APIs。但以下三个命令得以保留因为它们的替代实现尚未就绪ipfs object diffipfs object patch add-linkipfs object patch rm-link保留原因分别对应两个仍开放的 issueipfs/kubo#4801object diff的替代与 ipfs/kubo#4782link 操作的替代。从当前仓库的 core/commands/object 目录结构可以看到Object 相关命令已被收敛为少数文件该目录下仅剩 3 个.go文件正是本次删减后的结果。迁移指引Object API 的长期替代方案是DAG APIipfs dag get/put/resolve/stat与CID / UnixFS 工具链旧 Object 命令已移除建议替代object get/object putdag get/dag putcore/commands/dagobject links/object statdag stat、lscore/commands/ls.goobject patchadd-link/rm-link 除外使用dag MFSfiles组合操作object newdag put构造空 DAG需要继续执行 DAG 差异比较的脚本可保留object diff但应规划向dag命令族的长期迁移需要修改链接的脚本目前仍可依赖object patch add-link/object patch rm-link但要意识到这两个命令属于等待替代实现的过渡形态未来仍可能被移除。DHT 地址清理不再记录回环与私网地址变更内容Kubo v0.28.0 起不再在 LAN DHT 上跟踪回环地址loopback如 127.0.0.1也不在 WAN DHT 上跟踪私网地址private如 10.x、192.168.x。其底层实现来自go-libp2p-kad-dhtv0.25.0 的filter local addresses (for WAN) and localhost addresses (for LAN)与fix: apply addrFilters in the dht两项修复。带来的直接效果是其他节点不会再尝试拨号那些大概率不可达的地址从而减少无效连接尝试、降低网络噪音与拨号超时开销。对单机多节点测试的影响与testprofile这一行为变化会打破同一台机器上运行多个 Kubo 实例的测试场景——因为实例之间只能通过回环/私网地址互联。为此v0.28.0 引入了新的配置项Routing.LoopbackAddressesOnLanDHTbool类型默认false见 config/routing.go 中的DefaultLoopbackAddressesOnLanDHT false。设为true后LAN DHT 将不再忽略回环地址从而允许同一主机上的多个节点通过 LAN DHT 相互发现与路由。该配置在 docs/config.md 中标记为EXPERIMENTAL实验性未来版本可能变化并特别说明大多数用户不需要该设置它仅在测试场景同一机器运行多个节点、且部分节点未启用Discovery.MDNS.Enabled下有用。testprofile 会自动开启此选项。在 config/profile.go 中可以看到testprofile 的Transform函数test: { Description: Reduces external interference of IPFS daemon, this is useful when using the daemon in test environments., Transform: func(c *Config) error { c.Addresses.API Strings{/ip4/127.0.0.1/tcp/0} c.Addresses.Gateway Strings{/ip4/127.0.0.1/tcp/0} c.Addresses.Swarm []string{ /ip4/127.0.0.1/tcp/0, } c.Swarm.DisableNatPortMap true c.Routing.LoopbackAddressesOnLanDHT True c.Bootstrap []string{} c.Discovery.MDNS.Enabled false // … return nil }, },即testprofile 会同时把 API/Gateway/Swarm 全部绑定到127.0.0.1的随机端口、关闭 NAT 端口映射、清空 Bootstrap、关闭 mDNS并设置Routing.LoopbackAddressesOnLanDHT true。如果要在自定义测试环境中复现该行为可以手动设置ipfs config Routing.LoopbackAddressesOnLanDHT true # 或直接编辑 ~/.ipfs/config注意default-networkingprofile 是test的逆操作但并未显式将LoopbackAddressesOnLanDHT复位其 Transform 中没有对应字段如需在测试后恢复默认值请手动ipfs config Routing.LoopbackAddressesOnLanDHT false。生产节点的默认行为生产节点保持默认值即可LAN DHT 忽略回环地址、WAN DHT 忽略私网地址避免向全网广播127.0.0.1、10.x.x.x、192.168.x.x等不可达地址从而减少其他节点对无意义地址的拨号尝试。Pin 根 CID 在 announce 时获得优先级变更内容v0.28.0 改进了 reprovide定期重新广播本地内容的顺序策略被 pin 内容的根 CID 现在会被优先广播。对应提交为core/node: prioritize announcing pin roots, and flat strategyipfs/kubo#10376。这意味着当节点向 Amino DHT 广播 provider 记录时最重要的 CIDpin 的根会最先到达路由系统从而让关键内容更快地被其他节点发现和获取。策略与源码实现该行为由提供provide策略控制。虽然变更日志中引用的是旧的Reprovider.Strategy配置名但本仓库当前版本已将其迁移并废弃为Provide.Strategyconfig/reprovider.go 中的Reprovider结构体明确标注Deprecated: use Provide.Strategy instead. This will be removed in a future releasedocs/config.md 中Reprovider.Strategy同样标记为REMOVED并被Provide.Strategy取代新配置定义在 config/provide.go其中ProvideStrategy为位掩码类型包含ProvideStrategyAll、ProvideStrategyPinned、ProvideStrategyRoots、ProvideStrategyMFS等取值默认值为DefaultProvideStrategy all。all默认与pinned策略下的优先级行为all广播本地存储块的全部 CID根优先pinned仅广播递归 pin 的 CIDipfs pin add -r的根与子块且根块最先广播随后才是递归 pin 的子块见 docs/config.md 中的顺序说明roots仅广播显式 pin 的 DAG 顶层根 CID。核心实现位于 core/node/core.go构建 pinner 时通过WithPinnedProvider/WithRootsProvider选项注入 provider且代码注释明确说明二者互斥、优先使用pinnedroots : (strategyFlag config.ProvideStrategyRoots) ! 0 pinned : (strategyFlag config.ProvideStrategyPinned) ! 0 // Important: Only one of WithPinnedProvider or WithRootsProvider should be active. // Having both would cause duplicate root advertisements since pinned includes all // pinned content (roots children), while roots is just the root CIDs. // We prioritize pinned if both are somehow set (though this shouldnt happen // with proper strategy parsing). if pinned { opts append(opts, dspinner.WithPinnedProvider(prov)) } else if roots { opts append(opts, dspinner.WithRootsProvider(prov)) }策略配置建议实际配置请使用新字段Provide.Strategy而不是已废弃的Reprovider.Strategy{ Provide: { Strategy: all, DHT: { Interval: 22h } } }根据 docs/config.md 的建议pinnedmfsunique适合启用 GC 的节点或桌面用户——只广播 pin 与 MFS 内容并通过 bloom filter 去重可显著降低 reprovide 的内存占用例如 1000 万 CID 场景从约 750 MB 降至约 42 MBpinnedmfsentities在上一项基础上进一步跳过文件内部 chunk减少 provider 记录数量注意变更策略并重启后provide 队列会被自动清空以保证只广播符合新策略的内容也可用ipfs provide clear手动清空。其他值得关注的变更依赖与工具链升级go-libp2p-kad-dhtv0.24.4 → v0.25.2包含地址过滤本次 DHT 清理的底层来源、FindProvidersAsync输出去缓冲的性能优化、以及 tracing 相关的多项修复go-libp2pv0.33.0 → v0.33.2quic-go 升级到 v0.42.0boxov0.18.0 → v0.19.0CI 工具链升级至 Go 1.22ci: upgrade to go 1.22。配置项形态调整Routing.AcceleratedDHTClient被改为Flag类型chore(config): make Routing.AcceleratedDHTClient a Flag配置行为与布尔语义保持一致但配置解析更严格lowpowerprofile 切换为 autoclient 模式fix: switch lowpower profile to autoclient进一步降低低功耗节点的资源占用。性能与内部优化coreapi/unixfs--only-hash模式下不再额外创建 IpfsNodecoreapi/unixfs: dont create an additional IpfsNode for --only-hashipfs add --only-hash的计算开销进一步下降reframe 相关代码清理完毕chore: finish reframe removalWebUI 升级到 v4.2.1。升级建议清单针对从 v0.27.x 及更早版本升级到 v0.28.0 的节点运营者与开发者建议按以下顺序检查扫描 RPC 调用确认代码/脚本中没有使用/api/v0/dht/*端点全部替换为/api/v0/routing/*检查 Gateway 端口使用若曾在8080端口调用/api/v0/*请迁移到 RPC 端口默认5001或配置带鉴权的反向代理并设置API.Authorizations清理 Object 命令依赖将object get/put/links/stat/new/patch保留的三个子命令除外迁移到dag/files/ls命令族核对 DHT 地址行为生产节点无需改动单机多节点测试请使用ipfs init --profiletest或手动设置Routing.LoopbackAddressesOnLanDHT true审视 provide 策略需要 pin 根优先广播效果的用户保持默认Provide.Strategyall即可需要控制广播范围与内存的节点考虑pinnedmfsunique等组合策略并注意配置项已由Reprovider.Strategy迁移至Provide.Strategy。如需了解完整变更条目可查阅 v0.28.0 完整变更日志各配置项的详细语义与默认值见 docs/config.md。【免费下载链接】kuboIPFS implementation in Go: a daemon that stores and serves content-addressed data, with a CLI, HTTP Gateway, and RPC API项目地址: https://gitcode.com/GitHub_Trending/ku/kubo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubo v0.28.0 版本解析：DHT 清理、Gateway 去 API 化与 Object API 移除的迁移指南
Kubo v0.28.0 版本解析DHT 清理、Gateway 去 API 化与 Object API 移除的迁移指南【免费下载链接】kuboIPFS implementation in Go: a daemon that stores and serves content-addressed data, with a CLI, HTTP Gateway, and RPC API项目地址: https://gitcode.com/GitHub_Trending/ku/kuboKubo v0.28.0 是一次以清理遗留接口、收窄攻击面、提升内容可达性为核心的版本升级它彻底移除了 Gateway 端口上遗留的/api/v0子集、删除了 2021 年起便已废弃的 Object API 命令与 RPC 客户端中的 DHT 命令同时不再在 WAN/LAN DHT 上记录私网与回环地址并让 pin 根 CID 在 reprovide 时获得优先广播。本文以 v0.28.0 变更日志为主线结合仓库源码与 配置文件文档逐条说明破坏性变更的成因、受影响场景与迁移路径帮助运行旧版 Kubo 的节点运营者平滑升级。v0.28.0 变更总览v0.28.0 的主要变更集中在五条高亮条目中前三条属于破坏性变更Breaking Changes后两条属于行为优化类别变更内容影响面破坏性RPC 客户端移除废弃的 DHT 命令依赖client/rpc的二次开发者破坏性Gateway 端口上/api/v0子集完全移除依赖 Gateway 端口调用 RPC 的遗留软件破坏性移除废弃的 Object API 命令使用ipfs object cmd的脚本与用户优化不在 LAN/WAN DHT 上记录回环/私网地址单机多节点测试场景需关注testprofile优化Pin 根 CID 在 announce 时优先广播使用默认 reprovide 策略的节点配套的版本依赖升级包括go-libp2pv0.33.0 → v0.33.2、go-libp2p-kad-dhtv0.24.4 → v0.25.2、boxov0.18.0 → v0.19.0以及 Go 工具链升级至 1.22见 v0.28.md 中的ci: upgrade to go 1.22。其中go-libp2p-kad-dht的 v0.25.0 引入的filter local addresses (for WAN) and localhost addresses (for LAN)正是本版本 DHT 地址清理行为的底层来源。RPC 客户端移除废弃的 DHT API统一走 Routing API变更内容Kubo 的 Go RPC 客户端库client/rpc中一组早已标记废弃的 DHT 命令被删除。变更日志明确指出请改用 Routing API。对应的 PR 为client/rpc!: remove deprecated DHT commands。在 client/rpc/routing.go 中可以看到 Kubo 客户端当前对外暴露的 routing 能力RoutingAPI接口提供Get、Put、FindPeer、FindProviders、Provide等方法对应 HTTP API 的POST /api/v0/routing/...端点内容路由相关操作统一走routing命令族而非旧的dht命令族。迁移指引对于二次开发者将代码中对client/rpc内废弃 DHT 方法的调用替换为 RoutingAPI 上语义等价的方法FindProviders、FindPeer、Provide等底层 HTTP 端点从/api/v0/dht/*迁移到/api/v0/routing/*若你的应用直接通过 CLI 或 HTTP API 调用ipfs dht findprovs等命令请改用ipfs routing findprovs。需要注意的是本仓库当前版本的 core/commands/routing.go 与 core/commands/dht.go 仍同时存在但 dht 命令族已在 CLI 与 RPC 层面持续收窄新代码应一律以 routing 命令族为准。Gateway/api/v0完全移除RPC 与 Gateway 端口职责分离变更内容自 v0.28.0 起通过 Gateway 端口默认8080暴露的遗留 RPC 子集被彻底删除对应的提交为core/corehttp!: remove /api/v0 from gateway port。此前 Kubo 一直允许在 Gateway 端口上以/api/v0/...前缀访问一部分 RPC 端点主要是只读的数据访问类命令这一行为自废弃后现已完全下线遗留问题详见 ipfs/kubo#10312。这一变更的源码依据可以在 core/corehttp/commands.go 中看到commandsOption通过ServerOption显式挂载 RPC 命令处理链到 API 端口而 Gateway 端core/corehttp/gateway.go仅注册网关自身的处理器/ipfs、/ipns、/api/v0前缀的 RPC 转发逻辑已被移除。迁移方案反向代理同端口共存如果你有依赖此行为的遗留软件希望在同一个端口上同时提供/ipfs内容服务与/api/v0RPC官方给出的做法是在 Kubo 前面架设反向代理把 Gateway 与 RPC 挂载到同一端口# 示例Nginx 将 /api/v0 转发到 RPC 端口5001其余请求转发到 Gateway 端口8080 server { listen 80; location /api/v0/ { proxy_pass http://127.0.0.1:5001; # 见下方安全提示 } location / { proxy_pass http://127.0.0.1:8080; } }⚠️安全警告把 RPC 暴露到公网或任何非受信网络会带来严重安全风险。Kubo 官方强烈建议在这种部署形态下为 RPC 配置访问控制。具体的做法是设置API.Authorizations见 config/api.go仅允许受信来源调用 RPC例如{ API: { Authorizations: [ { Type: basic, User: admin, Pass: …, AllowedPaths: [/api/v0/, /webui] } ] } }此外更安全的替代方案是直接使用 RPC 端点的 socket 鉴权IPFS_API_AUTH环境变量 /api.authorizations不要对公网开放裸 RPC。对运维的影响若你的脚本只使用默认 Gateway 端口调用/api/v0/block/get、/api/v0/cat等命令升级后必须改为调用 RPC 端口默认5001的对应端点或按上述方式配置反向代理检查是否有第三方应用硬编码了http://node:8080/api/v0/...的地址此类调用在 v0.28.0 将直接返回 404从本次变更起Gateway 端口与 RPC 端口的职责已彻底分离Gateway 只服务内容/ipfs、/ipnsRPC 只服务管理面/api/v0。移除废弃的 Object API 命令变更内容自 2021 年起被标记废弃的 Object API 命令对应ipfs object subcommand家族在本版本中大部分被移除提交为core/commands!: remove deprecated object APIs。但以下三个命令得以保留因为它们的替代实现尚未就绪ipfs object diffipfs object patch add-linkipfs object patch rm-link保留原因分别对应两个仍开放的 issueipfs/kubo#4801object diff的替代与 ipfs/kubo#4782link 操作的替代。从当前仓库的 core/commands/object 目录结构可以看到Object 相关命令已被收敛为少数文件该目录下仅剩 3 个.go文件正是本次删减后的结果。迁移指引Object API 的长期替代方案是DAG APIipfs dag get/put/resolve/stat与CID / UnixFS 工具链旧 Object 命令已移除建议替代object get/object putdag get/dag putcore/commands/dagobject links/object statdag stat、lscore/commands/ls.goobject patchadd-link/rm-link 除外使用dag MFSfiles组合操作object newdag put构造空 DAG需要继续执行 DAG 差异比较的脚本可保留object diff但应规划向dag命令族的长期迁移需要修改链接的脚本目前仍可依赖object patch add-link/object patch rm-link但要意识到这两个命令属于等待替代实现的过渡形态未来仍可能被移除。DHT 地址清理不再记录回环与私网地址变更内容Kubo v0.28.0 起不再在 LAN DHT 上跟踪回环地址loopback如 127.0.0.1也不在 WAN DHT 上跟踪私网地址private如 10.x、192.168.x。其底层实现来自go-libp2p-kad-dhtv0.25.0 的filter local addresses (for WAN) and localhost addresses (for LAN)与fix: apply addrFilters in the dht两项修复。带来的直接效果是其他节点不会再尝试拨号那些大概率不可达的地址从而减少无效连接尝试、降低网络噪音与拨号超时开销。对单机多节点测试的影响与testprofile这一行为变化会打破同一台机器上运行多个 Kubo 实例的测试场景——因为实例之间只能通过回环/私网地址互联。为此v0.28.0 引入了新的配置项Routing.LoopbackAddressesOnLanDHTbool类型默认false见 config/routing.go 中的DefaultLoopbackAddressesOnLanDHT false。设为true后LAN DHT 将不再忽略回环地址从而允许同一主机上的多个节点通过 LAN DHT 相互发现与路由。该配置在 docs/config.md 中标记为EXPERIMENTAL实验性未来版本可能变化并特别说明大多数用户不需要该设置它仅在测试场景同一机器运行多个节点、且部分节点未启用Discovery.MDNS.Enabled下有用。testprofile 会自动开启此选项。在 config/profile.go 中可以看到testprofile 的Transform函数test: { Description: Reduces external interference of IPFS daemon, this is useful when using the daemon in test environments., Transform: func(c *Config) error { c.Addresses.API Strings{/ip4/127.0.0.1/tcp/0} c.Addresses.Gateway Strings{/ip4/127.0.0.1/tcp/0} c.Addresses.Swarm []string{ /ip4/127.0.0.1/tcp/0, } c.Swarm.DisableNatPortMap true c.Routing.LoopbackAddressesOnLanDHT True c.Bootstrap []string{} c.Discovery.MDNS.Enabled false // … return nil }, },即testprofile 会同时把 API/Gateway/Swarm 全部绑定到127.0.0.1的随机端口、关闭 NAT 端口映射、清空 Bootstrap、关闭 mDNS并设置Routing.LoopbackAddressesOnLanDHT true。如果要在自定义测试环境中复现该行为可以手动设置ipfs config Routing.LoopbackAddressesOnLanDHT true # 或直接编辑 ~/.ipfs/config注意default-networkingprofile 是test的逆操作但并未显式将LoopbackAddressesOnLanDHT复位其 Transform 中没有对应字段如需在测试后恢复默认值请手动ipfs config Routing.LoopbackAddressesOnLanDHT false。生产节点的默认行为生产节点保持默认值即可LAN DHT 忽略回环地址、WAN DHT 忽略私网地址避免向全网广播127.0.0.1、10.x.x.x、192.168.x.x等不可达地址从而减少其他节点对无意义地址的拨号尝试。Pin 根 CID 在 announce 时获得优先级变更内容v0.28.0 改进了 reprovide定期重新广播本地内容的顺序策略被 pin 内容的根 CID 现在会被优先广播。对应提交为core/node: prioritize announcing pin roots, and flat strategyipfs/kubo#10376。这意味着当节点向 Amino DHT 广播 provider 记录时最重要的 CIDpin 的根会最先到达路由系统从而让关键内容更快地被其他节点发现和获取。策略与源码实现该行为由提供provide策略控制。虽然变更日志中引用的是旧的Reprovider.Strategy配置名但本仓库当前版本已将其迁移并废弃为Provide.Strategyconfig/reprovider.go 中的Reprovider结构体明确标注Deprecated: use Provide.Strategy instead. This will be removed in a future releasedocs/config.md 中Reprovider.Strategy同样标记为REMOVED并被Provide.Strategy取代新配置定义在 config/provide.go其中ProvideStrategy为位掩码类型包含ProvideStrategyAll、ProvideStrategyPinned、ProvideStrategyRoots、ProvideStrategyMFS等取值默认值为DefaultProvideStrategy all。all默认与pinned策略下的优先级行为all广播本地存储块的全部 CID根优先pinned仅广播递归 pin 的 CIDipfs pin add -r的根与子块且根块最先广播随后才是递归 pin 的子块见 docs/config.md 中的顺序说明roots仅广播显式 pin 的 DAG 顶层根 CID。核心实现位于 core/node/core.go构建 pinner 时通过WithPinnedProvider/WithRootsProvider选项注入 provider且代码注释明确说明二者互斥、优先使用pinnedroots : (strategyFlag config.ProvideStrategyRoots) ! 0 pinned : (strategyFlag config.ProvideStrategyPinned) ! 0 // Important: Only one of WithPinnedProvider or WithRootsProvider should be active. // Having both would cause duplicate root advertisements since pinned includes all // pinned content (roots children), while roots is just the root CIDs. // We prioritize pinned if both are somehow set (though this shouldnt happen // with proper strategy parsing). if pinned { opts append(opts, dspinner.WithPinnedProvider(prov)) } else if roots { opts append(opts, dspinner.WithRootsProvider(prov)) }策略配置建议实际配置请使用新字段Provide.Strategy而不是已废弃的Reprovider.Strategy{ Provide: { Strategy: all, DHT: { Interval: 22h } } }根据 docs/config.md 的建议pinnedmfsunique适合启用 GC 的节点或桌面用户——只广播 pin 与 MFS 内容并通过 bloom filter 去重可显著降低 reprovide 的内存占用例如 1000 万 CID 场景从约 750 MB 降至约 42 MBpinnedmfsentities在上一项基础上进一步跳过文件内部 chunk减少 provider 记录数量注意变更策略并重启后provide 队列会被自动清空以保证只广播符合新策略的内容也可用ipfs provide clear手动清空。其他值得关注的变更依赖与工具链升级go-libp2p-kad-dhtv0.24.4 → v0.25.2包含地址过滤本次 DHT 清理的底层来源、FindProvidersAsync输出去缓冲的性能优化、以及 tracing 相关的多项修复go-libp2pv0.33.0 → v0.33.2quic-go 升级到 v0.42.0boxov0.18.0 → v0.19.0CI 工具链升级至 Go 1.22ci: upgrade to go 1.22。配置项形态调整Routing.AcceleratedDHTClient被改为Flag类型chore(config): make Routing.AcceleratedDHTClient a Flag配置行为与布尔语义保持一致但配置解析更严格lowpowerprofile 切换为 autoclient 模式fix: switch lowpower profile to autoclient进一步降低低功耗节点的资源占用。性能与内部优化coreapi/unixfs--only-hash模式下不再额外创建 IpfsNodecoreapi/unixfs: dont create an additional IpfsNode for --only-hashipfs add --only-hash的计算开销进一步下降reframe 相关代码清理完毕chore: finish reframe removalWebUI 升级到 v4.2.1。升级建议清单针对从 v0.27.x 及更早版本升级到 v0.28.0 的节点运营者与开发者建议按以下顺序检查扫描 RPC 调用确认代码/脚本中没有使用/api/v0/dht/*端点全部替换为/api/v0/routing/*检查 Gateway 端口使用若曾在8080端口调用/api/v0/*请迁移到 RPC 端口默认5001或配置带鉴权的反向代理并设置API.Authorizations清理 Object 命令依赖将object get/put/links/stat/new/patch保留的三个子命令除外迁移到dag/files/ls命令族核对 DHT 地址行为生产节点无需改动单机多节点测试请使用ipfs init --profiletest或手动设置Routing.LoopbackAddressesOnLanDHT true审视 provide 策略需要 pin 根优先广播效果的用户保持默认Provide.Strategyall即可需要控制广播范围与内存的节点考虑pinnedmfsunique等组合策略并注意配置项已由Reprovider.Strategy迁移至Provide.Strategy。如需了解完整变更条目可查阅 v0.28.0 完整变更日志各配置项的详细语义与默认值见 docs/config.md。【免费下载链接】kuboIPFS implementation in Go: a daemon that stores and serves content-addressed data, with a CLI, HTTP Gateway, and RPC API项目地址: https://gitcode.com/GitHub_Trending/ku/kubo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考