<div dir="ltr">I've just tried the patch from ticket 20082 and it works great for me. I was actually wondering why it was taking so long for a ephemeral hidden service to get registered in my SIM4Things project (I register an ephemeral service first to get Tor to setup the introduction points, then re-register it a la OnionBalance with a new identity). It's definitely a great improvement for my project!<div><br></div><div>Razvan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 7, 2016 at 6:40 PM, Ivan Markin <span dir="ltr"><<a href="mailto:twim@riseup.net" target="_blank">twim@riseup.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi tor-dev@!<br>
<br>
Moving the discussion on the future of rendinitialpostdelay from ticket<br>
#20082 [1] here.<br>
<br>
Transcribing the issue:<br>
> At the moment descriptor is getting posted at<br>
> MIN_REND_INITIAL_POST_DELAY (30) seconds after onion service<br>
> initialization. For the use case of real-time one-time services<br>
> (like OnionShare, etc) one has to wait for 30 seconds until this<br>
> onion service can be reached. Besides, if a client tries to reach<br>
> the service before its descriptor is ever published, tor client gets<br>
> stuck preventing user from reaching this service after descriptor is<br>
> published. Like this: Could not pick one of the responsible hidden<br>
> service directories to fetch descriptors, because we already tried<br>
> them all unsuccessfully.<br>
<br>
<br>
> It has jumped to 30s from 5s due to "load on authorities".<br>
> 11d89141ac0ae0ff371e8da79abe21<wbr>8474e7365c:<br>
><br>
> +  o Minor bugfixes (hidden services): +    - Upload hidden service<br>
> descriptors slightly less often, to reduce +      load on<br>
> authorities.<br>
><br>
> "Load on authorities" is not the point anymore because we don't use<br>
> V0 since 0.2.2.1-alpha. Thus I think it's safe to drop it back to at<br>
> least 5s (3s?) for all services. Or even remove it at all?<br>
<br>
The questions are:<br>
  * Can we drop this delay? Why?<br>
  * Can we set it back to 5s thus avoiding issues that can arise after<br>
removing the delay?<br>
  * Should we do something now or postpone it to prop224?<br>
<br>
[1] <a href="https://trac.torproject.org/projects/tor/ticket/20082" rel="noreferrer" target="_blank">https://trac.torproject.org/<wbr>projects/tor/ticket/20082</a><br>
--<br>
Ivan Markin<br>
______________________________<wbr>_________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" rel="noreferrer" target="_blank">https://lists.torproject.org/<wbr>cgi-bin/mailman/listinfo/tor-<wbr>dev</a><br>
</blockquote></div><br></div>