So, we currently have a Pluggable Transport (PT) spec, and it kind-of
sort-of works (The documentation is a mess that I'm working on
cleaning up, but it's an orthogonal issue for how well it works).
There are a number of problems with the current PT spec that require
breaking backward compatibility to fix, so eventually I would like to
do so.
I'm soliciting input on what people would also like to see in a
(currently hypothetical) PT spec 2.0 beyond what I already have in mind:
ÂMUST haves:
 * Support dual stack Bridges correctly (Multiple server endpoints per
  transport)
 * Increase the argument space beyond 510 bytes (Prop. #227).
 * Mandatory ExtORPort support (currently optional, but metrics are
  good).
 * Centralized logging by the calling process (Probably via stderr).
 * AF_UNIX support where sensible for better sandboxing.
ÂMIGHT haves:
 * Rename the env vars to not start with "TOR_PT". Some people claim
  that this is a good idea (I think it is stupid and cosmetic).
 * Ability to force at least clients to stop network activity without
  tearing the PT down.
 * Deprecate SOCKS4a, and make SOCKS5 mandatory for clients.
ÂUNLIKELY:
 * Specify an interface for where fork()/exec() isn't possible (iOS).
  I don't think this is makes sense because it is probably too
  platform/caller specific.
 * Allow operating both as a client and a server simultaneously. I
  don't see a problem with running 2 copies of something for this
  use case.
I probably missed some things. If people have strong opinions about
this, do reply, otherwise I *will* design something that I like, which
will not include what other people want.
Regards,
--
Yawning Angel
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev