tor/TODO

[First four are all equally first.
Others follow in order of priority.]

Patch well-known proxies to make them OR compliant
   Data stream anonymizing, HTTP/FTP (Privoxy, Squid), SMTP, etc.
   Packet Redirector, a la FreeBSD (DNS, authenticated connections, etc.)

Deploy and manage open source development site.
Manage and maintain code, write documentation, design and write
 unit tests, handle patch submissions, make the autoconf work, etc

Deploy a widespread network: manage deployment.
Maintain and distribute directory/network state information etc. Keep
operators and users happy.

Test OR network for reliability and performance, with and without
 mechanisms for throttling, congestion control, padding, load balancing
 if applicable, etc.
     Use httperf and webload to get some performance stats
     Modify code as dictated by testing.

Develop rendezvous points
Implement reply onions
Develop location protected servers idea

Enhance router twins to do load balancing as well as DoS prevention

Develop and deploy automated reputation management, directory servers,
and directory/network state monitoring.

---

debian / red hat spec file
handle starting things as a system daemon
transition addr to sin_addr
get proxy to choose the same conn if it's open

Obvious things I'd like to do that won't break anything:

* Abstract out crypto calls (done), with the eventual goal of moving
  from openssl to something with a more flexible license.

* Test suite. We need one.

* Since my OR can handle multiple circuits through a given OP,
  I think it's clear that the OP should pass new create cells through the
  same channel. Thus we can take advantage of the padding we're already
  getting. Does that mean the choose_onion functions should be changed
  to always pick a favorite OR first, so the OP can minimize the number
  of outgoing connections it must sustain?

* Figure out what .h files we're actually using, and how portable
  those are.

* Exit policies. Since we don't really know what protocol is being spoken,
  it really comes down to an IP range and port range that we
  allow/disallow. The 'application' connection can evaluate it and make
  a decision.

* We currently block on gethostbyname at the exit. This is poor. We need
  to set it up so we have a separate process that we talk to. There are
  some free software versions we can use, but they'll still be tricky.

* I'd like a cleaner interface for the configuration files, keys, etc.
  Perhaps the next step is a central repository where we download router
  lists? We can aim to make use of the directory servers that Mixminion
  deploys.

* ORs should rotate their link keys periodically. Later.

* The parts of the code that say 'FIXME'

* Clean up the number of places that get to look at prkey. Later.

* Circuits should expire sometime, say, when circuit->expire triggers?
  Later.




Non-obvious things I'd like to do:

(Many of these topics are inter-related. It's clear that we need more
analysis before we can guess which approaches are good.)

* Currently when a connection goes down, it generates a destroy cell
  (either in both directions or just the appropriate one). When a
  destroy cell arrives to an OR (and it gets read after all previous
  cells have arrived), it delivers a destroy cell for the "other side"
  of the circuit: if the other side is an OP or App, it closes the entire
  connection as well.

  But by "a connection going down", I mean "I read eof from it". Yet
  reading an eof simply means that it promises not to send any more
  data. It may still be perfectly fine receiving data (read "man 2
  shutdown"). In fact, some webservers work that way -- the client sends
  his entire request, and when the webserver reads an eof it begins
  its response. We currently don't support that sort of protocol; we
  may want to switch to some sort of a two-way-destroy-ripple technique
  (where a destroy makes its way all the way to the end of the circuit
  before being echoed back, and data stops flowing only when a destroy
  has been received from both sides of the circuit); this extends the
  one-hop-ack approach that Matej used.

* Reply onions. Hrm.