New network topology ideas: a DHT/supernode hybrid.

Nodes are user or supernodes as usual; supernodes participate in a
chord-like DHT network. 

Every node has a unique (persistent) public/private keypair. There's a
hash table keyed by public key; when a node connects to the network it
gets told which node to register at; user nodes request parent status
from that node, unsure about search nodes yet.  Thus push requests to
any node are easily accomplished, and robust.  (Also possibly instant
messaging?)

There's a second hash table, by filehash (which should be a tree). All
hash lookups go to a specific node. It's possible to both do a lookup
and add yourself as a source in a single message. Thus a
bittorrent-style tracker setup for passing on source
information. Sources could be specified as IP:port pairs for
directly-contactable nodes, and public keys for others. (Requiring a
host lookup for every source would be inefficient, and storing the key
as well as the host wouldn't gain anything as even malicious nodes
can't disrupt the transfer. Besides, the node itself can provide its
key.)

Files themselves.  These are submitted to parents in the usual manner,
and the parent spreads the filehashes around to the correct nodes.
Searching is done conventionally, but returns no sources; hash lookup
is mandatory. Shares are signed (need to check overhead for
this). Shares aren't removed when children quit; there's a fixed-size
persistent shares cache: entries are refreshed when children resubmit
them, old entries are removed.[1]  Optimizations for submitting
already-known shares would help a lot.  Possibly shares diffuse slowly
to adjacent peers.  Search requests *may* be forwarded, maybe not.
Unsure.  Space requirements for cache are likely to be large -
possibly as much as 1Gb or so.

[1] Possibly source searching when search results come in - just
getting a count for each file.  Each result would have to be forwarded
via the parent to the child (the child doesn't know the topology well
enough to know which nodes to ask, and telling the nodes to just reply
directly to the child requires expensive correlation to map replies to
results), so possibly a "last seen" count for files could be updated
in passing.