Only throttle uploads to peers, not to apt.

[quix0rs-apt-p2p.git] / TODO

diff --git a/TODO b/TODO
index b4951933a627a2d6a5b4d47e4f561401aaa4e188..b0724b4bd35671f916b35b39b250cdcdbec93411 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,10 +1,3 @@
-Consider what happens when we are the closest node.
-
-In some of the actions it is unclear what happens when we are one of the
-closest nodes to the target key. Do we store values that we publish
-ourself?
-
-

 Add all cache files to the database.
 
 All files in the cache should be added to the database, so that they can
 Add all cache files to the database.
 
 All files in the cache should be added to the database, so that they can


@@ -47,3 +40,45 @@ originally provided the piece is probably at fault, since he is now
 providing a later piece. This doesn't work if the differing piece is the 
 first piece, in which case it is downloaded from a 3rd peer, with 
 consensus revealing the misbehaving peer.
 providing a later piece. This doesn't work if the differing piece is the 
 first piece, in which case it is downloaded from a 3rd peer, with 
 consensus revealing the misbehaving peer.

+
+
+Consider storing deltas of packages.
+
+Instead of downloading full package files when a previous version of
+the same package is available, peers could request a delta of the
+package to the previous version. This would only be done if the delta
+is significantly (>50%) smaller than the full package, and is not too
+large (absolutely). A peer that has a new package and an old one would
+add a list of deltas for the package to the value stored in the DHT.
+The delta information would specify the old version (by hash), the
+size of the delta, and the hash of the delta. A peer that has the same
+old package could then download the delta from the peer by requesting
+the hash of the delta. Alternatively, very small deltas could be
+stored directly in the DHT.
+
+
+Consider tracking security issues with packages.
+
+Since sharing information with others about what packages you have
+downloaded (and probably installed) is a possible security
+vulnerability, it would be advantageous to not share that information
+for packages that have known security vulnerabilities. This would
+require some way of obtaining a list of which packages (and versions)
+are vulnerable, which is not currently available.
+
+
+Consider adding peer characteristics to the DHT.
+
+Bad peers could be indicated in the DHT by adding a new value that is
+the NOT of their ID (so they are guaranteed not to store it) indicating
+information about the peer. This could be bad votes on the peer, as
+otherwise a peer could add good info about itself.
+
+
+Consider adding pieces to the DHT instead of files.
+
+Instead of adding file hashes to the DHT, only piece hashes could be
+added. This would allow a peer to upload to other peers while it is
+still downloading the rest of the file. It is not clear that this is
+needed, since peer's will not be uploading and downloading ery much of
+the time.