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 功能的使用体验，及能对此做什么优化，我还需要通过代码尝试更多的实际情况才能知道。