Does Tribler hidden seeding use centralized directory servers?

[ghost]

If you're somehow bypassing central directory servers, how else do you bootstrap? I don't quite understand your explanation regarding a key-request in your Hidden Seeding Services Specifications, and I'm trying to understand how it works. I've been studying Tor as I'm quite untrusting of Tor directory authorities and Tor bridge authorities which give the Tor Project the ability to know your Tor circuit as they are responsible for giving it to you as a client. As far as anyone aside from the Tor Project is concerned, you're anonymous. But as far as the Tor Project is concerned, you're not anonymous at all. Tor is very akin to DNS over HTTPS in this regard, where nobody aside from your DoH resolver knows your DNS queries, but your DoH resolver knows them all.

With Tor hidden services or Tor stealth hidden services, you generate a hidden service descriptor and you send it out to all of the HSDir relays which make up the Distributed Hash Table of Tor. Your hidden service descriptor tells the client which introduction points you're using so they can send you their one-time-secret and rendezvous point which you'll use to rendezvous, aptly named. Your hidden service descriptor would also tell the client your public key as well as their authentication cookie if it is a Tor stealth hidden service with client authorization (As far as I understand, the introduction point is not able to fully decrypt your authentication cookie, as only the client is able to fully decrypt and verify their authentication cookie). If both the client and server wish to connect to Tor anonymously, they'd have to bypass the Tor directory authority or Tor bridge authority by using a Tor private bridge relay which is not published to any Tor directory authority or Tor bridge authority.

Assuming I've understood all of this correctly, how does this process compare to the process of Tribler's hidden seeding process?

[ichorid]

@egbertbouman , could you please comment on our hidden seeding process?

[egbertbouman]

Unfortunately, our documentation is outdated, and the key-request/response messages no longer exist in our protocol. Instead, the IP address for the introduction point and the public key for the hidden seeder are stored in our own built-in DHT. Note that this public key is not the default IPv8 public key, but it is a new key generated specifically for the use of being a hidden seeder within a particular swarm.

For all our overlays, including hidden services and the DHT, we bootstrap using a number of IPv8 trackers.

[ghost]

Sweet, what I meant by that is Tribler differs from Tor in that once you've built your Tor circuit, you're still only connecting to a single hidden service. Whereas with Tribler, once you've built your Tribler circuit, you're connecting to Tribler peers and hidden seeders. Tor + BitTorrent essentially, utilizing the properties of both Tor and BitTorrent which is of course the goal of Tribler after all, including your IPv8 networking framework which is another rabbit hole I'm going to dig into.

[ghost]

We currently have no bridge relays, although implementing such a feature would be trivial.

It certainly would be. Will you also be implementing stealth hidden seeding services with client authorization as well, giving hidden seeders the ability to create the Tribler equivalent of private trackers essentially? That'd be bad ass!

[egbertbouman]

While that does sound pretty cool, introducing authorization is not something that's on the roadmap. For the foreseeable future, our focus for the tunnel overlay will mostly be on improving security and performance.

[ghost]

Fair enough. Do you publish your roadmap publicly anywhere? I'd love to see what you're working on.

[egbertbouman]

We still need to discuss the exact roadmap internally, but I've just added a small list of things I'd like to see to #4459.