transactions ids should be 32 bits or less

we cant do this. if peers A and B get a txid conflict, then one of them will have data that they did not push, and if they write next, they never get asked for those records.

I don't think this is invalid. Specifically, if we ever detect a txid conflict, we fall back to requiring a full sync.

I guess your point is:

A copied to B
A syncs with C
B syncs with C (no changes detected)
A adds data, syncs with C
B adds data (gets txid conflict) syncs with C, doesn't see the conflict at rev X.
C now has B's txid, but not all of B's data. It has all of A's data.
A adds data
A syncs with C, and sees the txid conflict.
A resets its replica_uid, and starts a full sync with a new uid.
B adds data and syncs with C, but does not detect there is a conflict ever again since it is now the 'owner' of that replica uid.

One option, if we ever detect a txid conflict, we set that replica_uid as 'known bad' and all future syncs from that replica_uid are aborted and told to reset to a full sync before progressing.

That lets us use the smaller txids, and saves a fair amount of bandwidth on send/receive, and a good amount of stored data.

Changing this to low. It would require polluting a replica_uid on a conflict, but that would enable this to be useful.

So we would need an extra step in the conversation, where the clients just calls the server to inform of a txid conflict.

If this can be added later, we can then shorten the txids, as they should be an opaque list of bytes, we can decide how long we want it to be and change that with time.