External sd cards should actually show up by default, no idea why they donāt.
And no need to use the web interface, just enable the advanced folder picker in settings.
Iām also a BTSync user, very possibly to soon be a non-BTSync user, and have a few questions I hope someone can help me with. Mostly these are feature/usage situations that I expect to encounter, or BTSync functionality I havenāt seen yet in my poking around this site.
1 - I have a Raspberry PI which I use as my āalways onā sync point. It syncs data to/from a disk attached to my router and accessed via Samba. There are two issues here: ā shared files will never be changed other than by Syncthing, so there is really no reason to rescan the disk at all, and I donāt want to keep it from spinning down. Sounds like I can set a long rescan interval and this will be OK? ā I currently have this set up as a āread onlyā share in BTSync, to prevent accidents (on the PI or router or whatever) from propagating to my other devices. Is there a similar āread only shareā concept in Syncthing? (āencrypted read onlyā shares is another nice feature to allow people to āback upā each others sensitive files).
2- Iāve seen some discussions here about āselective downloadā or āsync on demandā ā I regard this as a VERY useful feature, particularly for my phone where I want access to all my music but donāt have enough local storage. It is nice to be able to download an album or two, delete them when done, redownload later, etc. Hopefully something like this that is easy to use can be implemented soon?
3- Is there some way to bypass the Syncthing central server? My PI has a fixed DNS name, and if everyone can find each other by finding it, that would be ideal.
That sounds like enough to get started. I think Iāll try Syncthing on a couple of machines this weekend and see how it goes.
Thanks!
(PS ā I keep running out of space in this composer window ā my text going off the bottom and I have to resize this browser pane. Is there some way to get a scroll bar here or is this intentional to keep posts short?)
1 Like
You can set it to 0, which means it will never be rescanned. Or use inotify if you want to avoid rescanning, but still want to have correctness.
There is a master folder approach, but that means that NOBODY can modify the files apart from the device syncthing is running on.
You can ignore files (ala .gitignore) but thatās a bit hard to use (as it is now).
You can run your own discovery server on the PI in that case, and just configure your devices to use that. Sadly, it now requires postgres (or you could probably compile a version which uses sqlite)
Thanks Nutomic - I found the option to turn on the advanced file explorer, solved that problem!
I saw inotify, and will check into that for my other machines. Hopefully the inotify behavior can be built in to syncthing directly for ease of use. But for the PI, 0 is probably fine, thanks.
Sounds like that will work for most of my needs, Iāll check it out.
I saw that discussion also ā Iām just hoping that a simple interface can be built for this capability. Sounds like some folks are talking about it, which is good.
Great! I have no need to do that right now, Iām just thinking long term. I donāt want to rely on this and then have syncthing shut down their discovery server and be stuck. As long as I CAN run my own, that is great, but I probably wonāt.
Thanks for the suggestions!
Knew they would be coming 2 months ago 
Automatic node discovery like Bittorrent-Sync - #10 by Rewt0r
2 Likes
Guys, wake up, this is a huge opportunity for you if you want it!
Honestly, my impression is that I donāt think you guys are aspiring to be the answer, and you donāt care enough about providing a smooth Windows installation experience (neither nssm nor syncthingtray are good in their present state for the common user), an iOS client, or even an iOS-compatible source code license. IIRC even the android fork is hampered by the license. (Without anyone starting a competitor to SyncThing, I consider open sourcing the protocol a mere gimmick, albeit a nice one). Please correct me if Iām wrong. If you donāt care, you donāt care, and thatās fair enough. But please consider the opportunity that lies before you. Being a part of something big, money, helping mankind, technical satisfaction ā Iām not sure what might motivate potential contributors, but these are all possible.
I think it is tragic that neither BTSync nor SyncThing seems to be on the course of solving sync for everybody, but I hope whatever project comes next (or whatever new contributors join SyncThing or a fork of it) can learn from the shortsightedness of these two and finally get it right.
I started reading one thread on the BTSync forum and kept getting more upset as I was reading it until I wrote my own rant: http://forum.bittorrent.com/topic/34291-i-was-in-support-of-sync-20-right-up-till-they-broke-a-promise/page-7. There is a huge amount of savvy upset users who really feel trust was violated with BT Inc., and are jumping ship. I for one had half jumped to SyncThing, but now I will fully switch over and be sad at the uselessness of my iOS devices. It is like BTSync cultivated a userbase for SyncThing ā but are you ready? ā¦
Iāve pretty much fully jumped ship myself (and commented over there about how they should change their approach - on the same page as user T42).
Oddly, I jumped ship just yesterday, and already like SyncThing better than BTSync - it has similar limitations but I feel I have more control over it.
Still, ST does need some UI/UX love. Running as a process in a command prompt on Windows rather than a service is not good (though thereās a work around with Non-Sucking Service Manager). Also not great that the management interface is in a browser. A few other features/tweaks that it could use - like incorporate all config in the app interface for Android. But none of this needs to be altered immediately, but certainly a piece at a time.
Iām thinking money does come into play (some kind of payment system to the ST team) if we want to see consistent dev on it. As I commented over on the BTSync, some kind of split in free vs pay version that makes sense. Or as for donations (like kickstarter) where a certain amount gets you the pro version. Just not subscription - unless itās a small fee for the Discovery service in the āProā version, and you keep the ability to host-your-own Discovery server in the Free version.
I thought I read somewhere that Jakob initially didnāt intend SyncThing to be the primary focus of development, but rather the sync protocol itself, and he expected other devs to fork SyncThing or even develop other tools that utilized the protocol; SyncThing was intended as a proof-of-concept/demo.
Either way - nice work Devs, and thanks to everyone here for helping me get mine working.
1 Like
syncthing-android doesnāt have any problems with the license (I have no idea about iOS though).
Regarding Windows: Everyone in this project is contributing in their free time, and probably has enough to do already. If you want to see a certain feature, itās probably best to try and implement it yourself. Thatās how open source works 
Sorry, but this has filled my glass.
So first of all, you seem to have a negative vibe, telling people that they are not trying hard enough and they donāt care.
This is as far as I am concerned a hobby project, me (and I believe @calmh too) invest our own personal time working on this rather than spending time with our families.
I am not getting paid to do this, neither I feel that syncthing will become a business, hence I only do this to satisfy the crowdā¦ And then cowboys like you come along and start bossing and insulting peoples time and effort, which I think is under the assumption that this will make them work harder/invest more time.
To be honest, when I read posts from people like you, I just want to say:
Fuck it, why I am I even bothering with this if I have to read rants about not trying hard enough?
How about you actually tone down, and help us out PROVING that YOU CARE, instead of bitching/bossing people around?
You can participate in the iOS beta that someone is running. Someone has took the effort of reimplementing the protocol to have a iOS client. For now it seems to be free, but not sure if it will stay that way in the future.
6 Likes
Try syncthing-gtk, it wraps everything very nicely.
Iām sorry, @AudriusButkevicius, I donāt want to put down the work SyncThing people are doing. I think it has been great! I think it is the most compelling option, and it is why I have been promoting it in multiple non-SyncThing forums in the last day, and it is why I have been migrating to it. I plan to switch multiple family members over to it from BT Sync. You guys are rock stars, in my and many othersā books sitting for a while at #2, but are now #1 on the charts! It is quite a feat.
It is a blow to the sync landscape to have BT Sync shoot themselves in the foot in remarkable fashion, and I am lamenting that member(s) of the SyncThing community in the past have, according to my perhaps faulty memory, expressed the attitude that
1. it is not seen as a big deal to not have an iOS client -- (correct me if I am wrong! I am probing here) or
2. contentment with how things are,
3. lack of desire to a) invest time, and b) make simple choices that turn ST into a big thing that can be good for the masses because it works for them for their purposes and that's all they care about and
4. 'we are afraid to make an iOS-friendly license because someone might take our code and profit from it, and so we would rather neither users nor developers profit from it'.
Note: 3b is a much bigger concern to me than 3a!!! I canāt fault anyone for 3a, and it doesnāt hold others back from contributing/forking. 3b does!
I just found a quote that spoke to 4 ā I could try to find quotes for the others but it would be better if everyone just clarified the their vision, rethinking things if necessary, since there are potentially myriads of potential users coming here to try to determine if this is a good investment for them as users (and possibly a few contributors ā I may contribute to a permissive licensed fork some day, or a windows wrapper, especially if iOS is in the mix.) This opportunity will not last very long. Now, it is totally and entirely up to you what license you choose to release your software as ā you have to do whatever benefits your personal goals the most ā it is just unfortunate from the perspective of me as a potential iOS user (and all the other ones) if the SyncThing community intentionally makes avoids choices that would make the availability of ubiquitous ST delayed or less likely. I question whether it is in the self-interest of the ST community, and I think they are fair questions to ask.
The big opportunity
BT Sync just triggered a HUGE mass exodus. It is a big deal! Stuff just got real! This isnāt time to tiptoe softly around peopleās feelings. When times become intense, I am intentionally provocative to get a response to figure out where people stand, especially because they themselves may not have thought through where they stand. Sometimes emotions are tools to get people to think things through. This is an enormous opportunity. It is a badge of honor to be the best game in town. I donāt know why you should be offended. Maybe there should be a poll on this forum so I could give @Audriusbutkevicius and @calmh and all contributors here a 10 out of 10 for awesomeness, so you could know how appreciated you are. But it is a cold hard fact of reality that my iOS devices are not usable in the SyncThing world, and that it is harder for my grandma to install ST on Windows and nerd out on NSSM than BTSync ā so what? It is a negative situation but that doesnāt mean anyone should take it personally that nobody has spent the time to improve these things to perfection.
I think it would be easier to have an iOS solution if there was a license to allow porting. (But I know the Go language makes it a technical challenge.) Honestly, I think the licensing turbulence here in the last 6 months has revealed a lack of ambition that potential new users from BT Sync like me may want to consider before placing all our hopes here, and potential contributors may want to weigh contributing to the culture here vs starting their own, with clearer ambitions and less emotional turbulence. As a user, it is a pain to have something crazy happen and reconfigure all of our syncāed folders using new software. I prefer to minimize how many times I have to do this since it is time consuming. As a developer, it is really painful to contribute to a movement only to have it shoot itself in the foot ā and at this point I donāt get warm fuzzies that I would be compatible as a developer with my personal way of seeing the world with SyncThing. (Although the BEP is a great starting point for a new project.)
On iOS and GPL:
There seems to be a preference to have neither users nor developers benefit on iOS rather than have someone potentially profit from an iOS app, and (IMHO) unwarranted fears of scamming, and that someone else couldnāt simply release a free version of ST for iOS and the market would route to the free version. Or if a hypothetical paid iOS version added value, that that wouldnāt be a good thing overall for BEP and ST in the long run.
I have been away for a couple months ā it is really cool someone is working on iOS. āSomeone has took the effort of reimplementing the protocol to have a iOS client.ā ā I canāt help but read this as āwe forced someone to reimplement from scratch on iOS, because, ___ā and I for the life of me canāt think of something that goes in the blank that makes sense.
I was not sure if the MIT android wrapper is licensed correctly, since it directly hosts the GPL library in a thread. Maybe that is not considered linking?? If that is GPL compatible, that is a new scenario to me! (http://stackoverflow.com/questions/3902754/mit-vs-gpl-license)
Even if the android wrapper is licensed correctly, a wrapper approach of GPL (or LGPL) on iOS and other similar app stores seems impossible due to the license chosen. If the desire is for the BEP protocol to succeed, I am not sure why there wouldnāt be a desire to have a strong, permissive reference implementation that anyone can use as a starting point on as many platforms as possible.
But again, it is entirely up to the contributors to prevent the possibilities with what people do with their Intellectual Property, if they want to preserve the possibility for themselves, or make the choice to permanently limit what can be done with the software because they see the potential abuses as greater than the potential benefit to all involved.
The trajectory of the community
Part of my provocativeness is also to try to get a feel for the sensitivities of the developers. If one guy like me can come in here and strut like a cowboy and dissuade people like you from continuing at all, I would say that being thin-skinned is a project risk, as a cold impersonal fact of reality. You guys may be rockstars, but rock bands sometimes self destruct (as with OSS projects and communities), I have sincere concerns that this developer community may be too emotional for long-term success, both in terms of stability in not making knee jerk reactions, and also in making objective decisions that are best for itself and for its community. I hope more people join the team who can bring wisdom and stability, and/or that current people can find it in themselves. I am trying to determine where I and others should be investing their time as users and potential contributors and what the risks are, and some of that includes the personalities and emotional nature of the people involved. The relationship with ind.ie blew up over pettiness, very needlessly in my not so humble opinion ā what additional blow-ups are in the works? What other synergies are going to be wasted? Who is going to start a permissive license alternative to SyncThing that has an easier path to ubiquity? I think these are important questions, and I am trying to figure out what the future holds based on currently available evidence.
Less than glowing opinions may be a tough thing to hear, and I tried to sugar coat it and mix it with positive feedback, but these are my honest opinions and I think this is a time for honest discussion. BT Sync has not released any open source, so you are already miles ahead of them. It is always a special thing whenever anyone creates and gives away free software, or free open source software.
Donāt take what I say personally. I hate seeing BT Sync shoot themselves down, and for ST I hate seeing needless tragedy in in OSS partnerships destroyed, large user segments and user scenarios being (possibly) needlessly unreached, and choices being made that (maybe) slow down the growth of ST. There is a huge difference between insulting your time and effort, versus questioning (and disliking) your choices and I hope you can see that, if only for your own emotional well being.
My bottom line for sync in general: I want a good (permissive) open source sync protocol and featureful software everywhere, ASAP, as in 8 years ago ā maybe SyncThing/BEP will be it, maybe an alternative OSS project that doesnāt exist yet is the most promising bet. A lot of ex-BT Sync users/potential developers are up in the air right now, so letās figure it out!! Exciting times! There is even a lot of potential people willing to spend money for a BT Sync product (that doesnāt exist, since they went for a bizarre subscription model), and people willing to donate ā as I said on the BT Sync forum, this is a large part of the recipe for a successful kickstarter campaign, even if the money goes to fund open source and not a commercial entity, or to start a business that has a open source/freemium model.
Bottom line for SyncThing What I want first and foremost for ST developers and community to think about what is truly best for them, and do it. You can never ask more of open source developers than that!! If I can help you guys figure out whatās best for you, I want to, even if it ends up not being a direction that is not compatible with me and others like me as an end-user or end-developer or contributor.
Hi, ex-BTSync user right here. You hit the nail on the head.
Here! Here!
Well put Jared.
And to the devs/contributors of ST, Iād like to re-iterate a couple points of Jareds:
-
We think you guys (gals?) have done a very commendable job creating a sync tool that already competes with BT.
-
Our questions/thoughts/concerns are in now way a criticism of this great work - weāre just trying to clarify whatās happening/what will be happening, and perhaps promote our own ideas/vision (or at least thought/discussion about the direction of ST).
-
Forums arenāt the best place for these kinds of discussions- sometimes our wording/writing isnāt ideal, and may come across as criticising rather than simply analytical.
Keep up the great work, know that itās appreciated, and that guys like me and jared would like to find some way for ST to take advantage of this sudden shift in the market - clarify the direction/vision, increase funding/monetizing opportunities, etc.
Iām no market analyst - perhaps thatās whatās needed, a Business Analyst who can speak authoritatively to how to proceed.
2 Likes
So I was going to reply about all the politics, but Iāll just try to summarize. Move from MIT to GPL was initiated by ind.ie, and everyone has agreed to that to help them. When ind.ie weeks later realized that GPL was no good for them (since they wanted to put something which has syncthing inside on the app store), there was a movement to switch syncthing back to MIT, but two license flips within a few weeks was I guess too much.
Now on the technical side: Given you currently cannot run Go binaries on iOS, I donāt see how Syncthing not being GPL helps iOS. The protocol implementation is already MIT, and thatās pretty much the core of what syncthing is, the rest is just some glue to make it all work. If a day comes where you can compile .soās with go and link against them, you will already have more than half of the implementation.
Even if the glue is GPL, you cannot enforce GPL on an algorithm, and given you cannot run Go on iOS, I donāt see what you are loosing out on, as you can still look at how the glue is implemented, and port it.
The reason someone has re-implemented things in iOS (if I am not mistaken) not because of the license, but because you couldnāt do anything with the code even if it was public domain.
I am not saying GPL is the right answer, nor do I have a strong preference. I do feel for the developers, and I do want people to build awesome stuff on top of syncthing, or more people to join making syncthing.
I do understand that your approach was to make people wake up, but you have to understand that we are under limited resources. I would love to spend more time on syncthing, perhaps even work on syncthing full time, but sadly my local supermarket does not accept github commit hashes as a currency. But to be honest, Iād rather you come and help us out, rather than trying to teach us or challenge us.
3 Likes
Yeah, this is part of why I donāt understand why there is a desire to stick with a decision (GPL) that even the initiator (ind.ie) realized was a bad idea. I have been trying to come to peace with the rationale / rational rationalization for staying GPL but I am struggling.
It looks like there is at least some effort to get Go on iOS.
I think the value of the glue, in the form of a working application, should not be underestimated. Instead of saying āhereās a fully functional app that many people have already tested, and use, and added some nice features toā, you are saying āhere is a protocol, go make a fully functional app.ā I think the barrier to getting started is order(s) of magnitude higher, especially as more nice features get added to ST.
You may have a point, and I may overestimate the value of ST, but perception matters, and if the flagship development of BEP is under a restrictive license then the perception is hurt in the minds of people like me.
I think you underestimate the power of copyright law, and the fear it invokes in people that they may building something that is in violation.
Check out the Mono contribution rules. Rule #1: āIf you have looked at Microsoftās proprietary implementation of .NET or their shared source code (which is also proprietary), you will not be able to contribute to Mono.ā If you even LOOK at the source which is licensed under a restrictive incompatible license, you are in danger of accidentally bringing over code that is too similar! I agree, algorithms arenāt covered, but copyright does cover implementation. [Note: Microsoft has seen the light and embraced permissive open source in the core of .NET, and used the permissive Apache 2.0 license, so the rule doesnāt apply to Mono anymore, but the principle for copyright law still does.]
Would the ST authors be impressed if someone took a tool to automatically port ST from Go into C++, and re-licensed into the public domain? (So they could turn around and use it and extend it in proprietary commercial projects and become billionaires.) I think they would be upset, and IANAL but I think they would have grounds to sue. And then someone could take the public domain C++ code, run it through a tool to get Go code that might very closely resemble the original source. Bam. Instant copyright nullification. But thatās not how the world works. Copyright law is stronger than that.
Whether an automated tool does this or a human being does (intentionally or accidentally), my understanding is this does not make much difference in a court of law. I for one would be afraid to look at the GPL glue, out of fear I would accidentally infringe, or be tempted to push the envelope.
If this were true (and I donāt think it is), why have the restrictions of the GPL at all in the first place?
I for one would google āGo trans-compilation and conversion toolsā to see if there was an easy way to port ST to iOS using another iOS language like c, objective-c, etc., or something that runs on iOS and everywhere else like C#. Or I would look at how many lines of code there were and see if it was a big task to port it by hand to my cross-platform language of choice. But because the license is GPL, the end result would have to be GPL, which makes it a non-starter for the App Store, plus many other potential uses I can envision for the software.
On a tangent: how many apps use Appleās iCloud to sync data? A lot. Why couldnāt SyncThing be used to help implement this on a cross-platform basis for apps? I think that would be a cool use case. I am interested in this possibility. But the GPL makes it a non-starter. It is nice the protocol is open source but when people have limited resources, it is nice to not have to start from nothing (or just a protocol) when building new functionality. Every little bit helpsā¦so why not help? There may be a good reason why the ST community would choose to be less helpful, but I just want to make sure it really exists.
I hope you guys maximize what you accomplish with those limited resources! We are at a point in tech history where this could snowball into something big if you play your cards right. The potential to attract more resources is here, right now.
[quote="AudriusButkevicius, post:28, topic:1937] I would love to spend more time on syncthing, perhaps even work on syncthing full time, but sadly my local supermarket does not accept github commit hashes as a currency.[/quote]
Someone should start a kickstarter, or a few, so ST devs or other devs can quit their jobs for a while and add some features. Iād consider it if I didnāt have other things Iām working on. Iām not loaded but I would chip in a little. Kickstarter campaigns can be a lot of work, so check out Backer, a crowdfund platform for software features, or Tilt.
Thanks for the invitation. I would appreciate the chance to be a part of a solution and it would be an honor to help on this great project. However, as you can guess by now, I canāt see myself ever contributing any significant time to a restrictive GPL sync project because I myself wouldnāt be able to make use of my own efforts on my iOS devices or as add-in functionality to my software.
Iām one of those BTS refugees. Imagine my happiness when I found you and Syncthing!
While Iām on linux and it just works, Iād try to help with the UX in general (Iām on that since 1994) and testing also the android version.
Anyway, thank you very much for the great spirit of ST. 
Bestā¦
ā e
2 Likes
As I mentioned earlier, Iām a BTS refugee too. First of Iāll, Iām really happy you folks have spent so much time building SyncThing. Thank you.
As an OS X and Windows user, I like what appears to be some upcoming features/additions. I do wish the inotify module was part of the core SyncThing, but maybe thatās on the way. It does have some issues with OS X and until that gets a little better Iām stuck syncing some smaller sets and living without it. But, those small sets have so far have worked perfectly. I canāt wait to see more.
But, the point is that I believe it will get there. I canāt wait to see more.
Please be aware that it is absolutely not a surprise to welcome a lot of former BTSync users here (I am one of them). I think everyone, including the SyncThing developers, were expecting that as soon as the version 1.4 was released and never really fixed. It was just a matter of time before Bittorrent completely shoots itself in the foot by releasing a free version with limited features.
From what I have seen, SyncThing is maintained by 2-3 developers who are working on the software on their free time. They donāt seem to do it for money, but because they like it, just like any hobby. Why would they invest time and energy to gather funds or include functionalities which will make the maintenance much more complicated? The goal here is not to be a challenger to BTSync, but an open source alternative. There is a huge difference.
Think about this comparison: imagine that your hobby is tuning/repairing your own car. You spend evenings and weekends doing that, alongside with a 9 to 5 job. One day, the professional car mechanic at the corner of the street closes down, leaving hundreds of customers helpless. You have two choices: take profit of this opportunity to take over the business in the area, or continue your hobby as nothing happened, and maybe give a hand to some people begging for help. SyncThing team seemed to choose the second option.
Keep in mind that this software is to be considered like a hobby, without any time or financial constraints (at least, that is my point of view). Donāt expect to see the developers start working on features upon requests. They will work on it if they are interested to do so, even though any code contribution is welcome. The advantage is that the software will tend to keep a constant quality; the drawback is that some requested features will never be developed.
To come back on your āyou would be pissed off if someone steals your idea and make millionsā, well, think about it with another perspective. Would you be pissed off if you refused to take over the professional car mechanic business and someone else did it and made millions? Would you be mad if someone starts to make money while you are only spending time on your hobby? If so, you are stupid.
2 Likes
@AudriusButkevicius and @calmh I know you said that you never wanted to accept any money to move the project forward but with the sudden influx of users (and I imagine you have a big swarm if you check your web statistics), wouldnāt you consider a Magic Backlog just like Robomongo (an open source Mongo client)?
Iām sure it would work well if it suits you.
2 Likes