Suggestion to merge/rename `Sync` and `Online` modes

[bilogic]

Problem

The names Online and Sync do not fully convey their meaning until I think really hard about it

Suggestion

1. I'm wondering what are the use cases to have Online mode

2. Comparing to chat apps, wouldn't it be simpler to have a single Sync mode? (And do away with even having to name it?)

   • If the network is present, send and save on server
   • If the network is not present, store locally until we can send it to the server

3. If the use case for Online is to avoid storing data locally, may I suggest a setting that states, Keep all data on server, store nothing locally

4. If the use case is to allow collaboration, we could have a setting Allow live collaborative editing

5. Having only 1 mode will eliminate having to choose (which incurs a heavy cognitive load trying to figure out their meanings)

[zefhemel]

Ok so here's the history of these modes.

Once upon a time, there was only what we call "Online" mode: the server does the heavy lifting: the indexing, the storing of files etc, the client was relatively thin. It's a web app right, that's how web apps work.

Then, there was a desire to also have a version, mostly useful for mobile where you could use it offline. On mobile you don't always have a (reliable) internet connection. So I worked on "native" mobile apps, using a thin web app wrapper, and somehow manage to integrate the server and the client into one, had it use the phone's local file system, and have that run fully on the mobile phone. Cool, but how do you now get your data in and out?

This is when the sync engine was born.

Initially, the sync engine would sync a local file system (on mobile, but I also had an Electron based desktop app at that time) to a remote one (likely your server).

This all worked, but maintaining and testing an Android, iOS and Electron app (for Windows, Linux and Mac), as well as the traditional web app version was a lot of work and there was just me. So I tested an alternative: the PWA route where the browser's IndexedDB database could be used as a local file system, and all indexing would happen in browser to support working offline. This worked, and turned the server into a "dumb" data store. No logic living there other than getting PUTs and GETs for files basically. All clients just constantly synced.

This was basically what Sync mode is today. You can still run SB this way, btw, when you enable the SB_SYNC_ONLY environment variable, all you'll have is this sync mode without a choice.

Then people said: "Yeah, I use various clients, sometimes just for a few minutes on a public computer to check something and I don't want to wait for it to synchronize 1000 pages and potentially hundreds of megabytes of attachments to local storage before I can have access." That's fair, this was a web app after all and having to wait for maybe minutes or longer to access your content is not really expected behavior. So this is how we got to the current mode where you can choose.

Sync is inherently problematic, whenever you offer it you will run into sync conflicts, so the less sync you need to do the better, that's why I like Online mode, and for most people this will be enough. This is also why it's the default. The other reason it's the default is that if Sync would be the default, it would immediately start to sync stuff before you're able to switch modes.

Yes, there is some complexity in supporting these two modes, but it's fairly managable. There may be UX complexity in these two modes, which I can also appreciate.

Now I also know that naming things is one of the hard problems in computer science, so perhaps there's simply a better name for these modes that is more obvious. I'm open to suggestions here.

Let me know if that makes sense.

[bilogic]

Ok, thanks for the very detailed explanation.

Off the top of my mind, I think sticking to Online by default makes sense. Then have a setting Allow SB to edit without network, which changes SB into sync mode.

Thinking of better names will take some time, but what do you think of this approach? This will take 1 button off visible menu :)

[zefhemel]

When you say setting, do you mean a global setting (like in the SETTINGS file) or per client? The reason it's a button now is that it's per client. Btw, you can hide the button if you don't like it, there's a setting for it

# Hide the sync button
hideSyncButton: true

[bilogic]

I see, I missed the point that it has to be per client. Let me ponder on this more. And I thank you for being so patient and receptive.

[bilogic]

Some checkbox (on/off) options so that we name it once rather than twice:

1. Usable when offline, unchecked to avoid massive syncing and check to use while in airplane mode
2. Runs while offline
3. Runs while disconnected
4. Runs without network
5. Offline mode (from https://github.com/jarnedemeulemeester/findroid), but this might give the wrong impression that SB is forcefully disconnecting itself

I will list more if others come to mind

[zefhemel]

All these options raise the question: why would I ever disable this, what's the trade off? I mean, everybody wants to allow running while offline, right? :)

[bilogic]

Well, they would have to read the documentation or this issue of your very detailed explanation. Hehe

Perhaps I would also consider, how many have large notes? And what kind of numbers are we talking to require minutes to sync? My guess is probably in the region of 100+MiB and probably a small fraction of users?

Since online is the default, my whole suggestion is to actually hide this Runs while offline in the settings until they find a need to write in airplane mode. Ignorance is a bliss, so no questions will be asked. :)

[zefhemel]

As to: how many have large or many notes: I have absolutely no idea. There is no tracking in SB and since people self host I have 0 data on this. I have had people complain that syncing their 200,000 file folder took a long time, but that could just have been an anomaly.

[bilogic]

It might be the way syncing is done because if it is going to be 200,000 HTTP requests, that is likely to take quite a while even with a persistent connection.

Perhaps let me summarize the impact of the change I'm proposing

1. I wouldn't be surprised if many have pondered online vs sync, but few have asked. This will no longer happen and probably results in a better first time experience with SB
2. Only Runs while offline needs to be explained in the documentation
3. The large data folks will only face trouble if they turn it on and they should just live with it for now, to be guilty of generating 200,000 text files(!) (I'm just kidding)
4. More space on the main UI with 1 less option

Again, it would be your prerogative, I just wanted to provide this feedback as I really appreciate SB and this bugged me since day 1.

Regarding syncing, the fix might come in the form of zipping up all the data, transmitting in 1 HTTP request and expanding locally.