No-Intro 和 Redump 是两个由互联网上的游戏爱好者们维护的数据库，目标是获取并保存过去那些通过卡带和碟片发行的老游戏的特征码。

早期的卡带游戏，由于破解和盗版，玩家能够玩到的版本往往已经被修改过。比如你很可能就玩过一个叫做「90 坦克」的游戏，实际上是修改自 NAMCO 的一个叫做 BattleCity 的 Famicom 游戏。而在游戏的开头，往往就会有修改者加上的新的画面，也就是 intro。而 No-Intro 项目就是希望能够维护这样的一个数据库——里面是这些游戏的原始版本的特征码，也就是 hash 值。hash 是一类计算机算法，通过复杂的数学过程，可以获得一个文件的特征。如果两个文件的内容的每一个字节都是相同的，那么就会获得同样的 hash 值。常见的 hash 算法有 MD5，SHA1，SHA256 等等。

IPFS 的 Content-addressing，也就是「内容寻址」技术，也是基于 hash。只是你不能直接在 IPFS 中使用一个文件的 SHA256 值来找到它，而需要通过 IPFS 的 CID。IPFS 的 CID 包括了比整个文件的 hash 更多的信息。

所以，假如像 No-Intro 这样的数据库中除了 SHA-256，同时也包括文件的 CID 值的话，那么就有可能可以通过整个互联网，而不是某台确定的服务器，来获得那个文件了。只是这种不确定性，同时带来了很多的优点和缺点。

优点：

• 不需要依赖单一的网站地址或者服务器地址：互联网上的大部分地址都无法存在太长时间，平均值甚至不到半年。而 SHA256 或者 CID 是确定的，因此假设如果互联网上确实有 IPFS 服务器存储了某个确定的 CID，那就有机会下载下来。

缺点：

• 巨大的 overhead。如果你曾经看过 Jeff Dean 的 Latency Numbers Every Programmer Should Know，然后再看 IPFS 内容寻址的过程，就会看到一切都完全发生在一个不确定的网络架构中，因此需要非常多次尝试才有可能拿到有意义的数据，这是巨大的 overhead。

基于内容寻址的技术因为其不需要依赖特定服务器，谁都可以存，因此在理想情况下，如果一个内容确实有很多节点都存了，于是也就实现高度的去中心化。所以在一些理解和需要这样架构的场景中已经得到了应用，比如 NFT 的图片。当你在 mint 一个 NFT 时，大部分情况下，你获得的 token 并不是图片文件本身，而是图片文件的 CID。理想情况下，NFT 的 CID 会有多个 IPFS 节点存储，因此通过 CID 就始终可以获得这张图片。为什么一直强调「理想情况」，因为另外一种情况是，随着时间过去，一件事情没有人在意了，于是本来存有这些 CID 的服务器逐个下线了，最终这个 CID 也就消失了。就像，如果，即使我们知道一个 ROM 的 SHA-256 值，但这个世界上最后一块存有那个 ROM 的硬盘坏了，并且原始的最后一张游戏卡带也坏了的话，那么即使知道 SHA-256 值，那个文件也会永远消失。如果要增加一个文件持续存在下去的可能性，那么尝试多种完全不同的存储和传播方式就是有意义的。

前面提到 IPFS 的内容寻址过程中的不确定性，这或许是一个可能可以解决的用户体验问题。相比通过商业 CDN 加速过的内容，从 IPFS 网络下载东西的体验可能会非常糟糕——因为很多时候如果试着直接在浏览器里访问一个 CID，就卡在那里了，像是什么都没有发生。

早期的拨号互联网，及 BitTorrent 下载也面临同样的用户期待值问题，于是开发者们通过更好的进度条来实现了用户体验优化。

而这样的图形化手段，应该也可以用于改进 IPFS CID 的下载体验。但目前（2024 年 7 月），这样的软件存在于传统的 HTTP 协议和 BT 协议，暂时还没有看到针对 CID 下载的实现。

想象这样的一种可能性：各种下载网站上提供的不只是 https 或者 torrent，也提供或者只提供 CID。下载一个文件的过程是把 CID 放进原生支持 IPFS 通讯协议的下载软件，然后下载软件就可以显示一个非常具体的进度，甚至可以通过多线程同时下载文件的不同部分。对于下载网站的维护者来说，文件存储除了完全自己维护，也有可能通过更多的其他人的服务器来分档存储。而对于各种 retro 内容存档爱好者们来说，自己在意的内容，也多了一种获得和持续存在下去的可能。

PubSub 是 IPFS 中的一项实验性的功能，默认没有在 kubo 发布版本中打开。它的具体工作方式是这样的：

• 节点 A 向一个名称为 X 的 channel 发布消息
• 如果节点 B 和 A 互相是 peers，并且节点 B 正在监听同样名称的 channel，那么就可以实时收到这条消息

在 Planet 搭载的 kubo 中，打开了这个功能，因为它可以实现更快的 IPNS 信息更新。这也是 kubo 的另外一个实验性的功能：通过 PubSub 更新 IPNS。

于是，基于 PubSub，有可能可以实现一些很有趣的互动玩法。

对文章的点赞和评论

目前 Planet 的信息发布和传播模式，是一种类似广播的单向模式：写文章的人可以把自己的作品向外传递出去，通过 IPNS 或者 ENS，但是无法收到来自读者的反馈，比如评论和点赞之类的互动是不存在的。

