id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
266	onion vs tor+exit: which will win? which should win?	Brian Warner		"If a FURL contains both `tcp:` and `tor:` (perhaps from a server that wants to assist Tor-capable clients, but remain accessible to non-capable clients), and the client is configured to use Tor for `tcp:` hints too (because it wants to hide its own IP address), what will happen?

I think the two connections will race, and I suspect the `tcp:` hint will win (it will go through an exit node, but it doesn't have to look up the onion descriptor, so I think it'll have less work to do).

But I think we'd prefer the `tor:` (onion) hint to win, since that reveals less information to the internet at large.

Is there a clean way to make this more likely to happen? If hints were processed as a group, we could make the `tcp` handler notice the presence of the `tor` handler, and then stall itself for a few seconds, to give the `tor` handler a chance to win. But connection handlers are pretty independent: they're unaware of each other.

Maybe connection-handlers could return a priority value (synchronously, before `hint_to_endpoint` is called). If there are multiple hints with different priorities, the overall connection manager could impose a delay.

Or maybe the handler could get an additional argument that says ""by the way, here are the other handlers that I'm about to ask, feel free to let that influence your behavior"". We know all the handlers that will be used early (once we see the hint types), so this wouldn't be too hard to implement. And then the TCP handler could notice the Tor handler and stall itself. We might add a marker Interface to let the connection manager know that this handler is capable of understanding the extra argument. Or add a static class attribute, or something.
"	enhancement	new	major	undecided	network	0.12.0		anonymity tor