CRDT in production, how to handle protocol versioning?

@yard Anton Zhuravsky
Sun, 07 Sep 2025 15:40:32 +0000

One of the more reliable (esp in decetralized setting) solutions would be to store a migrations map holding all « executed » migration versions as keys. So, if a client A on version 1 opens the doc, it would set add { 1: true } to the map; client B with version 2 would add { 2: true }. When client C running version 1 connects, it would « add » version 1 again (not really add as it is there already, but you get the point); version 2 merged by client B stays intact. Once you have this, a client can always scan versions stored in this map and do something when it sees a newer version that it supports - the safest would prob be to display an upgrade prompt.

Just mind nested maps have some kinks when it comes ro merging, but you prob won’t be affected by these