Kind 3 already is a CRDT in the narrow sense: a last-writer-wins register per pubkey, ordered by created_at. That is exactly why it loses data silently. Newest write wins, and it cannot tell 'the event never reached me' apart from 'I unfollowed'. Your example needs the piece kind 3 lacks: a version vector or per-entry tombstones. Add tombstones and the merge is well defined. Skip them and any union merge resurrects unfollows, so clients that tried ended up with special casing. My reservation sits on the read side. One kind 3 is a single self-contained event. A follow set spread over hundreds of events only reconstructs if a client can pull the whole set from somewhere. No relay promises that. Whoever syncs against a relay that answers halfway computes a different list and never learns it. So keep the list computable, but let the per-follow events carry enough causal metadata to prove completeness before merging.