Hacker News Reader

Comment by okket | Hacker News Reader

This is the price you have to pay for a (secure) decentralised system, but syncthing tries to help where it can. E.g. you can set a syncthing instance as an 'introducer', so you only have to establish a connection to this device to get offered connections to all others devices. You still need to authorise these introductions on the devices, but you do not need to type in the crypto verification strings.

View on HN

This is the price you have to pay for a (secure) decentralised system, but syncthing tries to help where it can.

In general, Resilio Sync's 'key per folder' model seems to work better. I can give a key to other people and they can join the swarm without extra work on either sides. Also, it has a logical extension to encrypted-only peers: they get a derived key that can be used to sync in the swarm, but cannot decrypt the data.

If there was a stable open source program using Resilio Sync's sharing model, I would switch in a heartbeat. (There is Librevault, but it still seems to be mostly in development.)

Where can I read about the swarm capability? I'm searching for something like how BTSync worked, but I don't see how Syncthing does this. It seems like one to one sharing, per: https://forum.syncthing.net/t/can-i-use-synthing-to-distribu...

Yeah, the only problem is you can never "un-give" a key, which means you either have to rebuild your cluster under a different key (having to re-give key to everyone else apart from that one guy you want to kick out), or deal with the person having access to the data forever.

Indeed, with the standard folders you cannot do this. With the identity-based sharing, you can remove someone from a folder. The identity-based sharing model has some downsides (no support for encrypted read-only peers), but does support user management.

If the data is encrypted using a session key and then the session key encrypted with a master key and stored with the data (concat them together) then it can. You can't revoke access to the data they've already got, of course, but as changes/additions are made they lose the ability to decrypt the new data because you've used a new session and master key.

Arq uses this method when encrypting blobs.

The model has been considered for Syncthing many times, but it boils down to the fact that:

1) There's no way to revoke access, and 2) Once the secret is out, it's out: you have to scrap it and start again from scratch.

What is the problem with that?

You can always close the folder and start a new one.

That's how I do it. My use case is a large number of nodes (>200) need read-only access to data I provide from my node. So my node is set as "introducer" and gives the host list to everyone joining the swarm.

Reply on news.ycombinator.com