I’ve run in to [Automerge](https://github.com/automerge/automerge) this morning. It has a mention in the channel history, but given how exciting I find it, I think it’s worth mentioning again. The technology itself is really interesting, but its principles, ideas and direction are maybe even more interesting. TLDR: it provides a distributed JSON style document store that’s happily “offline first”. Changes made at one node can be propagated to others over any desired medium (Flash disks or network), where they’ll be combined. It has some support for relational style data in the form of a “table” type. Sequence types allow collaborative insert and removal without conflict. IMHO something providing functionality like this will be pretty vital to the future of computing. I envisage we’ll move to keeping programs in a database like this, along with other information such as chats, code review, issue trackers, wiki, ui designs, … basically all the data we use as we develop. It’ll also make sense as a store for all user data: not walled in by a single tool, but freely usable and updatable from any application view on to it. I’m just looking through some internal details documented here: https://github.com/automerge/automerge/blob/master/INTERNALS.md and hoping it’ll make enough sense that I might be able to start on a swift implementation.

Maybe you might also been interested on this article that discuss CRDT and especially Causal Tree. I personnaly found the article very intersting and accessible, and it convinced me to give Causal Tree a try. What's can really interested you is that the author has done some proof of concept of Causal Tree and experiments using Swift! 🙂 Here is the link: http://archagon.net/blog/2018/03/24/data-laced-with-history/

A related thread from the history: https://futureofcoding.slack.com/archives/C5T9GPWFL/p1556770732488500

@shalabh Thanks – the ink and switch folks are doing some really cool stuff, and I like their manifesto position very much. The focus on local whenever possible is surely the right technical, privacy, and … well, economic (?) approach. On “economic”, local data and user ownership seems much more likely to reduce data siloing, which is a natural barrier to entry for any kind of centralised system to exploit.

@Benjohn Barnes (sorry for this late answer but I have missed your message for some reason...) Maybe I miss what you are meaning, but I find that with casual tree it is easy to identify revision. In fact, at a lower level a causal tree is just a sequence of events. Each event is uniquely identified by its author (read device/editor unique id) and a timestamp in that author's timeline. A revision is identified by the last event for each author involved in the revision. With this you identify the sequence of events for this revision and you are able to consistently reconstruct the state from it.

I think what I was trying to get at, perhaps mistakenly, is that an event i don’t have in a log yet may have “happened before” other events in the log and can be inserted before them when I do finally become aware of it. I was thinking that this makes it hard to “tag” a “version” and declare “this is the stable release at the moment”. But I think you could probably build “something” on top of all this to support stable tags — or I could be mistaken that it’s even a problem!

A tag T1 is a list of authors' last events that "you are aware of". If you are aware of new "older events" later (it is weird to write this 🙂 ), they are not included in the revision tag T1. If you want to consider them you need to create a new tag T2. As an offline first system, you could never know what happens concurently, and you can only identify version on events you have heard about. So all this allow to identify versions without ambiguity, considering the full and complete history of the events log, with such a tag you can reconstruct a "past" state. But of course it says nothing on the meaning of a particular tag, i.e. there is no meaning in it for stuff like "this is the stable version at the moment" (as you mentionned).