I think we’re going in circles here. I didn’t “side-channel an update mechanism”. The official Syncthing has a built-in update mechanism and is capable of updating itself. It has an API that instructs it to update. That’s what I use. I disallow Syncthing from detecting and displaying that updates are available. But when it’s own update feed indicates that an upgrade is available, I use the primary update channel.
I hope that clarifies things. If you have further questions, concerns, or suggestions about Syncthing’s hardening, I encourage you to contact me directly. I agree with your assertion that we need to take privacy and security seriously for a wide variety of reasons. I’ve attempted to do so with Syncthing Menu in design, implementation, transparency, build chain (inclusive of tooling, signing, notarization and transparent chain of trust).
I think both approaches make sense for different priorities. Bundling the daemon gives tighter version control and makes support easier, while allowing Syncthing to update independently avoids the wrapper becoming the bottleneck for new releases.
The interesting part is probably finding a middle ground: keep the app decoupled, but detect API incompatibilities early and warn or temporarily block an unsupported Syncthing version. That would preserve faster updates without giving up too much robustness.
The Syncthing REST API is well documented (REST API — Syncthing documentation) but is subject to change. Syncthing Menu, and a reasonably large number of other apps and utilities, depend on the API and I believe the Syncthing team takes this into consideration when evolving it.
Unexpected API changes could certainly theoretically break Syncthing Menu (and many other apps and utilities). I’ve done my best to mitigate the consequences of breaking changes but there’s always a chance that I missed something.
I’ll give a bit of info at the end of this message but, realistically, the risk here is quite small. Syncthing Menu is just a simple control menu + activity view on top of Syncthing. It does not set up devices or folders or modify Syncthing prefs. It’s just a view app. It can’t and won’t cause data loss or other serious problems.
Syncthing Menu gives the user control over update detection and installation for both Syncthing and Syncthing Menu. By default, updates are detected but not automatically installed. A conservative user can leave those settings in place, wait a few days after an update for either becomes available to see if the community has found issues and, if not, install the update.
A few details:
I’ve used Claude to model API break scenarios. I’ve done this fairly exhaustively
There are no identified cases where an API breakage can cause the app to abort or exit unexepectedly
I use a number of APIs for detecting sync status and activity. If these APIs change in a way that breaks (which means the current documentation is invalidated), some combination of no activity being detected or incorrect activity being detected will occur. The menu icon may not be accurate, the activity window may be inaccurate, or an error icon or string may be displayed in the menu, activity, or settings. In these cases, Syncthing continues to run just fine though an update to Syncthing menu will be required.
Process spawning and managing should work just fine though if Syncthing really breaks input params, something unidentified could break. I’m going to just trust that they aren’t going to break this so badly that everything anywhere breaks. The people working in this area are hypersmart.
Syncthing updates might break. I’ve modeled this with an eye towards understanding if anything in this area can break the Syncthing Menu update path. The model holds in the sense that Syncthing updates might be broken but Syncthing Menu updates would work. An update to Syncthing Menu would be required
In the great scheme of things, the risk here is very low. I don’t mean the risk of something breaking, I mean the real risk of data loss or something like that. It’s also worth noting that Syncthing Menu wouldn’t be close to the only thing to break.
I’d like to request that we allow this thread to be used for the purpose of having actual users give feedback on the app. I’ve now been using it for weeks and across multiple Syncthing updates. It’s working really well and I personally am quite pleased with the UX.
I’m close to promoting it out of pre-release and plan to do so soon.