如果，Planet 里增加一个基于 PubSub 的互动玩法，就可以这样实现：

• Planet app 监听所有本地 IPNS 同名的 channel
• 读者可以向这些 channel 发送点赞或者评论
• 如果监听方收到这些点赞和评论，就存入本地的 comments.json 和 likes.json 这样的文件，然后定时重新渲染网站发布。

这样的话，就在一个完全去中心化的环境里，实现了点赞和评论。

话题投稿、公共空间、话题广场

PubSub channel 的另外一种用法，可以被当作一个公共容器。

比如你写了一篇关于 Ethereum 这个标签的文章，那么就可以把文章的 IPNS + UUID 作为一条消息发送到一个叫做 planet:tags:ethereum 的 channel。

另外一端，如果有程序持续在监听这个 channel，就可以把所有收到的 URL 保存及抓取，然后生成一个专门关于这个 tag 的网站。

整个发送、接收、展示的步骤，都是自组织、无需许可的。

一些可能的问题

PubSub 机制要能完全按照期待的那样正常工作，需要满足两个稍微有些苛刻的条件：

• 发送方和接收方需要同时在线。因为中间并没有任何暂存机制，而是一种广播机制，所以如果消息发送的时候，接收方没有在线。那么稍后接收方在线的时候，并不能看到之前的消息。一种解决方式是发送方重复发送很多次，把去重（deduplication）这个问题交给接收方去处理。
• 发送方和接收方需要是彼此的 peers。这个问题在 WAN 复杂的网络条件下，究竟会如何影响 PubSub 功能的使用体验，及能对此做什么优化，我还需要通过代码尝试更多的实际情况才能知道。

通过 Planet 发布内容，是一种完全去中心化的 local-first 模式。所有的内容不仅存储是在本地，提供对外服务的 IPFS 节点，也是运行在本地机器上。这样的好处是，整个内容的发布和订阅流程，不会受制于外部的大公司的基础架构。

但这样的完全去中心化的做法，也会带来一些挑战：

因为提供对外服务的 IPFS 节点也在本地，因此需要程序一直运行。这对于 Mac mini 或者 Mac Studio 这样的桌面设备可能不是太大的问题，但是对于笔记本电脑的用户就会是一个问题。

对于笔记本电脑的用户，因为不可能让设备保持 24x7 开机及联网，那么最简单的解决方案还是引入服务器来帮助分发。如果你有自己的 Linux 服务器，那么下面是在自己的服务器上启用 IPFS 来帮助 Planet 内容分发的操作步骤和原理。

安装 IPFS for Linux Server

• 从这里 https://github.com/ipfs/kubo/releases 下载 Linux 版本的 IPFS 服务器端。就是一个可执行文件，我通常的做法就是把这个文件 ipfs 复制到 /usr/local/bin/ipfs，这样就可以随时运行 ipfs 指令。
• 启动 IPFS 进程 ipfs daemon，可以使用 screen、tmux 或者 supervisord。

IPFS 进程启动之后，就可以通过下面这样的指令来 pin 内容了。

ipfs pin add /ipns/olivida.eth

所谓 pin 内容这个操作，其实很类似 BitTorrent 下载中的「做种」这个概念。就是，如果一份内容被 pin 了，意味着本地保存了一份经过完整性校验的拷贝，如果网络上的其他节点也要请求这份内容，那么就是所有有拷贝的机器来一起提供，就像 BitTorrent 下载时，是所有 seeder 来一起服务下载请求。

你可以在 pin add 使用 IPNS 地址，无论是 k 开头的原生 IPNS 地址，或者是 ENS 地址，都可以支持：

ipfs pin add /ipns/planetable.eth

ipfs pin add /ipns/k51qzi5uqu5dgv8kzl1anc0m74n6t9ffdjnypdh846ct5wgpljc7rulynxa74a

如果你把这样的指令放到 crontab 中，那么就可以实现追踪 IPNS 背后的 CID 的变化，然后一直 pin 最新内容。

Pinning DAO

上面的这个操作过程，对于没有 Linux 服务器的用户来说，还是太麻烦了。我们需要更简单的方式，而这件事情非常适合做成一个 DAO。

DAO 存在的意义，就是服务成员的共同需求。

Pinning DAO 里，这个共同需求就是：成员需要全世界各地的服务器，来保证发布在 IPFS 上的内容，是永远可用的。为了持续实现这一点，于是需要一个或者多个这样的去中心化自治组织。

我希望接下来能够看到这样的组织的出现。

为了完整实现这个愿景，将会需要构建很多新的开源软件。

比如一个用 RainbowKit 或者 ConnectKit 实现登录的网站，ENS holder 登录并且通过 Juicebox 付款成为 DAO Member 之后，就可以通过这个 DAO 部署在全球各地的基础架构来 pin 自己发布在 ENS 上的网站。

而除了提供 pin 服务之外，DAO 也可以为成员提供自建的 Plausible 流量统计之类的服务。

虽然内容通过 DAO 进行了分发，但是权威版本依然是完全控制在用户本地。而不是像之前，因为使用了 Web 2.0 大公司的平台来存储和分发内容，内容的实际存活就完全被大公司所控制了。如果一个 DAO 提供的服务成员不满意，那完全可以发起另外一个，充分的竞争会带来最好的产品和服务。