2016-12-07 16:11:38 +00:00
|
|
|
git-annex sync over tor
|
|
|
|
|
|
|
|
|
|
Mostly working!
|
|
|
|
|
|
|
|
|
|
Current todo list:
|
|
|
|
|
|
2016-12-08 20:00:29 +00: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 16:11:38 +00: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 17:10:51 +00:00
|
|
|
* Windows and Android support.
|
2016-12-08 17:58:11 +00: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 16:11:38 +00:00
|
|
|
* friend-of-a-friend peer discovery to build more interconnected networks
|
|
|
|
|
of nodes
|
2016-12-13 17:59:28 +00:00
|
|
|
* Discovery of nodes on same LAN, and direct connection to them.
|
2016-12-29 18:57:13 +00:00
|
|
|
* Make `git annex map` show a peer's remotes?
|
|
|
|
|
Would it be surprising if peers can learn this information?
|
2023-01-16 17:45:24 +00: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]]
|
