IQNets, making ISPs happy as bro, happy as ;)

[Zenaan Harkness]

  "Incentivize, in every case possible."

The primary vector of node 'locality' (in a technical sense) is
friend node, friend of friend node, etc, with each "friend" node
carrying a meat space user asserted 'trust' level.

The next vector of node locality, is network locality - nodes
connected to my ISP ought be known, and for many types of content,
preferred for downloading from.

"My ISP" may be "none" when I am in pure ad hoc wireless mesh mode.

There may well be some trust vs locality vs cautiousness polynomial
calculations to determine "reasonable randomized routes for each
content distribution use case at issue", given current IQNets
connectivity.

At least, by preferring ISP network locality where it is reasonable
and sensible to do so (modulo inter jurisdictional network hopping
chaff fill, node configuration, 'security' needs for the app making
the route(s) etc), IQNets is able to "prefer local ISP" and thereby
maximize ISP network locality; this is necessary to be practical (as
a mode of operation, per config) in order to maximize the "improving
network efficiency as more users join" effects, and to make ISPs as
happy as we are able - the more efficiently we use of underlying
physical networks, backhauls, dark fibre links etc, the less barriers
to use and support from those we want support from, and the more
resources are ultimately available to end users.

Another "polynomial" or config will perhaps necessarily be "minimum
node count presently within a given network locality, for 'local/ISP
preferred' routing to be enabled - if there are only 2 other IQNets
nodes presently within my ISP's network, route node mixing is simply
insufficient for various anonymizing needs.

[TODO: workshop terms "security" (may be too overloaded), and anonymity]

Similar "polynomial calculation principle" may apply for legal
jurisdiction hopping (at the network layer)...