A number of future-of-computing projects including Dynamicland, many by Ink & Switch and the work of @Alexander Obenauer have all been evolving along a similar theme. I'm calling it "The Data-First movement"! https://open.substack.com/pub/duncancragg/p/the-data-first-movement

More original than this one:

you're right, it is!

Your notion of "data" seems to include some form of cross-device synchronization. That can take many forms. Real-time vs. delayed. Automatic or on demand. Merging changes in particular can take many forms, from automerge to manual as with Git. Is any of these forms more aligned with your idea of data-first than the others?

Thanks for the challenge! And good question of course. Which is just the point of the chat example, to bring out these questions. Data-First simply requires that you have something to ship updates to data across devices, such as: • a sync server, perhaps using CRDTs • a syncing-and-sharing database • a pub-sub mechanism, letting you subscribe to a remote data chunk's changes • a message bus, where messages or events describe updates or latest states • a DHT, P2P, maybe a P2P chat protocol • ...? Any of these should allow you to implement collaboration over shared, live data. ---- In my own Object Network, there's only one base mechanism on top of which everything else can be built, which is observing an object's state:

=> OBS: <uid>
<= UID: <uid>  V:34  type: banana  colour: yellow
<= UID: <uid>  V:36  type: banana  colour: yellow-brown
<= UID: <uid>  V:37  type: banana  colour: brown-black

(yes, it missed

V: 35

: it's unreliable, like life!)

Would a Git repository be sufficient as well? It's no good for chatting, but I much prefer on-demand manual sync (with manual merge) when collaborating on a technical document.

I call this "content" in my notes, but the idea is similar. I have the phrase "It's the content, stupid" in there. That said, I think it's important to consider what a content/data centric model is like without regard for sync. Sync is cool, but it's also fundamentally unreliable, in the sense of "the network is unreliable" as a distributed systems principle, and also maybe I just want to have an offline computer. I don't want sync as a mandatory part of my computing model.

I wouldn't want sync to be a mandatory part of my computing model either, but I believe that it's a good idea to think about sync when designing a computing model. In particular, sync requires diff and merge, which remain unsolved problems for complex structured data.

Well, as I say, at the bottom of sync all you need is packets on the wire, on top of which you can have CRDTs or manual git-like merges, or just last-edit-wins. You can implement reliability or not, it's up to you. All I want from a Data-First project is that it does something other than (a) having nothing to say, or (b) offering a silo service locked in to the front end and locking your data in! So I simply specifiy "Local-First", which covers that in a sufficiently vague way (even though most Local-First folk seem to use CRDTs, that's only a strong suggestion not a requirement as I read it)