Use known onions for XMPP servers

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

https://lists.torproject.org/pipermail/tbb-dev/2014-November/000155.html

added UX component::archived/tor messenger owner::sukhbir priority::medium resolution::fixed severity::normal status::closed type::defect labels

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?

Trac:
Owner: N/A to sukhbir
Keywords: N/A deleted, TorMessengerPublic added
Status: new to assigned
Parent: #10946 (closed) to #14161 (closed)

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?

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

Trac:
Keywords: N/A deleted, usability, UI/UX added

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 riseup.net, jabber.ccc.de, jabber.otr.im and jabber.calyxinstitute.org. For now, the default server is jabber.org 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.

Trac:
Status: assigned to closed
Resolution: N/A to fixed

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?

Trac:
Resolution: fixed to N/A
Cc: sukhbir to sukhbir, dgoulet
Status: closed to reopened

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.

Trac:
Parent: #14161 (closed) to N/A

https://github.com/nickcalyx/xmpp-onion-map

Trac:
Severity: N/A to Normal
Sponsor: N/A to N/A

Trac:
Keywords: TorMessengerPublic deleted, N/A added

Trac:
Keywords: usability, UI/UX deleted, UX added

Also suggested in #20368 (closed)

Trac:
Reviewer: N/A to N/A

Enabled again in bbded9c (and rebased for ESR52).

Trac:
Resolution: N/A to fixed
Status: reopened to closed

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

sad but true: https://blog.torproject.org/sunsetting-tor-messenger

luckily there are alternatives: https://blog.torproject.org/tor-heart-onion-messaging

.. and maybe someday

• https://cwtch.im (#27364)
• https://github.com/warner/magic-wormhole/issues/8

closed

mentioned in issue #15149 (closed)

mentioned in issue #17526 (closed)

mentioned in issue #20368 (closed)