Opened 6 years ago

Closed 3 years ago

Last modified 2 years ago

#13855 closed defect (fixed)

Use known onions for XMPP servers

Reported by: arlolra Owned by: sukhbir
Priority: Medium Milestone:
Component: Archived/Tor Messenger Version:
Severity: Normal Keywords: UX
Cc: sukhbir, dgoulet Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


xmpp-client hardcodes a list of .onion addresses for commonly used XMPP servers. Consider doing this for Tor Messenger as well.

Child Tickets

Change History (15)

comment:1 Changed 6 years ago by sukhbir

Sure, seems like a fine thing to do.

But how do we want to handle this in the UI? Should we automatically replace the address to a .onion when the user chooses a server? Or should we have a dropdown menu?

comment:2 Changed 6 years ago by sukhbir

Keywords: TorMessengerPublic added
Owner: set to sukhbir
Parent ID: #10946#14161
Status: newassigned

comment:3 Changed 6 years ago by cypherpunks

I'd think replacing invisibly to the user is best. Even better would be if the situation would be handled transparently as soon as no connection to the server could be made by falling back to the original domain (in case it's only the hidden service which is off) and only if that fails, too, inform the user. But I guess that is quite messy to implement?

comment:4 Changed 6 years ago by mrphs

Keywords: usability UI/UX added

There should be a setting for this, on-by-default. But the user should be able to turn it off at anytime.

comment:5 Changed 5 years ago by sukhbir

Resolution: fixed
Status: assignedclosed

Committed in b1c51f3.

Tor Messenger will now configure (XMPP) accounts for known servers to automatically use the onion address if available. The current list of servers we have borrowed are from xmpp-client and are,, and For now, the default server is and users have to manually enter the name of the service they want to use.

This process is transparent to the user (but requires no input from them so as to keep it easy) and in case the connection doesn't work or they don't want to use a hidden service, they can choose to omit this step.

comment:6 Changed 5 years ago by sukhbir

Just to add, we are still open to comments about how to make it apparent to the user that we are setting the onion addresses so that they are not confused when they see it in the server field (since they are not setting it). Modal dialog windows are out of the question; suggestions are welcome for other ways, like perhaps tooltips?

comment:7 Changed 5 years ago by arlolra

Cc: dgoulet added
Resolution: fixed
Status: closedreopened

comment:8 Changed 5 years ago by arlolra

These sentences are paraphrased from a discussion on IRC with dgoulet.

Using the onions by default has the potential to bring these services (or their guards) to their knees. Some experiments show HSs as unusable with around 60 to 100 client connections with data in transit. ~30% of the whole CPU/tor process is crypto at that load, which for the most part doesn't make use of multiple cores. Until that's fixed or DonnchaC's HS load balancing comes along, maybe we don't want that as the default.

A better starting point may be to make it easier to configure the onions.

comment:9 Changed 5 years ago by sukhbir

Parent ID: #14161

comment:11 Changed 5 years ago by arlolra

Keywords: TorMessengerPublic removed

comment:12 Changed 5 years ago by arlolra

Keywords: UX added; usability UI/UX removed

comment:13 Changed 4 years ago by arlolra

Also suggested in #20368

comment:14 Changed 3 years ago by sukhbir

Resolution: fixed
Status: reopenedclosed

Enabled again in bbded9c (and rebased for ESR52).

comment:15 Changed 2 years ago by traumschule

<+sukhe> hello. yes, I think it's fine to close the tickets. thanks for doing what we should done earlier :)

sad but true:

luckily there are alternatives:

.. and maybe someday

Note: See TracTickets for help on using tickets.