Offline mode deletes content

[Willyfrog]

open same page on desktop and mobile

on mobile

• turn on airplane mode
• write "this is mobile"

on desktop

• write "this is desktop

on mobile

• turn off airplan mode

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.

[zefhemel]

Thanks for this. Indeed, there's no proper conflict detection at this stage.

[zefhemel]

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.

[Willyfrog]

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)

[jzacsh]

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.

[ngrilly]

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.

[zefhemel]

@ngrilly When you say Obsidian, you mean Obsidian Sync?

[Willyfrog]

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

[ngrilly]

@zefhemel Yes, Obsidian Sync.

[infogulch]

I really like the simplicity of the PUT idea, I think its the right layer to solve this problem:

• When a file is downloaded to the client, add an Etag header with the hash of the file
• When the file is uploaded via PUT, set If-Match header to the value of the last etag
• If the server receives a PUT with an etag that matches the current hash of the file, then everything is fine, replace the file as usual
• If the etag doesn't match, then the server creates a new file (with -{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.
  • Perhaps a new plug to display the diff of two files could be added independently

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.

[jzacsh]

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.

[zefhemel]

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.

[jzacsh]

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.