diff options
| -rw-r--r-- | doc/design/assistant/telehash.mdwn | 28 |
1 files changed, 28 insertions, 0 deletions
diff --git a/doc/design/assistant/telehash.mdwn b/doc/design/assistant/telehash.mdwn index 9e1d6f613..01cbd1340 100644 --- a/doc/design/assistant/telehash.mdwn +++ b/doc/design/assistant/telehash.mdwn @@ -58,3 +58,31 @@ This might turn out to be easy to split off from git-annex, so `git pull` and `git push` can be used at the command line to access telehash remotes. Allows using general git entirely decentralized and with end-to-end encryption. + +## separate daemon? + +A `gathd` could contain all the telehash specific code, and git-annex +communicate with it via a local socket. + +Advantages: + +* `git annex sync` could also use the running daemon +* `git-remote-telehash` could use the running daemon +* c-telehash might end up linked to openssl, which has licence combination + problems with git-annex. A separate process not using git-annex's code + would avoid this. +* Allows the daemon to be written in some other language if necessary + (for example, if c-telehash development stalls and the nodejs version is + already usable) +* Potentially could be generalized to handle other similar protocols. + Or even the xmpp code moved into it. +* Security holes in telehash would not need to compromise the entire + git-annex. gathd could be sandboxed in one way or another. + +Disadvantages: + +* Adds a memcopy when large files are being transferred through telehash. + Unlikely to be a bottleneck. +* Adds some complexity. +* What IPC to use on Windows? Might have to make git-annex communicate + with it over its stdin/stdout there. |