Open Willyfrog opened 2 years ago
Thanks for this. Indeed, there's no proper conflict detection at this stage.
A way to implement this is to add a type of “conditional put”. That is, “only write this page to disk, if the current timestamp matches X otherwise reject”. For the http_space_primitives
(which is where this protocol is implemented between the browser and server) this may translate to an additional header to be sent as part of the PUT
request.
I’ve been thinking about this and wondering if we could use some sort of patching functionality when updating a page, generating a conflict if it can’t be automatically solved (as git does)
CRDTs maybe? I think the patch approach makes sense but will result in merge conflicts and the complex user experience the ensues, whereas CRDTs might solve this problem more smoothly. https://crdt.tech/implementations seems like a nice list of implementations and I know someone was getting to know the yjs lib in particular.
I think Obsidian is solving this problem without CRDTs, by just merging the server-side and the client-side content using a standard text merge algorithm like the one in difftools
.
@ngrilly When you say Obsidian, you mean Obsidian Sync?
the way to do that in obsidian might depend on the sync, I use iCloud to sync, and if I create a new file with the same name (like a daily note), it will create a daily 1
note and I'm the one expected to merge.
I haven't used the other syncing methods
@zefhemel Yes, Obsidian Sync.
I really like the simplicity of the PUT idea, I think its the right layer to solve this problem:
Etag
header with the hash of the fileIf-Match
header to the value of the last etag-{n}
appended to the filename) with the contents of the PUT request and tells the client to switch to the new file. The client can display a warning about a conflict and let the user resolve the conflict manually.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Match
That said, if the collab plugin is good enough to become the primary way to interact with the server then maybe shifting all effort to build on that would work too.
I agree it could be technically-simpler to use e-tag, but it's of course more complex for users to resolve (and depending on workflow this might happen a lot). Both are of course valid - it's an interesting trade-off to consider, for sure!
I wonder if the file reads/writes happen in such a way that this could be solved entirely in the plug space, and thus let multiple compete?
Also, possibly helpful anecdote: in logseq I can reproduce an issue like this at-will almost daily, due to my using syncthing to run multiple devices' instances of logseq (never actually in parallel, mind you). logseq just blindly deletes whatever is its buffer for the current file (the content I've been writing) when it encounters different content on disk (something that I know syncthing wrote there hours ago, well before I opened the file on this device). This is probably where my concern about user experience stems from; the race among files might be more common a user-experience than is obvious.
How I would imagine people use SB (at least I do) is to deploy just one instance (in your local network) and access it from multiple devices via the browser so you don't need to sync at all this avoiding such conflicts.
Yeah, that makes sense. I suppose I take my laptop places a lot though (to the office, out to a bar/cafe, etc.) so maybe that's why I run into this issue a lot.
open same page on desktop and mobile
on mobile
on desktop
on mobile
Expected: somehow both lines, on obsidian I see that it creates a separate page with a number 2 (mentioning for reference), a conflict like git would also work.
Observed: mobile wins and desktop line is lost.