graft

When you mentioned offline sync and graft, I mistook you for the author of this project: https://github.com/orbitinghail/graft However, they're clearly two different projects. I don't want to take away from the work you've done, as you're clearly knowledgeable, but as someone else observed, heavy use of AI assistance can be observed in all your public projects. It's worth explicitly addressing, especially considering the foundational nature of your project: it's not easily replaced if it turns out to have to have subtle bugs. Though I rarely use it myself, I'd like to know, simply because I'm curious as to how other engineers have incorporated such assistance it into their process.

I think you could! Graft just provides transactions over sets of pages. As long as you can model your data in a compatible way it should work with Graft. A better question is how easy the system allows extensions to intercept filesystem operations. I'd prefer to avoid building a Fuse/NBD layer. I've filed an issue for both: https://github.com/orbitinghail/graft/issues/37 https://github.com/orbitinghail/graft/issues/38

Exciting to see all the continued energy around Graft today! If you want to continue the conversation feel free to join the Discord [1] or post a discussion on GitHub [2]. I'll be at Antithesis BugBash [3] for the next few days talking about Deterministic Simulation Testing (DST) with fellow DST nerds. If you're around please reach out so we can meet in person! Either way, have an excellent day! :) [1]: https://discord.gg/etFk2N9nzC [2]: https://github.com/orbitinghail/graft [3]: https://bugbash.antithesis.com/

For now, Graft suffers from the same minimum payload size of 4KB. However, there are ways to eliminate that. I've filed an issue to resolve this in Graft (https://github.com/orbitinghail/graft/issues/35), thanks for the reminder! As for the more general question though, by shipping pages you will often ship more data than the equivalent logical replication approach. This is a tradeoff you make for a much simpler approach to strong consistency on top of arbitrary data models. I'd love to learn more about the approach you took with your sync engine! It's so fun how much energy is in the replication space right now!

The consistency model doesn't seem to make sense. https://github.com/orbitinghail/graft/blob/main/docs/design.... > Graft clients commit locally and then asynchronously attempt to commit remotely. Because Graft enforces Strict Serializability globally, when two clients concurrently commit based on the same snapshot, one commit will succeed and the other will fail. OK, but, the API provides only a single commit operation: > commit(VolumeId, ClientId, Snapshot LSN, page_count, segments) Commit changes to a Volume if it is safe to do so. The provided Snapshot LSN is the snapshot the commit was based on. Returns the newly committed Snapshot on success. So if a client commits something, and it succeeds, presumably locally, then how should that client discover that the "async" propagation of that commit has failed, and therefore everything it's