Just one more thing (Q&A starting at 29:20 poked me too much)... *IF* you focus on the UX of timeline composition, then the pain points of merge conflicts go away. What we have right now, with git, is a UX problem on only a subset of inter-timeline dynamics. If you only use a command line (or one step up some kind of rudimentary diffing tool UX designed by backend people), AND your use case is merging source code then merging can be a PITA. But if you focus on timeline UX and you're enabling merge *composition* then that can be a completely different story! For example, if you are merging source code then you better nit pick on the details of order. But imagine you are presenting a "multiplayer" collaboration on a recipe composition. In this domain, presenting alternative edits on text is the same visual workflow as providing alternative subsections of the recipe. Say the recipe's OP polls followers for pictures of their meals created with the recipe. Now when you present these *picture* alternatives (like a gallery), this is ALSO the same visual workflow of presenting alternatives. You're just conceptualizing them as branching timelines and providing the UX to navigate these timelines. The other aspect, besides time, is enabling space dynamics. For example, take his large document problem. This is because we are used to thinking of the final product as one large object. But if you start thinking of timelines, you can now start thinking of not only sharding large documents, but focusing on providing inter-spatial dynamics. By this I mean you can provide homomorphic transforms from document --chunk--> paragraph --chunk--> sentence. Once we provide timeline dynamics, we can think of each of these aspects of the document as its own timeline. A separate sharding mechanism isn't even required, because the entire foundation of the architecture is about interspatial and inter-timeline dynamics (i.e. enabling push/pulls/merge/sync operations). Unfortunately, programmers are heavily biased in their preconceptions of what "version control" is, added to the fact that they have become mesmerized with git instead of looking to learn from it and move on. But I assure you, this spacetime-oriented approach solves the Q&A issues. Maybe one of these days I won't be shouting into a black hole about this awesomeness! The inkandswitch people are so close...

the stuff of dreams