Post #1404655
2026-02-17 22:59 UTC
@technomancy so the tricky thing is the core representation is automerge (https://automerge.org/). the easy to build easy to extend version of this exposes a rest API that takes automerge blobs and then all the crdt stuff happens on the client. keeps the server simple and unlocks hacking and extension on the client with the trade-off that the client now needs an automerge implementation.
the alternative is a rest API that is defined in terms of comments, issues, edits etc and the crdt stuff happens on the server. now your client only needs an http stack but your constrained by the API the server exposes.
Replies (2)
-
@technomancy@hey.hagelb.org 2026-02-17 23:01
@nasser ah gotcha; in that case if all the merging is literally happening in the browser and it's impossible to make an alternate client for it then I probably wouldn't use it, sorry =(
-
@trurl@mastodon.sdf.org 2026-02-18 03:52
@nasser @technomancy if I'm reading this correctly, it should be feasible to write a mu-style (https://www.djcbsoftware.nl/code/mu/) suite for interacting with this data store, right? (The analogy at work: your data at rest in the project git repo is like mail kept in Maildir format. Tooling is provided on top of it. It could be in client-side logic on Web pages, CLI utilities, or an Emacs package.) I'd vote strongly for the mu-style approach, or at least make it first class in tandem with a browser thing.