I think number 1!
1 and 2 concern basic functionality, 3 not essential.
2 seems good, 1 could be the real difference between version 0.8 and 0.9.
It’s a great thing that software goes on with a project design, and it’s beautiful that the project goes on in collaboration with users!
Thank you and good work!
The most important thing to do, in my opinion, is to make setup easy, because if that’s annoying or complex then it doesn’t matter whether the rest of the system works perfectly However, I’m not sure what’s being planned for that: it’s hard because you have to set up the connection at both ends, and that’s not going to change because the security of the system is critically reliant on it.
So I vote for number 2, less fragile local discovery, since it affects me, and I think that without it, syncing doesn’t work…
This is true. Then again the things do tie together a bit; with better hole punching and discovery, setup does get easier. Or it can be made easier at least.
But initial connection setup could still be made better even while retaining security. A mismatch would not need to be fatal for example - the missing side could configure the missing repository but mark it as inactive/temporary/provisionary/something and let the user enable it if desired, for example.
I think 1. Everyone I’ve introduced syncthing to loves it, but I have to point out that you need a server on the net somewhere. Unless the person has control (either via upnp or otherwise) over their home firewall or their own server on the net, they can’t use syncthing
The setup thing (3) could use some polish, but the key underlying functionality of the application resides in 1 and 2: if people struggle with that, then–even if they have configured everything properly–that is a fail.
Also, once you get the hang of how the config files work, setup is actually pretty painless. It is certainly just as straightforward, if not more so, than BT Sync.
Any effort that goes into making the actual synching much more solid: predictable, reliable and consistent, really delivers exactly what people who use these types of tools are looking for.
I think you have done an awesome job getting this thing going as well as it does now. 0.9 will be welcomed whatever you decide to include in it. Thanks for a great app.
#1 for me. As almost everybody has a firewall and in most cases has no idea how to configure it and/or can’t.
UDP based protocol that will allow to connect 2 peers w/o opening a port would be amazing. But ideas used in ngrok, which is equivalent to have an external relay host, might be a comprise. I don’t know which one is easier.
#3 would be interesting. But not yet a priority for me now.
Thanks. Much appreciated that you are asking for users opinion.
This would for sure be easier, bordering on trivial. The downside is that it would consume a serious amount of bandwidth for the poor sod running the relay.
That can be solved by either throwing money and resources on it (probably not going to happen) or distributing the problem on other people (using publicly reachable syncthing instances as relays). I don’t want to do the latter either - if you set up a syncthing cluster, it should be private to you. In fact, I’m skeptic toward any relay solution that’s not obviously secure against MITM attacks.
There are nice transport-over-UDP solutions out there though. uTP is the obvious one, but there are downsides to using that. UDT seems nice, if somewhat complex. Given that we’ll need to reimplement the protocol in Go (I haven’t found any existing implementations) simpler would be better…
I’d like to be able to run my own “syncthing router” host, it would avoid having a copy of the data on disk out there on the net. It might keep a lot of the people asking for encryption content. The router should only allow connections from my own nodes though.
Well, not true. Here in Greece ISPs have started giving out ZTE ADSL CPEs (108L, 108NS, Lantiq-chipset) to customers and those have UPNP disabled by default. I’ve also had trouble connecting home from our Metro’s WiFi network.
v0.9 has slipped a bit and is going to have a slightly different focus, however please note that point number 2 (less fragile local discovery) has been addressed during v0.8 - I haven’t seen any issues on that in a long time. Point number 3 (easier setup) still has some ways to go, but has also seen a bunch of work during the v0.8 branch.
A UDP based protocol remains for the future, and I do think it’s an important area for work.