I’m glad to do first announcement of my syncspirit, an alternative implementation of BEP protocol, gracefully shared by Syncthing developers. In simple words, it is Syncthing-compatible.
syncspirit is written from scratch in C++, so a lot of expected features found in syncthing missing. However, it is able to do one-side syncrhonization, i.e. it implements “receive-only” folder model at the moment.
Currenly only command-line intreface is available, so, it is targeted mostly to power users. The prebuild binaries for windows and linux are available for downloading, they are statically built, so no additional external dependencies should be required.
Why ss might be interesting for you? Well, it already has some unique features, like rsync-like mode (i.e. download files from peer and exit; it is implemented as “exit-on-inactivity-timeout”), and, it might have quite a good disk performance on HDDs since it tries hard to write sequentially. Also, the whole performance is tuneable (i.e. number of threads is manageable and configurable).
Any feedback is welcome. My short-term plan will be implement relay-transport.
I feel like this is not getting enough attention, so I wanted to take this chance to congratulate on this achievement.
Syncspirit could open doors for more client like applications, that just download a file or so, as opposed to the Syncthing application, that is more about continuous p2p.
That is something that this forum sees many questions about (especially for mobile devices) and is something the Syncthing application is not really designed for, which is why it is cumbersome to do.
A brief update about mobile devices: ss directly is not available for them, however indirecly you can build it via termux (can take about 30-50 mins, as c++ is heavily used), and yes, it does works. Yes, in termux console, which is quite uncomfortable on all mobiles w/o hardware keyboard.
Surely, I’m open for ideas/feature requests as long as they are BEP-compatible. Please, open corresponding issues in github (or other ss-mirrors).
And, of course, I’m open for contributions. However, the code itself is not “stable”, and it is subject for changes, so, it’s better to discuss/notify me about the planned changes to avoid code conflicts.
For example, I need MacOS-X console build (static lib), however, I don’t have access to that hardware/platform, so, if somebody help with that builds, I’ll ship the binaries with the next release.