Joplin: [Feature Request] run multiple instances of Joplin

[tessus]

Applications

• Desktop
• Mobile
• Terminal

Summary:

Scope instance to the profile, so multiple apps could run, each with different profiles.

Specification

Having the same app supports or load multiple profiles cannot be done without a massive refactoring, so it's unlikely to happen.

Instead what we can do is provide a way to switch profiles from the app:

• The user clicks on a menu and select change profile
• The list of available profiles is displayed
• User selects on of the profile
• The app closes and re-open and load the selected profile

Changing the structure of the profile directory

Currently, the profile is organised like this:

• ~/.config/joplin-desktop/
  
  
  
  • resources/
  
  
  • database.sqlite
  
  

If we want to support multiple profiles, the config directory should be changed like so (in a way similar to Firefox or Thunderbird multi-profile support):

• ~/.config/joplin-desktop/
  
  
  
  • PROFILE_ID_1/
  
  
  • PROFILE_ID_2/
  
  
  • etc.
  
  
  • profile.ini
  
  

The PROFILE_ID_x directories will be named with a UUID and contain the same profile as above with the "resources" and "database.sqlite" file.

profile.ini will tell what profiles are available. It's content will be like this (same as Firefox):

[Profile1]
Name=Personal
IsRelative=1
Path=cdb4ar19.Personal

[Profile0]
Name=default
IsRelative=1
Path=Profiles/ts6eud8o.default
Default=1

[Profile2]
Name=Work
IsRelative=1
Path=Profiles/ts9akd8o.work

[General]
StartWithLastProfile=1
Version=1

Swiching profiles

To switch profile, save a value to Setting table called "next_profile_id", then close and restart the app. When the app starts it loads "profile.ini", then checks the value of "next_profile_id", and uses that to choose and load the right profile.

Locking per profile

Each app needs to make sure that a given profile can only be open by one application, so there should be form of lock. If a profile is locked, it means it's already opened by another application, so the current application should close.

Locking should be implemented in such a way that if an app crashes, the lock is released. So probably some form of in-memory lock.

Desktop implementation

To restart the app use the built-in Electron function: https://electronjs.org/docs/api/app#apprelaunchoptions

 Mobile implementation

On mobile, give a try to this package to restart the app: https://www.npmjs.com/package/react-native-restart

See also

https://discourse.joplinapp.org/t/can-i-run-a-second-instance-of-joplin/110

[tessus]

An idea how this could be implemented:

• rename database.sqlite to default.sqlite
• if no profile is specified, use default.sqlite
• if --profile xyz is specified, create and/or use database xyz.sqlite
• add a menu item to switch profiles

Or you could use separate profile directories (default, xyz, …) in .config/joplin(-desktop).

[guakamole]

That would be super useful indeed! Example use-case:

I use Joplin for various topics, I would like to be able to sync my "work" notes while at work without having to sync my personal ones for instances. On my phone, on the other hand, I do not want my "work" notes (because they are useless there and for obvious security reasons).

@tessus I saw your comment on the forum, is the --profile option implemented? Is it documented somewhere?

[tessus]

is the --profile option implemented?

Yes.

Is it documented somewhere?

Nope, not that I'm aware of.

[guakamole]

Could you please briefly explain how it works? Is it similar to Firefox profile (dedicated folder and config for each profile)?

Edit: and is it stable/safe to use?

[tessus]

Can we please move the discussion to the forum? I'd like to keep this for the feature request.

[b1n4ryj4n]

any progress on that so we can run multi instances of joplin?

my current work around is that i use 2 virtual machines

[tessus]

@b1n4ryj4n not that I am aware of. I don't know what @laurent22's current opinion about this is. Maybe you can add a comment in the corresponding topic on the forum and also click on the
above (1st post).

