* When user rejects developer, the debug-me --debug prints
  "User did not grant access to their terminal." and says the session
  log is done, but keeps running.
* GPG WoT is checked by querying pgp.cs.uu.nl, could use wotsap if it's
  locally installed. However, the version of wotsap in debian only supports
  short, insecure keyids, so is less secure than using the server.
* Once we have a WoT path, we could download each gpg key in the path and
  verify the path. This would avoid trusting pgp.cs.uu.nl not to be evil.
  Not done yet, partly because downloading a lot of gpg keys is expensive.
* Multiple --downloads at the same time or close together fail
  with "thread blocked indefinitely in an STM transaction"
  Also see it occasionally with --debug.
* For some reason, user chat does not echo back to them, but developer
  chat does echo back to the developer.
* The current rules for when an Activity Entered is accepted allow it to
  refer to an older activity than the last one. If echoing is disabled,
  two Activity Entered could be sent, each pointing at the most recent
  Activity Seen, and there would be no proof of the order of the two.
  Reordering the two might cause different results though.

  This is not only a problem when 2 developers are connected; it also
  lets a single developer produce a proof chain that is ambiguous about
  what order they entered 2 things.

  Fix: Make a Activity Entered have a pointer to the previous Activity
  Entered that was accepted, in addition to the existing pointer. Then
  when one developer sends two Activity Entered that don't echo, there's
  still proof of ordering. When two developers are typing at the same
  time, only one of their inputs will be accepted. The client should only
  consider an Activity Entered legal if it points to the last Activity
  Entered that the client saw.

  May as well make Activity Seen have a pointer to the last accepted
  Activity Entered as well. This will make it easier when supported
  multiple developers, as each time a developer gets an Activity Seen,
  they can update their state to use the Activity Entered that it points
  to. (Perhaps not needed now that developers see other developer's
  Activity Entered.. But, this does let developers know what the current
  accepted line is.)
* loadLog should verify the hashes (and signatures) in the log, and
  refuse to use logs that are not valid proofs of a session.
  (--replay and --graphvis need this; server's use of loadLog does not)
  Everything else in debug-me checks a session's proof as it goes.
  And, everything that saves a log file checks the proof as it goes,
  so perhaps this is not actually necessary?
* Add a mode that, given a log file, displays what developer(s) gpg keys
  signed activity in the log file. For use when a developer did something
  wrong, to examine the proof of malfesence.
* How to prevent abusing servers to store large quantities of data
  that are not legitimate debug-me logs, but are formatted like them?
  Perhaps add POW to the wire protocol? Capthca?

  The user's email address is sent to the server when starting a debug-me
  session, and once the session ends, the server emails the log file
  to that address. This serves two purposes:

  1. It makes sure that the user gets a copy of the session log,
     which the developer cannot delete.
  2. Once the server has emailed the log, it's free to delete its
     copy to free up disk space. Since servers don't have to retain
     log files for long, this makes them unattractive to abusers
     who might otherwise try to store large quantities of data.

* Client should upload to multiple servers, for redundancy. This way,
  if Joey runs a server, and Alice runs a server, the user can start
  debug-me and not worry that Joey will connect, do something bad, and have
  his server cover it up, because Alice's server will also get the data.

  When Bob connects to Alice's server and sends messages to the client,
  it should then repeat those same messages to Joey's server (but not back
  to Alice's server). 

  This will use some more bandwidth of course. Inter-server replication
  could also be done to avoid using client bandwidth. But then, if the
  client only sent to Joey's server and trusted it to replicate to Alice,
  Joey could break the replication to cover up his nefarious activities
  in the debug-me session.
* When the user presses control-s, before forwarding it to the terminal,
  stop accepting any developer input. Control-s again to resume.
* Make control-backslash immediately end the debug-me session.