Last october, I announced a swift port of Automerge, including a demo app. The demo app included some networking capabilities, which has been extracted and updated - a bit more "batteries" included for the core Automerge library, to continue to make it easier to build cross-platform apps with live collaboration.
The Automerge project has a Javascript based server, automerge-repo, that makes it easy to support multiple documents, as well as handle the coordination of persistent storage and network synchronization. Today we've cut an initial release of a swift implementation of the automerge-repo sync protocols:
The library provides support for coordinating multiple Automerge documents, and syncs seamlessly both peer to peer and via a WebSocket to the parallel automerge-repo project. It is built with the latest concurrency updates (requiring Swift 5.8 or later), and I think is fully strict concurrency compatible (there are a couple of warnings remaining, but I'm reasonably confident they're extraneous warnings in the 5.10 compiler)
The library wraps Apple's Networking protocol to provide peer to peer networking and syncing that you can configure to auto-connect and replicate, to make that last "batteries included" link in collaborative software. And of course, if you don't like how we handled it, you're welcome to take from what's there to make your own - and contributions are more than welcome.
I've cut this intiatial release after proving to myself it's working with the Automerge iOS/macOS demo application MeetingNotes - although the final support is still in a branch while I continue to update documentation for both it and this project.
The overall Automerge OSS project runs an Automerge Discord server if you want to pop in and chat about this, or Automerge-swift - look for the channel #automerge-swift under the ports category on the server.
I hope to - in particular I’d love to make it possible to use this with server side swift down the road. The stumbling blocks are more mechanical than technical - it’s awkward to downright annoying to deal with a binary artifact in the various Linux distributions, and the core Automerge library uses a core library written in Rust. We do support using Automerge-swift with WebAssembly, so the markers and connection points are in that package where I could reference a C library compiled from the Rust core instead of the current XCFramework used for iOS, macOS, etc.
It’s in the back of my head, but so far there’s not been a pressing need that encouraged anyone to either help contribute to make that happen, or help fund development work for the same.
But beyond just the "challenge mode" of it, the Automerge open source project chose to do it's core implementation in Rust, and while I'm confident they wouldn't oppose such an effort, neither would I expect them to actively support it - as maintaining an intentionally cross-platform core in more than one language, doing parallel development, is more overhead and challenge (with dubious payback on that effort) than I expect they would be interested in pursuing.
They have active implementations using this core library in WASM/Javascript and through a C FFI interface Python, Go, Java, C#, and Ruby.
It's not that I haven't asked the same question, it's just that while I'll tilt at some crazy windmills, I'm not up to the time and effort when there's a perfectly viable option with less work right in front of me, that just happens to be written in a different language.
