2016-12-07 12:11:38 -04:00
|
|
|
git-annex sync over tor
|
|
|
|
|
|
|
|
|
|
Mostly working!
|
|
|
|
|
|
|
|
|
|
Current todo list:
|
|
|
|
|
|
2016-12-08 16:00:29 -04:00
|
|
|
* When a transfer can't be done because another transfer of the same
|
|
|
|
|
object is already in progress, the message about this is output by the
|
|
|
|
|
remotedaemon --debug, but not forwarded to the peer, which shows
|
|
|
|
|
"Connection reset by peer"
|
2016-12-07 12:11:38 -04:00
|
|
|
* Think about locking some more. What happens if the connection to the peer
|
|
|
|
|
is dropped while we think we're locking content there from being dropped?
|
|
|
|
|
|
|
|
|
|
Eventually:
|
|
|
|
|
|
2016-12-24 13:10:51 -04:00
|
|
|
* Windows and Android support.
|
2016-12-08 13:58:11 -04:00
|
|
|
* Limiting authtokens to read-only access.
|
|
|
|
|
* Revoking authtokens. (This and read-only need a name associated with an
|
|
|
|
|
authtoken, so the user can adjust its configuration after creating it.)
|
2016-12-07 12:11:38 -04:00
|
|
|
* friend-of-a-friend peer discovery to build more interconnected networks
|
|
|
|
|
of nodes
|
2016-12-13 13:59:28 -04:00
|
|
|
* Discovery of nodes on same LAN, and direct connection to them.
|
2016-12-29 14:57:13 -04:00
|
|
|
* Make `git annex map` show a peer's remotes?
|
|
|
|
|
Would it be surprising if peers can learn this information?
|
2023-01-16 13:45:24 -04:00
|
|
|
|
|
|
|
|
> While the above "eventually" todo list is not implemented, the main
|
|
|
|
|
> todo has been implemented for a long time. I think if users need
|
|
|
|
|
> such things, they should be in separate todos. So, [[done]] --[[Joey]]
|
