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.