diff options
author | 2016-12-16 16:32:29 -0400 | |
---|---|---|
committer | 2016-12-16 16:38:06 -0400 | |
commit | 6aa7e136b5d246228723f4c9996bda11f66c4445 (patch) | |
tree | 145310079adb607fae058a0a1dd42c7f155d26e1 /doc/tips/peer_to_peer_network_with_tor.mdwn | |
parent | 353b59a000dd0e4941b3c36a7fd02d23f3cf44a1 (diff) |
p2p --link now defaults to setting up a bi-directional link
Both the local and remote git repositories get remotes added
pointing at one-another.
Makes pairing twice as easy!
Security: The new LINK command in the protocol can be sent repeatedly,
but only by a peer who has authenticated with us. So, it's entirely safe to
add a link back to that peer, or to some other peer it knows about.
Anything we receive over such a link, the peer could send us over the
current connection.
There is some risk of being flooded with LINKs, and adding too many
remotes. To guard against that, there's a hard cap on the number of remotes
that can be set up this way. This will only be a problem if setting up
large p2p networks that have exceptional interconnectedness.
A new, dedicated authtoken is created when sending LINK.
This also allows, in theory, using a p2p network like tor, to learn about
links on other networks, like telehash.
This commit was sponsored by Bruno BEAUFILS on Patreon.
Diffstat (limited to 'doc/tips/peer_to_peer_network_with_tor.mdwn')
-rw-r--r-- | doc/tips/peer_to_peer_network_with_tor.mdwn | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/doc/tips/peer_to_peer_network_with_tor.mdwn b/doc/tips/peer_to_peer_network_with_tor.mdwn index 9c97735e4..13a7f0cc7 100644 --- a/doc/tips/peer_to_peer_network_with_tor.mdwn +++ b/doc/tips/peer_to_peer_network_with_tor.mdwn @@ -56,13 +56,13 @@ peer1 remote: git annex sync --content peer1 -You can also generate an address for this new peer, by running `git annex -p2p --gen-addresses`, and link other peers to that address using `git annex -p2p --link`. It's often useful to link peers up in both directions, -so peer1 is a remote of peer2 and peer2 is a remote of peer1. - Any number of peers can be connected this way, within reason. +(When the second peer links to it, the first peer also +gets a new remote added to it, which points to the second peer. +So, on the first peer, you can also sync with the second peer. +The name of the that remote will be "peer1", or "peer2", etc.) + ## starting git-annex remotedaemon Notice the `git annex remotedaemon` being run in the above examples. |