Well, that's what exit policies are for. As far as relay traffic goes,
the more traffic my relay handles, the more useful my relay seems to be and
the better it makes me feel about running a relay.
Well, me to.
As has been discussed to death here many times already, there is no
way to inspect traffic prior to its exit without destroying the functional
protections of tor.
Disagree. I wrote _port_ oriented QoS, not _content_. There can be config option to prioritize some port (port range) above other. Just because somebody want to support HTTP transfer than other, but he dont want to fully stop other services (torrents).
Simply I imagine that in same style like ExitPolicy. Did you ask others, why are they using ExitPolicies? I dont think so. It is part of Tor and nobody (as far as I know) is against - because it is free choice of relay operator which kind of traffic he will support.
I know it is "barrelhouse talk". Im just talking it, because dont know, if it was debated before. Unfortunately, it is long time ago, when I was able to handle C code on sufficient level. So I cannot show any prototype of my idea. Maybe it could be done by priorities on transparent proxy behind tor exit. But is is ugly hack and non system solution.
> destroying the functional
protections of tor.
What do you mean by it in discussed situation? I think priorities are not against security and anonymity.
if you like, but you cannot even know whether you are relaying Bittorent
traffic inside the tor network, so you may as well ignore and forget the
idea and get on with enjoying your life. :-)
Thank you, you are so gracious :-).
Marek
P.S. Please dont get irritated by my English, Im really doing my best ;-)