when I had set out to start doing this, I was still largely thinking of it working in a "file centric" model, given that's how the VS Code version worked. this was sort of okay, until I started to work on it and see some weird things.
first, a local file makes sense if you have a "dumb view" on top of it, but how does it work on a server (like the browser-hosted version)? does a server have to serve depot-the-editor and a file itself? between that and the standalone I was running into lots of permutations: 1) standalone + local file (normal file read) 2) standalone + network file (?) 3) server + local file (FileAccess web api) 4) server + network file (some endpoint, somewhere?)
having to start carving seperate paths for all the different cases felt weird, so I did a lot of thinking, and what I came up with was the idea of having both a "dumb" front end app, and then an actual server daemon that "serves" the data that the apps can connect to. this is doubly nice for doing a lot of in-browser testing, because I can serve the data on localhost and connect to it through both the web browser and the standalone app.
given the possible synchronous connections though, I also made the actual jump to CRDTs and Yjs. then also there was a need to implement an actual REST API on the same server for static asset serving for images.
here's a video of two clients connected to the same source — notice the bool flags changing!