From cac47364a6f3919561099046a90ff9159c58cdb9 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 12 Dec 2024 14:24:57 -0400 Subject: [PATCH] comment --- ..._57e4608559b0873617c82d5454cab798._comment | 45 +++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 doc/todo/generic_p2p_socket_transport/comment_2_57e4608559b0873617c82d5454cab798._comment diff --git a/doc/todo/generic_p2p_socket_transport/comment_2_57e4608559b0873617c82d5454cab798._comment b/doc/todo/generic_p2p_socket_transport/comment_2_57e4608559b0873617c82d5454cab798._comment new file mode 100644 index 0000000000..5c6307cb51 --- /dev/null +++ b/doc/todo/generic_p2p_socket_transport/comment_2_57e4608559b0873617c82d5454cab798._comment @@ -0,0 +1,45 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2024-12-12T17:01:42Z" + content=""" +This was all designed to be generalizable to some degree, but has so far +really only been used for tor. + +Making it generic may be a good idea. Or it may be that there are really +too many complications around how different p2p networks and addresses work +and how authentication is done, that would complicate a generic command, +but that can be transparently handled when implementing support for a +specific p2p transport, as was done for tor. + +Working from the client end, the git remote has an url, which needs to be +identified as a p2p address to use a p2p transport to talk to it. Currently +that is an url starting with "tor-annex:". Like you suggest, +the generic one could be "p2p-annex::". Or it could be +"p2p-annex::foo+" which causes git-annex to run a command like +`git-annex-p2p-foo ` and talk to its stdin and stdout. + +That's for outgoing connections. For incoming connections, +for tor, the remotedaemon looks to see if the socket file exists and +if so it accepts connections from it. (That tor socket is not used for +outgoing connections.) It would be easy to generalize this +to additional socket filenames. Eg, a remote with uuid U could use +`.git/annex/p2p/U` as its socket file. + +BTW, that git-annex-p2p-foo command is different from the git remote +helper you suggest, which corresponds to git-remote-tor-annex. But, +git-remote-tor-annex would easily generalize to a +git-remote-p2p-annex git remote helper, if there was a generic +p2p-annex url type and a way to connect to it. + +If the P2P protocol's AUTH is provided with an AuthToken, there would need +to be an interface to record the one to use for a given p2p connection. +`git-annex p2p` handles setting up AuthTokens, but its approach may or may +not make sense for a given p2p protocol. It does look like, if there's a +generic way implemented to connect to a given p2p-annex url, `git-annex +p2p` would mostly work. But there would need to be a way to generate an +address using such an url, like `git-annex enable-tor` does. + +Seems pretty close to a workable design to me, but I don't know how well it +will match up with these various kinds of P2P networks. +""]]