[tor-dev] Counting HS descriptor uploads

[Michael Rogers]

Hi David,

Many thanks for the reply. I think there are still some basic pieces I 
need to get my head around in order to understand this:

1. When a brand new hidden service is created, what are the minimum and 
maximum number of HSDirs that Tor will try to upload the descriptor to?

2. Does each successful upload produce exactly one HS_DESC UPLOADED 
control port event?

3. If Tor can't immediately upload as many copies of the descriptor as 
it wants to, does it retry immediately or is there some delay before 
retrying? (We're trying to decide how to design the UX for this 
situation.) Are there any control port events we could use to track the 
status of the upload process in this case?

4. When a (non-ephemeral) hidden service is created and then the Tor 
process is stopped and restarted, what are the minimum and maximum 
number of HSDirs that Tor will try to upload the descriptor to after 
restarting? In particular, are there any situations where Tor might 
decide that it doesn't need to upload any copies at all after 
restarting, because the previously uploaded copies are still good?

Thanks,
Michael

On 09/08/2022 14:01, David Goulet wrote:
> On 28 Jun (13:27:03), Michael Rogers wrote:
>> Hi,
> 
> Better late than never I guess :S...
> 
>>
>> The Briar team is working on a new app that uses Tor hidden services, and
>> we're trying to work out when the server publishing a hidden service should
>> consider the service to be reachable by clients.
>>
>> We've tried counting HS descriptor uploads via control port events, but we
>> found that when republishing a hidden service that has been published
>> before, the number of descriptor uploads seems to vary.
>>
>> When republishing a hidden service, is it guaranteed that at least one copy
>> of the descriptor will be uploaded? Or are there circumstances where Tor
>> might decide that enough copies were previously uploaded, and still contain
>> up-to-date information about introduction points etc, so no new copies need
>> to be uploaded?
> 
> Descriptor upload can be quite chaotic and unpredictable. Reason is that there
> are various cases that can make a service regenerate the descriptors and thus
> republish them.
> 
> But, in all these cases, the descriptor will change as in for the "version"
> but might not change the intro points information for instance. Such case
> would be that the HSDir hashring changed and the service noticed so it would
> immediately upload the existing descriptor(s).
> 
> Sometimes, 1 introduction points disappears and so a new one is picked up and
> a re-upload is done.
> 
> And on and on, there are really various cases that can change it.
> 
> Not sure I'm fully answering the question but if not, let me know.
> 
> Cheers!
> David
> 
> 
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x11044FD19FC527CC.asc
Type: application/pgp-keys
Size: 23451 bytes
Desc: OpenPGP public key
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20220817/fab38a75/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20220817/fab38a75/attachment-0001.sig>