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_STAT`
> that 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]]
