Multiple synchronisation targets / storage buckets

It would be very useful to be able to configure several synchronisation targets (e.g. multiple Webdav backing storage areas) each containing non overlapping notebooks / folders, and each with a separate master password / own encryption configuration.

Additionally it should be possible to move a note or notebook from one encryption/storage bucket to another. Or in other words chose which bucket a given notebook or note should be stored in - including a local bucket not synchronised anywhere.

This would be akin to managing several logins/profiles within one screen and being able to move things between them easily.

Few posts relevant for the discussion here.
Laurent's position on the feature

Technical details of an attempt as a part of gsoc '20

1 Like

The problem to solve is sharing without requiring a cloud server - only cloud storage is necessary and can be independently provided.

I feel like I don't quite get the difference between multiple profiles feature suggested in gsoc'20 and multiple sync target feature you're describing.

Would you kindly illustrate the unique points of it?
Does it serve different use case as multiple profiles?

Regarding this comment, I'm sorry for being so daft, but I don't quite understand it either.
How does it relate to suggested feature? Do you imply Joplin to split its database on multiple remote sync targets, sync them at the same time and have those databases communicate with each other (without a server mind you)?

I mean if so, that's a peer2peer architecture looking more like a messenger (or the internet itself) than a note taking application.

If you have notebook A syncing to say webdav server A and notebook B syncing to webdav B, you can easily move a note between notebooks and expect it to be synced to a different target. With multiple profiles you're looking at export from one profile and import into another or copy & paste (won't work with attachments!)

1 Like

Continuing with my example above you could sync a set of notebooks you wanted to share to your webdav B and give credentials to someone else. Your friend can then add it as another sync target and receive your notebooks.

1 Like

I've always been quite keen on the way that OneNote handles it.
Essentially OneNote itself is more of a container and Notebooks within act as a combination profile/target.

Allows you to:

  • Open or close local (or remote) notebooks at will
  • Have different synchronisation accounts per notebook (or none)
  • Have certain notebooks shared between two or more people

Now with Joplin the name Notebook has already been taken and is synonymous with "folder" when it comes to the tree heirachy.
So in order to reduce ambiguity I'll refer to the concept of what would be a OneNote "Notebook" as a "Portfolio".

One way I can see this working (with an absolute ton of effort) would be to redo the entire backend somewhat by splitting the databases.

A "master" sqlite database would control overall application settings (plugins, appearance, general settings, open "portfolios", available "portfolios" etc.) but no longer stores the main data.

For the "portfolios" you would have further, individual, sqlite databases within the main profile directory that contains all the information surrounding note data, sync targets, encryption, note revisions and references its own associated resources folder.

If one was simply working with markdown files from a text editor like Atom or VSCode then this approach is analagous to simply opening a closing a project folder which may or may not be situated in a folder set up for cloud syncing.

Roman has succinctly explained my thoughts better than I had.

The reason my feature suggestion is so much like gsoc'20 is because I had not found gsoc'20 as I was not looking with the same vocabulary. But basically my feature suggestion is very similar to gsoc'20, with the nuance that there must be an easy way to move notes/notebooks between what you name portfolios.

You are right that I have no idea of the implementation complexity, my aim was to try and suggest a feature with the least amount of complexity. The portfolio idea is right on.