Tribler 9.x - Remove GUI & SOCKS proxy over the Tribler network

[teddyrogers]

I see a lot of time invested in trying to get the Tribler GUI working (and bug fixing) along with backend issues for torrent tasks.

As a suggestion why not drop the GUI completely and focus development on the Tribler network. If Tribler could be run as a SOCKS proxy other bittorrent clients could use one of the local ports to connect and communicate over Tribler.

On the Connection page of qBittorrent there is the option to connect to a SOCKS proxy and I2P. Future state could implement features specific for connecting to Tribler.

[SpudmanWP]

Oh, I LIKE that

Use any Torrent client with Tribler as the backend network via SOCKS, sweet idea!

[qstokkink]

You can probably already do this. Tribler already funnels data through a (SOCKS5) proxy to anonymize it (see https://github.com/Tribler/tribler/wiki/Anonymous-Downloading-and-Streaming-specifications). It's just a matter of setting up the ports in another client. So, technically feasible.

Here's your big fat warning: Tribler is specifically made to NOT pass through any identity information through the proxy. Other clients are not made for this and will likely fingerprint the data and, thereby, deanonymize you. So, with the right configuration this is possible, but you would have to be really careful with the configuration of the third party client you hook in (assuming you can even configure such a client to that extent). Risky.

Regarding the dropping of the GUI. We are stuck in between two worlds. One set of users wants a background service and one set wants an integrated GUI. We settled for the middle ground of a web GUI. That will not please either set of users, but it's a workable solution for both. If you don't want a GUI: pass a command line argument to the Tribler process.

[teddyrogers]

@qstokkink I just tried this (using another client to connect). How to know which port I should be using, and any tips in general for making it work?

[qstokkink]

I think this should be a matter of fixing the configuration.json setting under libtorrent / socks_listen_ports to static ports (by default it's set to [0, 0, 0, 0, 0], which means "let the OS pick 5 random free ports") and then feeding those five ports to some other client (on the localhost / 127.0.0.1 address).

Let me also stress that we offer no support for this use case. You're on your own if you do this.

[teddyrogers]

@qstokkink I have been able to check Tribler process for the ports being used, and then customise another client to use it. Doing this I have been able to connect to trackers, and confirm the address of the external IP (exit node). Unfortunately there has been no connections to peers or transfer of torrent pieces.

I followed you suggestion and used fixed ports. The first port in the sequence marked "x" [x, 0, 0, 0, 0] seems to be the port for lookups. I haven't been able to get further than this. Any ideas?

[qstokkink]

What is likely (speculation!) happening is the configuration thing I mentioned before. Long story short, your torrent client is probably advertising your SOCKS proxy address from the exit node. Any other client that sees this will simply ignore you if those addresses don't match.

In human analogy: it's like someone with the name tag "Bob" introducing himself as "John". That's strange and people block you for it.

We have spent years getting Tribler's configuration just right, so that other peers "talk" to you.