"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)...