design for a git-annex-shell

doc/bugs/wishlist:_support_for_more_ssh_urls_.mdwn

@@ -16,5 +16,5 @@ Specifically, if I have ~/bar set up on host foo:
 > are somewhat tricky to support as they require running
 > code on the remote to lookup homedirs. If git-annex grows a
 > `git annex shell` that is run on the remote side
-> (something I am considering for other reasons), it
+> (something I am [[considering|todo/git-annex-shell]] for other reasons), it
 > could handle the expansions there. --[[Joey]] 

doc/todo/git-annex-shell.mdwn

@@ -0,0 +1,42 @@
+I've been considering adding a `git-annex-shell` command. This would
+be similar to `git-shell` (and in fact would pass unknown commands off to
+`git-shell`).
+
+## Reasons
+
+* Allows locking down an account to only be able to use git-annex (and
+  git).
+* Avoids needing to construct complex shell commands to run on the remote
+  system. (Mostly already avoided by the plumbing level commands.)
+* Could possibly allow multiple things to be done with one ssh connection
+  in future.
+* Allows expanding `~` and `~user` in repopath on the remote system.
+
+## Design
+
+`git-annex-shell -c <command> <repopath> <arguments>`
+
+### options
+
+Need at least `--quiet`, `--backend`, `--key`, `--force`
+
+### commands
+
+* `configlist repopath`
+
+  Returns `git config --list`, for use by `tryGitConfigRead`.
+  
+  May filter the listed config to only the options git-annex really needs,
+  to prevent info disclosure.
+
+* `inannex repopath key ...`
+
+  Checks if the keys are in the annex; shell exits zero if so.
+
+* `dropkey repopath key ... `
+
+  Same as `git annex dropkey`, and taking the same dashed options.
+
+* `setkey repopath tmpfile`
+
+  Same as `git annex setkey`, and taking the same dashed options.