[tor-bugs] #9022 [Pluggable transport]: Create an XMPP pluggable transport

[Tor Bug Tracker & Wiki]

#9022: Create an XMPP pluggable transport
---------------------------------+------------------------------------------
 Reporter:  asn                  |          Owner:  feynman 
     Type:  task                 |         Status:  accepted
 Priority:  normal               |      Milestone:          
Component:  Pluggable transport  |        Version:          
 Keywords:                       |         Parent:          
   Points:                       |   Actualpoints:          
---------------------------------+------------------------------------------

Comment(by feynman):

 Replying to [comment:62 asn]:
 > Check out my branch 'argparse_cli'. It looks like this:
 >
 https://gitweb.torproject.org/user/asn/hexchat.git/shortlog/refs/heads/argparse_cli
 >
 > You might or might not like it. It splits the hexchat.py launcher into
 two launchers, one for the client-side and another for the server-side. I
 believe the CLI is smoother now.
 >
 > You don't see many CLIs with '--client' containing three different
 things. Also, in your latest code all your args are optional, which breaks
 badly.
 >
 > The only functional change in my branch is that the client-side can't
 spawn multiple XMPP bots anymore (it only accepts a single jid/password
 pair). Does this matter? I imagined that only the server-side needs to
 have control XMPP bots. If that's not the case I'll fix it somehow to
 allow multiple JID/passwords. (The server-side still supports multiple
 XMPP credentials).

 First of all, the logins and log file should be required command line
 arguments. I will fix that now.


 As for your other changes, I generally think that cutting down on
 flexibility is a bad idea unless there is a clear tradeoff. Personally, I
 would rather have the ability to spawn have multiple clients and not need
 it. I really do not think it takes anything away from the program, and it
 just adds some extra versatility that someone someday might need.

 As for the client connecting with multiple JIDs, that is a must. Just like
 the server, the client should be able to distribute the load of an
 internet connection over multiple JIDs (even if it needs far less than a
 server).

 Remember, the only functional difference between a client and a server is
 that a client can start a conversation. Once the server makes the
 requested connection, the two bots act identically. There is nothing
 stopping a bot running as a client from making a connection to another bot
 running as a client. This is how I do my testing. My laptop's hexchat acts
 as a client for my browser and a server for my desktop's tor. My desktop's
 hexchat acts as a client for tor and a server for my laptop's hexchat.
 This helps me increase the stress on both bots and determine how they
 react under heaver loads than I could provide otherwise.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9022#comment:63>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online