[stale[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as "backlog" and I will leave it open. Thank you for your contributions.

[tsumare]

This is definitely still relevant to anyone who wants to separate "Work" and "Personal" notes, share a computer, and many other use-cases.

[laurent22]

By the way, what's the purpose of having multiple sync targets for work and personal? Can't you use one notebook (with sub-notebooks) for work and another one for personal? Even if multiple sync targets were supported, that's how it would look on the sidebar: one folder per sync target. Just trying to understand what's actually needed.

[tsumare]

I love Joplin, and it instantly became my preferred manner of keeping notes, but I don't want my coworkers (or work IT) potentially having access to my personal notes which can contain sensitive information. At the same time, I sometimes work from home or get calls at odd hours, and it's necessary for me to be able to access my work notes from a home system, or even mobile (which is much more difficult than running a second copy in dev mode).

Allowing a particular folder to have a different sync target would potentially be useful, especially in mobile. If I could assign my Work folder to be a separate sync target, that would resolve my issue. I could use that sync target alone at work, and add it as a folder at home.

Having separate sync targets in separate folders would also provide the additional benefit of being able to move notes between targets, though I don't know what would happen to their history entries in this case. My greater concern would be tags. If I have around 30 home tags, and around 30 work tags, having them mix around would make it harder to find things, particularly in the case where I use my work tags only a few days a month. There's also the question of what happens to other top level folders by default, if no sync target is defined. I would definitely be happy with an approach along these lines if it can address these various issues. A second instance just seemed to be the simpler method, to me.

I hope this better explains my use case, however, and I'd be happy to answer any other questions you may have.

[laurent22]

Ok I think I got a bit confused between multiple sync target support, and multiple instance support. The first one would be insanely complex, but the second is do-able. @tessus, I forgot what was the state of the discussion for this? I believe that's what we got to:

• Just use the existing --profile flag to point to one profile or another.

• Internally, do the multiple instance check based on the profile. If I launch joplin --profile ~/work and then joplin --profile ~/perso it works. However, if I launch again joplin --profile ~/work again the multi-instance check prevents the app from starting a second instance.

• We need a memory lock or some way to share memory to allow checking if an app with a given profile is running or not.

• As bonus, we should change the Joplin icon background depending the profile. If no profile is specified, we use the default blue, if one is set, we dynamically change the colour so that it's easy to know which is which in the system tray.

I think that's all we would need, is that right?

[tsumare]

Yes, I figured that multi-instance would be far more possible. I'm quite happy with the --profile solution. I can simply create different shortcuts to launch my different profiles. The only issue I see is that there is in fact a check of some sort to prevent opening multiple instances (which is not done in dev mode -- I seem to remember being able to run multiple dev mode instances). Splitting that check up properly so it's bound to the profile dir rather than just the application itself should solve the whole thing.

I like your icon idea. Perhaps even a setting for icon color at some point. (I think there's some kind of theme system already, which manual overrides might fit into?)

I don't think there's anything else required that you haven't already listed.

I would definitely appreciate the ability to easily use multiple profiles at once, so thank you very much for taking the time to look into this.

[tessus]

@laurent22 yes, you almost remember correctly. But it's just the first part. This helps with the desktop app, but not with mobile.
The next step is to add a UI option to switch profiles. The hardest part of this is to reset all the states to zero (as if the app was not running), but the rest should be fairly easy..

For the desktop app a memory lock would do the trick. Unfortunately shared memory is not available for nodejs thus we have a problem.
The only thing I could find is https://www.npmjs.com/package/mmap-object, although I haven't checked if we could really use it. It might be easier to write a new module that uses shm_open instead of mmap. (Scratch that, I have no idea how to do that on Windows. I can do it on macOS and Linux, but I am lost in the Windows area.)

[vsatmydynipnet]

Please do not use --profile. Let users create more then one sync target inside the software and assing sync target to the notebook holding notes and todos. Assing a color to the sync target and the displayed data out of it.

[laurent22]

@tessus, right it's true that the mobile app also needs to be supported. There's a package to restart a RN app so maybe we could use that: https://www.npmjs.com/package/react-native-restart Internally it would be best if it still works the same with the app pointing to one folder or another.

[tessus]

@laurent22

Internally it would be best if it still works the same with the app pointing to one folder or another.

right, the question is, how do we handle that?
e.g. if we had a structure like so:

.config/joplin(-desktop)/
    profile1/
    profile2/

we could scan the one parent directory to retrieve all profile names and present them in the UI.

@vsatmydynipnet as you have seen from previous comments, this would be very complicated to implement. Joplin was not designed to do that, so making this possible would mean a major rewrite and refactoring of the code. I doubt that anyone (I'm pretty sure that would have to be Laurent though) has the time to do that.

[tessus]

@laurent22 Even something like .config/joplin(-desktop)/profile1/profile.name could be used as meta data file for retrieving the profile name. The structure I suggested is only necessary to scan recursively, otherwise we'd need some array with profile directories (and the question is who fills that array? the user via a setting?)

[tsumare]

@tessus Something like what Firefox does with its profiles.ini would work nicely. Joplin can add any new profile the user creates or specifies to some json or similar file, perhaps even with its path, if I want to put it somewhere special as an advanced user. This method works for both simple and advanced users.

@laurent22 There are certainly a lot of potentially useful features here, but rather than getting too bogged down in them, I would suggest as a first step, to simply make --profile work correctly. Everything else is dependent on this functionality anyway, and it would allow us to make use of the feature right away while everything else is nailed down.

[archtur]

Swiching profiles

To switch profile, save a value to Setting table called "next_profile_id", then close and restart the app. When the app starts it loads "profile.ini", then checks the value of "next_profile_id", and uses that to choose and load the right profile.

Locking per profile

Could you implement it in a way, that in the "switch" menu you can choose to

• "load the profile in current Joplin instance"
• "load profile in new Joplin instance"
  ?

This would be very nice and would solve most of the questions about multiple instances / multiple sync targets etc.
From my very top level view, this should be possible, because you have to implement the per-profile-locking anyway.

What is your opinion laurent?

[alexwyl]

I also need this feature. I think there are two ways to implement it, both have been mentioned above.

1. Each notebook can have different sysc target, eg., "Personal" to dropbox, "Work" to nextcloud, just like a e-mail client can have multiple accounts at the same time. looks like multiple tree-root nodes in the left bar.
2. Multiple sysc profile, people can switch porfile while app is running, only one tree-root node shows in the left bar based by the profile.
   Sorry for my poor En.
   Thanks.

[vsatmydynipnet]

Please lets create different sync targets, set a default target and assign notebooks to sync targets. That way one can have all of his notes, private, company, charity, whatever in one display. Thank you.