Feature Request: Improve workflow for subscribing to an existing sync target

(avoid manual forced local repo creation + validate encryption key before sync)

Summary

When connecting Joplin to an existing remote data repository, the current workflow forces the creation of a new local data repository first. This creates several usability and safety issues, especially around unwanted default notes, cleanup steps, and encryption key mismatches.

Current Behavior

To subscribe to an existing remote sync target:

  1. Joplin requires creating a new local data repository.

  2. This automatically generates several default “Welcome” notes.

  3. These notes must be manually deleted.

  4. Then they must be manually deleted again from the recycle bin.

  5. Only after this cleanup can I safely sync with the remote repository — otherwise Joplin will push these unwanted local notes to the remote and pollute it.

  6. If encryption is enabled, Joplin does *not* validate the encryption key before syncing.

  • This can result in remote and local data being encrypted with **different keys**, creating a very confusing and potentially destructive situation.

Problems Caused

  • Unnecessary clutter and manual cleanup every time I want to connect to an existing sync target.

  • Risk of accidentally pushing unwanted local data to the remote repository.

  • No pre‑sync validation of encryption keys, which can lead to:

  • Multiple encryption keys being applied to the same dataset.

  • Data becoming unreadable until keys are manually reconciled.

  • Confusing or unsafe sync states.

Requested Improvements

I propose adding a Subscribe to existing remote repository option that:

  1. Creates an empty local data store automatically
  • No welcome notes

  • No recycle bin clutter

  • No risk of pushing local junk to the remote

  1. Validates the encryption key BEFORE any sync occurs
  • If the key is invalid, Joplin should block the sync and notify the user

  • Only allow syncing once the local and remote encryption keys match

  1. Optionally disable syncing to an existing local (currently opened) repository
  • This would prevent accidental overwrites or corruption

  • Ensures that “subscribe” mode is always safe and read‑only until validated

1 Like