rename design page
authorJoey Hess <joeyh@joeyh.name>
Tue, 29 Jul 2025 18:24:05 +0000 (14:24 -0400)
committerJoey Hess <joeyh@joeyh.name>
Tue, 29 Jul 2025 18:24:05 +0000 (14:24 -0400)
doc/design/generic_p2p_transport.mdwn [new file with mode: 0644]
doc/design/p2p_socket_transport.mdwn [deleted file]
doc/git-annex-p2p.mdwn
doc/git-remote-p2p-annex.mdwn
doc/todo/generic_p2p_socket_transport/comment_12_c106b0a8011cc5f66e35894e9899c2ab._comment

diff --git a/doc/design/generic_p2p_transport.mdwn b/doc/design/generic_p2p_transport.mdwn
new file mode 100644 (file)
index 0000000..0302607
--- /dev/null
@@ -0,0 +1,41 @@
+This is a generic interface that allows git-annex to use a P2P network.
+
+Examples of such networks are tor, yggstack or fowl. (git-annex has a
+built-in integration with tor which does not use this interface.)
+
+Such a P2P network has some form of address, which can be
+used to connect to a given peer by address across the network.
+
+A git remote using the P2P network has an url of the form
+`p2p-annex::<netname>+<address>`
+
+To connect to that remote, git-annex runs the command
+`git-annex-p2p-<netname>`, giving it the P2P network address as its only
+parameter. The command is responsible for connecting to that peer, and
+relaying data to it. Data fed into the command on stdin should be sent to
+the peer, and data received from the peer should be output to stdout. If it
+is unable to connect, the command can exit nonzero. When the peer closes
+connection, the command can exit zero.
+
+To handle incoming connections from peers, `git-annex remotedaemon`
+runs `git-annex-p2p-<netname>` with the parameter "socket", followed 
+by the P2P address of the local repository. The command
+should output the path of a unix socket file. When it does, `git-annex
+remotedaemon` will use that socket file to listen for connections from
+peers, and service them. (The [[P2P_protocol]] is spoken over these
+connections.)
+
+Note that, if the P2P network does not natively use a unix socket file,
+a command like `socat` can be run by `git-annex-p2p-<netname> socket` 
+to convert the P2P network's own equivilant into a unix socket file.
+
+To configure `git-annex remotedaemon` to listen on a given P2P network,
+the user runs `git-annex p2p --enable <netname>`. That also
+runs `git-annex-p2p-<netname>`, this time with the parameter "address".
+That should output the P2P network address that can be used by peers
+to connect to the repository. It can first do whatever it needs to do to
+set up the P2P networl.
+
+The program [[git-remote-p2p-annex]] is included in git-annex as a git
+remote helper program. git will use that program to handle `pull` and
+`push` with git remotes that use the `p2p-annex::` url scheme.
diff --git a/doc/design/p2p_socket_transport.mdwn b/doc/design/p2p_socket_transport.mdwn
deleted file mode 100644 (file)
index 0302607..0000000
+++ /dev/null
@@ -1,41 +0,0 @@
-This is a generic interface that allows git-annex to use a P2P network.
-
-Examples of such networks are tor, yggstack or fowl. (git-annex has a
-built-in integration with tor which does not use this interface.)
-
-Such a P2P network has some form of address, which can be
-used to connect to a given peer by address across the network.
-
-A git remote using the P2P network has an url of the form
-`p2p-annex::<netname>+<address>`
-
-To connect to that remote, git-annex runs the command
-`git-annex-p2p-<netname>`, giving it the P2P network address as its only
-parameter. The command is responsible for connecting to that peer, and
-relaying data to it. Data fed into the command on stdin should be sent to
-the peer, and data received from the peer should be output to stdout. If it
-is unable to connect, the command can exit nonzero. When the peer closes
-connection, the command can exit zero.
-
-To handle incoming connections from peers, `git-annex remotedaemon`
-runs `git-annex-p2p-<netname>` with the parameter "socket", followed 
-by the P2P address of the local repository. The command
-should output the path of a unix socket file. When it does, `git-annex
-remotedaemon` will use that socket file to listen for connections from
-peers, and service them. (The [[P2P_protocol]] is spoken over these
-connections.)
-
-Note that, if the P2P network does not natively use a unix socket file,
-a command like `socat` can be run by `git-annex-p2p-<netname> socket` 
-to convert the P2P network's own equivilant into a unix socket file.
-
-To configure `git-annex remotedaemon` to listen on a given P2P network,
-the user runs `git-annex p2p --enable <netname>`. That also
-runs `git-annex-p2p-<netname>`, this time with the parameter "address".
-That should output the P2P network address that can be used by peers
-to connect to the repository. It can first do whatever it needs to do to
-set up the P2P networl.
-
-The program [[git-remote-p2p-annex]] is included in git-annex as a git
-remote helper program. git will use that program to handle `pull` and
-`push` with git remotes that use the `p2p-annex::` url scheme.
index 7d96c0dbf8e4e367eec8d69c451c8bf76dcb209d..7d4c6ee80a68b0ac438458075a286c6a64faf347 100644 (file)
@@ -17,7 +17,7 @@ network. (This needs Tor to be installed.)
 git-annex can also support other P2P networks, using a helper program
 that you can install. These programs have names of the form
 `git-annex-p2p-<netname>`. See
-<https://git-annex.branchable.com/design/p2p_socket_transport/>
+<https://git-annex.branchable.com/design/generic_p2p_transport/>
 for documentation about how to create such a program.
 
 # OPTIONS
index 175ae3bc2988e187e72e43b2ff47f57910a5ce4f..5021312caeea7448c59cff39213fc4a89ee3b084 100644 (file)
@@ -28,7 +28,7 @@ gitremote-helpers(1)
 
 [[git-remote-tor-annex]](1)
 
-<https://git-annex.branchable.com/design/p2p_socket_transport/>
+<https://git-annex.branchable.com/design/generic_p2p_transport/>
 
 # AUTHOR
 
index b6b22034829ebae2d56fb8f070cb23c275c064d5..941ebe62c11e64e477b8d31dbd055424bd096c42 100644 (file)
@@ -3,7 +3,7 @@
  subject="""comment 12"""
  date="2025-07-29T16:41:07Z"
  content="""
-I have started a design document at [[design/p2p_socket_transport]],
+I have started a design document at [[design/generic_p2p_transport]],
 to collect all the scattered decisions here into a coherent document that
 can be used by someone implementing support for one of these networks.