js-IPFS 0.48.0发布：亮点：- js-IPFS 0.48.0带来了更好的默认连接、更小的块存储和更直观的API。default默认情况下启用代理节点：- 以前，JSIPFS主要面向浏览器，如果您想使用DHT，则浏览器是个问题。由于页面上的时间不足以进行或响应DHT查询，也无法拨号，因此即使您能够宣传自己也没有人可以与您建立联系检索该块。这导致每个人的服务质量下降，并且通过DHT查找更多同伴和内容变得困难。- 为浏览器内的IPFS节点提供更好的网络体验有多种方法之一是委托节点。委托节点是一个网络对等体，代表其他节点执行操作。在这种情况下，它将代表我们进行DHT查询，以便能够找到更多同伴和内容。- js-IPFS 0.48.0默认在配置中启用委托节点，这意味着您可以看到更多的对等节点，并且能够更快、更可靠地找到内容。默认情况下，它使用共享的公共委托节点为您提供最佳的体验。但是，在生产环境中部署JSIPFS时，应托管自己的委托节点并相应地配置JSIPFS。DHT配置：- JSIPFS的完整DHT实现以及GoIPFS 0.5中进行的所有更改将在今年晚些时候发布。但是，您可以使用实验性DHT实现来运行您的节点，尽管某些功能可能无法正常工作。您的节点的性能可能会随时间而降低，但您仍然可以使用它来解析内容和查找对等对象。- DHT对等方以客户端模式或服务器模式运行。DHT客户端可以进行查询以查找内容和其他对等方，但不会将自己宣传为内容的提供者或回答任何查询。如果您的节点位于NAT防火墙之后，应以客户端模式运行它。- js-IPFS 正在支持Autonat，但在此之前，它将只在客户端模式下运行。这是获得完全DHT支持的垫脚石。块更小，更快的区块存储：- 在IPFS早期，所有CID都是v0。它们只是一个简单的多重哈希，通过在字节数组中添加前缀来告诉您剩余字节的哈希类型和大小。这些多重哈希通过在散列数据创建块，然后将其存储在IPFS回购中。- 后来引入了v1CID，它们在字节数组中添加了版本号和编解码器，但CID仍然包含多重哈希。一个块可以对应多个CID，只要它们具有相同的多重哈希。- 块存储将CID转换为字节数组，并使用它们生成块的密钥。这导致重复存储v0CID和v1CID的相同块。为了解决这个问题，js-IPFS 0.48.0将所有块存储为从CID中提取的base32编码的多哈希。这消除了重复存储和重复查找，但需要进行回购迁移。更直观的API：- 随着IPFS生态系统的发展，越来越多的开发人员开始使用我们的API。为了更好地适应开发者的需要，我们对API进行了重构。我们删除了一些要求，使开发人员只需关注自然原语，如节点中的流和浏览器中的文件/ Blob。我们还将API从回调改为Promises，再从Arrays改为AsyncIterators，以支持大量流式数据的传输。- 使用js-IPFS 0.48.0，ipfs.add现在返回单个项目。这个改变在可用性方面带来了提升，因为经常出现的问题是“我添加了一个文件，然后又回来了，那是什么？”现在您不再需要解释CID，而是直接得到它。带有可选参数的API：- 最近，我们发布了一个更改，允许将AbortSignal传递给所有API方法。但这导致在options参数中不包含可选参数的一些问题。使用js-IPFS 0.48.0，所有可选参数现在都包含在options对象中，使API更加直观。