You do need something you are talking about when there is a centralized place which you do not own and where the files are stored because that’s the only way you can access the files.
I don’t see where syncthing fits in. I don’t think it’s in syncthings nature to provide file access.
If you are running on the same machine, you can access the files already, if you are on a remote machine, you can run a web server or any other system to get access to the files, I don’t see why we should bolt something on top of syncthing, when there are plenty of alternatives around that you can use (for example ownCloud).
It’s possible that I’m wrong, but I always thought Syncthing aimed to be a (more decentralized) alternative to ownCloud and DropBox.
Doesn’t it make sense to allow applications to implement Syncthing support so that they can store certain files using Syncthing? It doesn’t matter if you use a remote instance that has remote viewing enabled or a local instance that hosts its API on localhost.
Consider the following situation:
I use Syncthing to sync my laptop with my desktop. However, as an extra, I also sync my personal home server with it.
Allowing API file access would allow for the following interesting features:
Whenever I’m not on my desktop or laptop, I can access files using the public GUI on the address of my home server.
On my smartphone, I have an app that allows me to export content to cloud storage (like usage stats on RunKeeper). In addition to Dropbox and Drive, it allows me to save to Syncthing given the address of the instance and my credentials.
The use case above can also happen when using a web app in a browser. When I’m on my laptop, I won’t even have to enter the instance address, because the web app can automatically detect Syncthing by checking localhost for port 8384.
In your reaction above and your reaction here, you suggest to “just run a web server”. Valid alternative, but why should I build the webserver myself if supporting it from Syncthing itself (which already acts as a web server) only requires two extra API endpoints to be provided?
I can kind of see the utility. However I also think it’s a rabbit hole, feature wise. Like, if we expose files over HTTP, we should probably have authentication, right? And rate limiting? MIME type detection? Download quotas? One time access tokens? Image gallery generators? Video streaming plugins…? SOAP? Where do we draw the line? Is this still Syncthing we’re talking about, or something else?
On the flip side, you have things like Freehold, which I haven’t tested at all but looks like it might fullfil the initial requirements, even includes some sort of upload/sync client of it’s own (!) and is also just a single binary to download and run.
Freehold is a webserver that you can host on anything from a multi-core VPS to a Rasberry Pi. Running the webserver is as simple as starting starting up the freehold executable.
Once running the freehold instance exposes a simple REST API for uploading files and managing them. There is also a built-in datastore API that allows for storing any other type of data you need.
I’d like to chime-in. I have created a few Firefox extensions/userscripts and I’d love to be able to sync their data using Syncthing. Firefox sync has data size limits and uploads your data to a server you do not control.
This isn’t quite true as browser extensions can’t typically access the file system.
Couldn’t the api key of the exist api be reused for file access? For my use case I’d only need CRUD access and it’s also were one might draw the line. For serving files with rate limiting and whatnot, one could use Nginx, Jellyfin or whatever other application might better fit their needs.
PS: Freehold doesn’t seem to be available anymore.