yeah I will - but thats only a solution for me 
what about Emiliy B. from A.?
you mean like dns?
Look, this is getting tedious and I’m checking out for the night. So, I’m implementing discovery over tls. I’ll look at adding a server or two, that doesn’t hurt. I’m not going to implement a DHT discovery, because I don’t see the point and i don’t understand it well enough. If someone else does and contributes it, and it’s provably superior in some way, I’ll happily merge it and use it.
I think that’s all on this topic from me for the moment.
I am back with my Private vs Public discosrv questions. I think a graphic will explain my issue, so here goes:
In the illustration above, devices A,B,C share some “top secret” stuff using a Private discosrv. Device C (that’s me) adds a 2nd discosrv (public), and shares some family photos with devices D and E. Everything works, and devices A and B can never discover D and E and vice-versa.
In the diagram below, the owner of device A (not me) later decides to add a 2nd discosrv (public) and share some music files with his friend F.
Now my question: Since both devices C and A are configured to use 2 discosrv’s (1 private + 1 public) … is it possible to configure so that the discovery between A-C continues via the Private discovery server only?
The way it is now (and that’s the way I’d like it to stay) is that it will look for everyone everywhere, concurrently.
So in the first case, C will look for A, B, E, D on both public and private disco, but obviously will only find them on the ones they are participating on. So the public disco will get a request for C looking for A but not get a response. Again, A’s ID is just a hash of some random piece of information, so you can’t pin it to anyone.
In the second case, same case will happen, though through which server C will resolve A will depend on latency and gods of random numbers.
This might not be exactly the way I wish it could be - but now I fully understand the way it is now.
Thanks for walking me thru this … 
like calmh said, syncthing is for you syncing files with people you trust, if you don’t trust discosrv, then don’t use any discosrv, you don’t require a discosrv for connection, I tested it.
my 80+ computers running on both public and private network, and even with a discosrv running on a computer that connects with both network they just can’t communicate with each other, if you worry about your IP being transfer to malicious place, secure your own connection.
While I’m an avid advocate of privacy and anonymity, I don’ think syncthing is or should be designed to be used as a tool to sync files in perfect anonymity.
That is because it’s incredibly difficult to reach at least ok anonymity as you can see with all the bugs the TOR project has to fix. Most of those problems are with hidden services, because those have to be accessible from a fixed address/ID over a long time. Which is basically the same requirement we have when we want to find other ST devices. If even a project with several million dollars in funding and many highly skilled coders with experience in anonymity projects can’t reliably make this work, its impossible for us.
Oh and if your threat model includes an adversary with global passive listening skills (as it should for perfect anonymity, but even the TOR Project doesn’t do this), you have to protect agains traffic correllation attacks like Adam Langleys Pond. This might be kinda usable for the messaging usecase Pond has. But you’ll never be able to get any usable transfer speeds for file sync. At least not if you want normal people to use it, because Dropbox will always be several orders of magnitude faster than any truly anonymous file sync/sharing tool.
Because of all those problems the usecase of anonymous file sync can only ever be appropriately addressed by tools based on anonymity networks like I2P, GnuNet and partly TOR.
That’s why a DHT or a blockchain-based discovery would be nice in the long run. But building either with the privacy and usability on mobile devices provided by the current and especially the upcoming 0.12 release is next to impossible.
DHTs aren’t easily encrypted because of the way they work. Blockchain-based technology could fix the problem that the social graph of our devices is exposed, because everybody downloads EVERY IP-ID pairing and just uses the ones it’s looking for. It can’t fix the fact that hash-IP pairs are publicly accessible.
But downloading a huge blockchain and staying connected to a swarm is not viable on mobile devices because their storage and energy resources are rather limited.
There are things like “light” clients but they generally just trust the answer of a node with the whole blockchain. Light clients using snapshots of trusted points of time in a blockchain could also work but are still experimental.
If you are interested in those blockchain-based solutions, you should take a look at DNSChain by okTurtles.
But to be honest, I think Syncthing has bigger fish to fry at this point like selective sync and diff-based index exchanges.
As soon as the cost of hosting the discovery server(s) gets too high or ST gets popular enough to be attacked via DDOSing them, we can take another look at those options.
As for the anonymity requirement, this is basically impossible to do on our budget of financial, community and developer resources. And because the government can easily surveil everything connected to your official identity you would have to use a near-perfect anonymity network. Which brings us back to the first point.
The blockchain-based solution I described above would fix this, but it’s A LOT of work and I’d consider this technology to still be experimental.
For the TLS discovery in v0.12, I’ve setup three geographically redundant discovery servers - Sweden, the US and Singapore. Each is reachable on IPv4 and IPv6. So to take out global discovery, you now need to DDoS three separate servers on three continents, which is at least a little more work. Things will keep working as long as least one of them is not dead.
4 Likes
great news for the sunday 
I also spoke to a friend of mine whis working at a german hosting company… maybe they will sponsor a disco server for the community 
No need, to be honest, as they are very small and simple to host. My instances above are the cheapest $5 instances from Digital Ocean. However if they want to help host a relay server that would be awesome.
(It supports total and per-session rate limits, so can be made to behave. I’ll have a document on this up by the time 0.12 goes live.)
1 Like
I could ask them for that too when .12 has been released
btw: I would like to tell them the specifications that are needed to run a relay smoothly. are there some experiences?
I recently have created a PKGBUILD for arch linux. It is almost ready, I just have to
- add a install script which creates the appropriate user
- finish the systemd service files.
But you can run it now in, for instance tmux under your user of choice.
1 Like
I mean CPU, RAm etc…
It doesn’t need any of that, it’s just reading packets and sending packets, so anything should work
1 Like
Wondering if Digital Ocean may want to sponsor a few instances.
Well that is false.
Knowing which ips connect to which ips is quite bit a knowledge by itself.
This has already been discussed at length earlier in the thread, including this exact point.
The conclusion was that we can’t avoid discovery servers gaining this knowledge without going to a blockchain-like setup (where everyone can see ID<->IP mappings for everyone else, so hiding who’s looking for who), which has significant complications and other downsides. The conclusion being: if you’re concerned about this, don’t use a discovery server run by someone you don’t trust (i.e. don’t use the ones hosted by @Eddy2909).
1 Like
@canton7 such a post is not much qualified and sad 
even if this will bring up a fundamental diskussion:
why should I am less trustworthy than someone other? (and btw: your ids & ips don’t interest me at all)