A sftp special remote would be nice because gpg operations could be pipelined to the network transfer, not requiring the creation of a full file to disk with gpg before the network transmission, as it happens with the rsync special remote.
That's assuming a sftp library; the sftp command wouldn't support that. http://hackage.haskell.org/package/libssh2 has support for sftp, using the C libssh2. However, it does not integrate with ssh-agent, and it has two different entry points for authentication with a ssh key and with a password, and this would leave git-annex to somehow decide which method to use, and somehow remembering the ssh password or prompting for it each time. That seems suboptimal.
Driving the sftp command is also suboptimal because there would be a trafeoff
between reusing a single sftp session, which would prevent sftp from
displaying progress (it doesn't when stdout is not a tty), and running sftp
repeatedly (though ssh connection caching helps some with that).
Another reason to build this is that sftp has a
SFTP_FXP_STATthat can get disk free space information. "echo df | sftp user@host" exposes this, when available. Some sftp servers can be locked down so that the user can't run git-annex on them, so that could be the only way to get diskreserve working for such a remote. --Joey
I'd really welcome an sftp special remote because SFTP it is the only officially allowed way for our institution to exchange data with external collaborators and I had no luck using the gvfs approach.
Even without an sftp special remote, it would be great to have some short walkthrough how to use SFTP with git-annex (if SFTP is currently actually possible with e.g. gvfs).