One thing that bothers me about #Syncthing GUIs like Syncthing Tray is that none of them seem to be aware that you can connect to Syncthing over a Unix socket.
There would be serious security benefits to configuring Syncthing to allow access only by Unix socket, but I can't do that if none of the GUIs support it…
On a related note, why the actual hell does no #browser support HTTP over Unix socket? That would be SO USEFUL.
A hosts file containing a table of socket paths? Why?! That sounds horrible, especially if only root can add things to it.
I was thinking of having the socket path in the URL, like how Java/Firefox's jar URLs work.
@argv_minus_one the user controls the table, but a system-wide config can exist, with user defined entries having precedence.
The rationale is to be able to name services without having to care about the path in the FS, while following the URL spec. Typing http://rss.unix is easier than the whole path to the UNIX socket. I probably should add my reasoning in the document.
Other protocols apart from UNIX sockets could be used as well, as long as they specify a bidirectional channel.
Hmm. I guess I see your point, but I'm not a fan of indirections over the file system like this.
Idea: instead of a text file as described in your spec, what about folders full of symlinks pointing to sockets? Meaning, to resolve `foo.unix`, it will try to open a socket at /run/user/$UID/unix.hosts/foo, ~/.config/unix.hosts/foo, /run/unix.hosts/foo, /etc/unix.hosts/foo, and so on.
This also prevents a race between multiple apps writing to unix.hosts, which you know they will. 
@argv_minus_one yes, this is one of the things I left opened to future extensions:
> If no entry is found on the unix.hosts file for a given .unix host a default set of locations for the UNIX socket could be attempted, but this is left out of the current proposal.
I'm also worried about the side effects of the indirection, but until I test it for a few months I won't be able to say how bad it is in practice. In my case won't expect to change the unix host file too frequently.
Then you're making a serious mistake.
If there's more than one process that listens on an HTTP-over-Unix socket, and they both start up with your desktop session, then they will both write to unix.hosts. That's a race condition. unix.hosts *will* get clobbered on occasion.
At the very least, the spec must mandate which file locking API to use when reading or writing unix.hosts, but why go to the trouble when symlinks are inherently atomic?
And please keep in mind the adage that there's nothing more permanent than a temporary solution, especially in protocols between separately-developed programs. It's a lot easier to get it right the first time than to convince everyone to switch over to unix.hosts version 2.
@argv_minus_one there is no intention from programs to modify unix.hosts, in the same way they don't usually edit /etc/hosts.
You essentially choose a shorter and frindly name for a given UNIX socket path and type it in the unix.hosts file yourself.
Programs keep using their socket path, probably under ~/.config/app/sock or similar.
If programs aren't allowed to add themselves to unix.hosts, then it will be far less useful.
People using Syncthing aren't going to want to edit some textual configuration file in the process of setting it up. It needs to Just Work, as it does now with TCP. A unix.hosts file that can only be hand-edited does not Just Work.
/etc/hosts is generally considered useless, by the way. It was replaced long ago by something that Just Works, namely DNS.
> People using Syncthing aren't going to want to edit some textual configuration file in the process of setting it up.
This is a different problem that is not addressed by the RFC. My comment was referring to:
> why the actual hell does no browser support HTTP over Unix socket?
The unix.hosts file only assigns a name to a socket path, so it is easy to open in a browser while reusing the same URL parser for http URLs, nothing else.
Typing arcane incantations into an obscure textual configuration file inside a hidden folder is not what I would call easy. I can do it, but your average user can't.