Don't require pluggable transport proxies to be SOCKS proxies
(Re-using text from Zack Weinberg for this description.)
There are pluggable transport proxies that don't actually act as a SOCKS proxy. For example, StegoTorus has its own configuration; it ignores everything told it in the SOCKS dialogue and always connects to the bridge that it knows about. If you want multiple StegoTorus bridges accessible to your Tor client, you need multiple "ClientTransportPlugin ... exec" specifications. This is only going to get worse when they move away from having everything set up on StegoTorus' command line, which has been direly needed for some time now.
Theoretically all of StegoTorus' configuration could be encapsulated in the SOCKS key-value-pairs-in-the-password hack that's described in 180-pluggable-transport.txt, but they never implemented that and they don't want to. They want to rip out all of the SOCKS code, in fact. The way they want it to work is
Bridge storus1 direct [keyid=...]
ClientTransportPlugin storus1 direct 127.0.0.1:8888In this case, 'storus1' is not a "method", it's a human-readable identifier for the bridge that Tor will be connected to if it starts talking the OR protocol -- with no initial SOCKS exchange! -- on 127.0.0.1:8888.
"direct" should also be valid in CMETHOD/SMETHOD lines for the proxy-management protocol, with the same semantics. Zack says he hasn't really thought through how the server side of this stuff ought to work.