Cool stuff!<p>What do you suggest is the sweet spot for document size and "hotness"? Your cookbook [0] says "We suspect that an Automerge document is best suited to being a unit of collaboration between two people or a small group." Does that mean tens of kilobytes? Hundreds? More? And how much concurrent contention is viable? And is the "atom of contention" the document as a whole, or do you have any plans for merging of sub-parts?<p>Also, do you have support for juggling multiple transports, either concurrently or back-to-back? In particular, I'm thinking about synchronizing via the cloud when connected, and falling back to peer-to-peer when offline. In that peer-to-peer case, how many peers can I have, and can my peer network behave as a mesh, or must it stick together to some degree?<p>And finally, it looks like your tutorial [1] doesn't actually exist! You refer to it in a blog post [2], but it's a dead link.<p>[0] <a href="https://automerge.org/docs/cookbook/modeling-data/" rel="nofollow noreferrer">https://automerge.org/docs/cookbook/modeling-data/</a><p>[1] <a href="https://automerge.org/docs/tutorial/introduction/" rel="nofollow noreferrer">https://automerge.org/docs/tutorial/introduction/</a><p>[2] <a href="https://automerge.org/blog/automerge-2/" rel="nofollow noreferrer">https://automerge.org/blog/automerge-2/</a>
If you are interested in this, check out the video from StrangeLoop 2023:<p><a href="https://www.youtube.com/watch?v=Mr0a5KyD6BU">https://www.youtube.com/watch?v=Mr0a5KyD6BU</a><p>Also, check out the unconf for localfirst that happened right after 2023:<p><a href="https://github.com/LoFiUnconf/stlouis2023">https://github.com/LoFiUnconf/stlouis2023</a><p>Ink & Switch is doing such interesting stuff. Their after party at StrangeLoop was so cool.
Nice, I use automerge with Rust via autosurgeon [0] which is their Rust wrapper, but looks like it hasn't been updated recently, any updates on that? I'm guessing with a small team that web support is taking priority right now, as I'm running this on my Rust client (technically Flutter but via the FFI package flutter_rust_bridge [1]) and server (via the Axum web server crate).<p>[0] <a href="https://github.com/automerge/autosurgeon">https://github.com/automerge/autosurgeon</a><p>[1] <a href="https://github.com/fzyzcjy/flutter_rust_bridge">https://github.com/fzyzcjy/flutter_rust_bridge</a>
Curious how you think about this compared to Electric SQL [1] - I'm currently deciding what sync solution we're going to use for a product rebuild and have been looking at quite a few<p>[1] <a href="https://electric-sql.com/" rel="nofollow noreferrer">https://electric-sql.com/</a>
Super excited to see Automerge getting this high-level API out. Been following since before 1.0 and I can't wait to play around with the latest incarnation! Congrats to the Automerge team.
Last time I looked into CRDT, automerge was not as fast/efficient as yjs, but the team was actively improving the algorithm. Is there any benchmark to show the progress.
This is exciting in several ways including the fact that
Martin Kleppmann is involved with the project. Filed at the top of my reading list if nothing else to see an undoubtedly good example of a complex Rust project.
This is super powerful, been playing around with the previous releases for the past few days. It works really well, but still needs a few dx tweaks to make it performant for large applications. You have to watch the callbacks yourself to update slices of state and unless your app is small enough that the whole thing can re-render every update.<p>That being said, I love everything automerge is doing and hope this pace will keep up!
So is it like <a href="https://en.wikipedia.org/wiki/Google_Wave" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Google_Wave</a> - but with limited scope and with new algos and finally usable?
Seems we have a really great technical spec — but aren’t y’all gonna build a product on it and let us pay you to use? A google docs for markdown/quarto documents would be brilliant but apparently does not yet exist…
Would Automerge be a good choice for a non-realtime single-user app that just needs to have reliable offline support?<p>E.g a personal note-taking app where the user will never have any collaborators, but where they expect the app to work fully offline on multiple devices and reliably sync up when they come online.
Anyone have any info on who is behind this project, how reliable it is (will it be around in 2 years), etc? Considering using it for one of my projects.
By calling it "repos", they're trying to capitalize on the popularity of VCS repositories, but these don't have their history implicitly tracked the way Automerge does, just explicitly tracked by committing and pushing.<p>I think it's cool, but I still see CRDTs as very niche.<p>I also want "local-first" but what I really want is something closer to how traditional desktop apps just open up, edit, and save files, not some real time collaboration that is already set up before I add my first collaborator.