Yeah, I think multiplexing commands and data was probably not as well solved a problem as it is now.

Having worked with ssh/scp/sftp, I think sftp could be better too, and therefore more useful.

It's intimately entwined with ssh, which means that instead of just transferring files, you have to give out ssh permissions where they're not required.

Really, there should be an sftp client and server, strictly dealing with files.

- You could have "accounts" that weren't real users on the machine

- You wouldn't have to deal with users and shells and groups and permissions

- You wouldn't have users running commands on your machine

- You could have read-only sftp (sort of a repository with access controls)

- You could have write-only sftp (sort of a dropbox)

- You could make these formal, with daemons like read-only-sftpd or write-only-sftpd that were securely purposed to prevent unexpected file operations.

"SFTP is though (poorly named, it is based on SSH rather than the FTP protocol), but no web browser that I know of supports SFTP."

For a time I was using Konqueror with fish:// URLs as a SFTP browser and it worked very well and made me happy ...

I am not sure if that workflow still works but most rsync.net customers that I interact with are using sshfs on top of FUSE and mounting ssh resources as a local filesystem - so no browser involved.

Yeah. Even though I remember a lot of the reasons for FTPs weirdness back then, looking at it below the cover today, it's a similar feeling as operating a mechanic calculating machine. Interesting, weird, with unfamiliar concepts, but you wouldn't do it like that anymore.