I've been building a sync framework that app devel...
# share-your-work
m
I've been building a sync framework that app developers can integrate, to securely sync state changes between clients. I call it DIPLOMATIC, after the concept of a diplomatic bag which travels through foreign territories, but protected against inspection. So far I've got a couple host implementations targeting Deno and Cloudflare (Workers + Durable Objects + D1), as well as client libraries to build web clients in React and CLI tools in Deno. The attached video shows off a demo app that displays and updates a consistent status message across clients. It generates and stores a cryptographic seed (synced via the browser's password manager), queues status changes when offline or not connected to a host, then pushes queued changes when connected, and receives real-time updates using WebSockets. I've got some rough docs up at https://diplomatic-docs.replit.app, and a walkthrough of the demo app from the video at https://diplomatic-docs.replit.app/docs/demos/status.html. The backstory is that, for a while I've wanted to build a grand life-planning app, like a TODO list that can operate at the decade-level rather than the daily-level. But I kept running into these blocks: a) I'll want to access it from phone and desktop, so it needs a sync solution, b) maintaining servers is a pain, and c) a life-planning tool will necessarily have personal info, so it shouldn't hang out in plaintext on someone else's computers. These sorts of issues aren't unique to this tool. In fact, I think they're common enough to merit a general solution. The Web 2.0 client/server model gave us easy software updates and access from multiple devices with consistent data. But we backslid by making all app data visible to the software provider and relying on them to maintain their servers. Mobile apps gave us the additional expectation that we could access our data while offline. I think there's a simple solution to get the best of all worlds, by encoding app state changes as objects (the Event Sourcing pattern), then encrypting those deltas and shipping them off to a server which relays to other clients, which then decrypt and apply the changes locally. With this architecture, the relay servers all have a standard interface (not application-specific), and they're blind to delta contents, so hosting becomes a commodity. This means companies could specialize in just running these hosts, giving application developers a secure backend without the maintenance burden. It also creates a standardized import/export format for app state—the delta log, so you get a backup format for free. I'm only designing around single-user apps at the moment. Having a "last-wins" policy for conflicts makes things nice and simple.. If anyone knows of related work I should check out, has suggestions, wants to collaborate, ... let me know. The code is still a bit messy, but I'm planning to tidy that up and open the repo soon.
❤️ 1
b
https://github.com/standardnotes/app has e2e encrypted sync, but I don't remember the exact techniques they use. --- How much do you care about offline multi-device scenarios with conflicts? What is the resolution of "last-wins" you care about? Relaying deltas sounds like Operational Transformation, specifically "operation-based OT" as opposed to "state-based OT"? If so, consider CRDTs instead — basically they give more peace of mind. (I'd google "yjs encrypted" & "automerge encrypted" — the 2 leading CRDT engines) https://localfirstweb.dev/ probably has useful resources.
👍 1
m
Thanks! Yes, this is inspired by operational transform. I’m aware of CRDTs but haven’t tried them out. I’ll read up. Regarding offline conflicts, they’ll be frequent. E.g. a TODO list where you check off a box on your laptop but shut the lid before it syncs. Then you check the box again on your phone for a sense of completion. In single-user scenarios like this, “last wins” just means whichever operation has a later timestamp is the one that overwrites the current app state, which makes sense because any conflict just indicates the user changed their mind, rather than being an actual disagreement as in multi-user scenarios. Thanks for that link to localfirstweb.dev! That is highly relevant.
b
Just happened upon https://jazz.tools/ which is also encrypted sync
m
Thanks again. I’ll take a look at how they’re doing things.
k
I'm also building a long term life planning tool called Kairos (greek word for nonlinear time). I haven't considered the architecture as much as you but I'm going with yjs + tiptap to create local first state www.eusaybia.com
m
Awesome. It looks like we’ve got some similar ideas. Something I’ve found useful in my prototype (a spreadsheet) is presenting each timescale with the containing one, e.g. week-level planning has annual goals simultaneously visible. I’ll be interested to see your app develop.
g
Came here to also mention jazz.tools but I guess I'm late to the party. Chatted with the creator last summer, very motivated bright fellow. It would be great to see you combine efforts!