meejah transcribed 2.0K bytes:
Ivan Markin twim@riseup.net writes:
IMO an onion service should publish its first descriptor instantly. If something happens afterwards and one has to fix the descriptor - deal with it with backoff/delay to prevent DoS on HSDirs.
+1
txtorcon only ever waits for the first descriptor to be published (since at this point I presume the service is at least theoretically reachable) before alerting the caller that the service is "ready".
From a controller perspective it would also be nice to have more-granular feedback (maybe an HS_DESC event that indicates "waiting X seconds to do anything at all with this one") so that e.g. a GUI can make a nice progress bar that doesn't just sit there (i.e. if tor tells me that it will be 5 seconds before we even try anything, I can provide feedback every 1 second if I like).
Similarly to teor's earlier response in this thread, the change to a 1s timer would be an easy patch (read: also a welcome patch!) which would likely see inclusion in 0.2.9 stable, accompanied by plausible arguments for inclusion. Given [insert handwavey "I'm not the person who does statistics/metrics around here"] that most ephemeral onion services are well-behaving, from txtorcon-using to stem-based things, to apps like ricochet which create onion services and then later reload them, the initial descriptor upload should be no overhead at all compared to a not-so-well-behaving service/app which e.g. uploads ten descriptors per second.
Perhaps you could achieve "less load on HSdirs" but preserve "at least one descriptor is uploaded right away" by selecting N random delays, where one lucky HSDir gets a 0 second delay and the other 5 get something random between 1 and 30 (or whatever).
Couldn't have a worrisome effect: that a client chooses the wrong HSDir several times (in the process of the onion service unluckily reporting delayed descriptors at precisely the wrong time w.r.t. the client)?
p.s. I don't view ADD_ONION as being useful *only* for temporary services -- it's also the good API for applications that want to manage their own private-key material. For these, they might like to know when *all* descriptors are uploaded, etc.
Again, improving the control port notification interface is much welcome, and patches are straightforward to review for timely inclusion.
Best regards,