Sync Sharing

Use case or problem

Now that Sync is basically working for multiple devices (mobile + workstation), we should extend it to add support for inviting other people to share Vault syncs.

This is a big need for us, as we individually use Obsidian for personal Vaults, but we have common knowledge we wish to share amongst our team.

Proposed solution

Syncs are already passphrase-encrypted. It’s not ideal, but given the current setup, sharing that passphrase is an acceptable solution. Both of these require (and I presume the existence of) unique IDs for syncs and users.

Given my lack of knowledge on how the Sync service is implemented, I can only speculate on solutions, but I see two obvious approaches:

Pure client-side sharing

The Server doesn’t care about sync access: so long as the client has the Sync ID, it can access the Sync.

The upshot is simplicity. The downshot is security:

  • single layer of access security; just two pieces of knowledge (no second factor)
  • in case of a breach, there is no way to re-secure the Sync

Server-mediated sharing

  1. Users declare other Users from whom they will accept Sync offers
  2. Users declare other Users to whom they wish to share a given Vault (or set of Vaults)

This is, then, a double opt-in, server-moderated sharing system. Sync passphrases must still be shared out-of-band, but this adds a server-mediated revokability and finer-grained control, as well as something of a second factor. The down side is that it involves much more UI complexity and Server-side facility.

This double opt-in model is mostly the same as what Syncthing currently uses. In particular, I do not think we should facilitate unsolicited share offers: that is a SPAM-inviting anti-pattern.

Current workaround (optional)

Currently, we use Syncthing to manage this, but that is an additional tool which should not be necessary with the Sync feature. Obviously there are myriad other external solutions (Dropbox, Drive, etc), but nothing beats the simplicity of having in-app support for this.

1 Like

In truth, there is nothing particularly necessary about the Server-side solution which actually mandates a Server-side mediation. All of that can be done on the client side… and indeed, that is exactly what Syncthing does. However, that presumes a kind of peer-to-peer communications channel which may not presently exist, which is why I present it as a server-side implementation. It is certainly better to implement it in a completely distributed fashion.

Mightn’t this run into the Sync limit on the number of remote vaults?