Hi everyone,
In the p2p messaging app we're building, Quiet, users exchange some information out-of-band (an onion address) and use that to connect to each other over Tor, as they would for direct messages in Ricochet Refresh or Cwtch.
One UX failure we see now is that newly-online hidden services are not available when users first try to connect, so connecting after users have just come online takes unreasonably long (15 minutes or more) and Quiet seems like it's broken.
Any thoughts on how to speed up connecting to a newly-online hidden service?
One idea we had is to include enough information from the HSDir entry in what peers exchange out-of-band, so that they wouldn't need to rely on finding the HSDir entry. (And if this information became out of date, we could simply encourage users to share information out of band again.) Is there an easy way for us to get this information from Tor on the receiver side and pass it to Tor when connecting?
Another idea was to run some service of our own as a fallback, that we knew would always have the latest HSDir entries posted by our users. Is there some straightforward way to hardcode our own HSDir so that Tor would always check it alongside others?
If I'm reading the situation wrong or there's some other possibility I'm not thinking of, please let me know! We've definitely observed long delays in onion addresses becoming available, on top of general connection delays, and I'm trying to find a way to improve this situation.
Thanks!
Holmes
Hi Holmes,
The Briar team has been working on a new app that creates a hidden service when the app is first launched. What we've found during testing is that the newly published hidden service is usually reachable in the first connection attempt (with a timeout of 2 minutes, based on Tor's internal timeouts for HS client connections). We wait for a single copy of the HS descriptor to be uploaded before showing a QR code, which the other device scans and then immediately tries to connect. It sounds like you're seeing different results with a similar scenario, so it would be interesting to find out what's different between your scenario and ours.
When you say newly-online, do you mean that the HS has never been published before, or that it's been published and has then spent some time offline? Is the Tor process still running when the app is offline?
Cheers, Michael
On 23/02/2023 14:35, Holmes Wilson wrote:
Hi everyone,
In the p2p messaging app we're building, Quiet, users exchange some information out-of-band (an onion address) and use that to connect to each other over Tor, as they would for direct messages in Ricochet Refresh or Cwtch.
One UX failure we see now is that newly-online hidden services are not available when users first try to connect, so connecting after users have just come online takes unreasonably long (15 minutes or more) and Quiet seems like it's broken.
Any thoughts on how to speed up connecting to a newly-online hidden service?
One idea we had is to include enough information from the HSDir entry in what peers exchange out-of-band, so that they wouldn't need to rely on finding the HSDir entry. (And if this information became out of date, we could simply encourage users to share information out of band again.) Is there an easy way for us to get this information from Tor on the receiver side and pass it to Tor when connecting?
Another idea was to run some service of our own as a fallback, that we knew would always have the latest HSDir entries posted by our users. Is there some straightforward way to hardcode our own HSDir so that Tor would always check it alongside others?
If I'm reading the situation wrong or there's some other possibility I'm not thinking of, please let me know! We've definitely observed long delays in onion addresses becoming available, on top of general connection delays, and I'm trying to find a way to improve this situation.
Thanks!
Holmes
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
Holmes Wilson -
Michael Rogers