关于用 PubSub 来实现互动内容的一些构想

Nov 7, 2022 at 10:31:01 PM
pubsub

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.jsonlikes.json 这样的文件,然后定时重新渲染网站发布。

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

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

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

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

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

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

一些可能的问题

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

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