<div dir="auto">Interesting! </div><div dir="auto"><br></div><div dir="auto">So it seems important to not have two clients hosting the same onion address at the same time, which is doable, and then we have to figure out this revision counter.</div><div dir="auto"><br></div><div dir="auto">What happens if the revision counter is not incremented correctly? </div><div dir="auto"><br></div><div dir="auto">Is it that the now offline host could become the destination for incoming traffic to the onion address?</div><div dir="auto"><br></div><div dir="auto">Thanks so much for this feedback! </div><div dir="auto">Holmes </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 2, 2021 at 1:41 PM David Goulet <<a href="mailto:dgoulet@torproject.org">dgoulet@torproject.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 26 Mar (08:55:54), Holmes Wilson wrote:<br>
> Hi everyone,<br>
<br>
Greetings,<br>
<br>
> <br>
> We’re working on a peer-to-peer group chat app where peers connect over v3<br>
> onion addresses. <br>
> <br>
> One issue are groups where there are many users but only a few are online in<br>
> a given moment.  Onion addresses are forever, and existing peers might know<br>
> every peer in the network, but it will take a while to try connecting to all<br>
> of them to find one that is online. <br>
> <br>
> In this case, it seems helpful for one or more peers to share one or more<br>
> onion addresses that would serve as reliable  “trackers", e.g. <br>
> <br>
> 1. All members know the keypairs for these addresses.<br>
> 2. All online members ping these addresses at random intervals to say<br>
>    they’re online.<br>
> 3. If they can’t connect to an address, they start hosting it themselves.<br>
> <br>
> We’re going to start testing it, but we’re wondering if folks here know the<br>
> likely outcome of trying to “share” hosting of an onion service in this<br>
> spontaneous-volunteer sort of way and if there are downsides.<br>
> <br>
> I *think* the most important question is how long it takes for the network<br>
> to stop routing incoming traffic to an offline client when there’s an online<br>
> one available. How long will the address likely be unreachable in one of<br>
> these transition moments, assuming some peer immediately detects that a<br>
> “tracker” onion address has gone offline and begins hosting it themselves?<br>
> (And does this question make sense?)<br>
<br>
Interesting idea!<br>
<br>
So sharing onion address key material between peers can be fine until they are<br>
used at the same time. What will happen is that the two peers hosting the same<br>
onion address (service) will start competing on the onion service directory<br>
side where service's upload what we call a "descriptor" which is what client<br>
fetch in order to initiate a connection to the service.<br>
<br>
With v3, it gets even more complicated actually because of the "revision<br>
counter" in the descriptor which v2 didn't have.<br>
<br>
It is simply a number that keeps going up in the descriptor so the onion<br>
service directory (relay) doesn't accept a previous descriptor (replay). And<br>
so, your two peers sharing the onion keys will require to somehow sync that<br>
revision counter for your idea to work (located on disk in the state file,<br>
"HidServRevCounter").<br>
<br>
Else, one will inevitably be higher than the other and thus will always<br>
succeed where it will always fail for the other peer.<br>
<br>
One approach here, and it is a hack of course, is for the second peer<br>
detecting that the onion is down to download the descriptor (offline one)<br>
still on the directory, get the revision counter out of it ("revision-counter"<br>
field), do a +1 on it and set its state file with it. It is a hack but would<br>
work... You will likely have to deal with "descriptor not found anymore on the<br>
directories" and so you could bruteforce the revision counter from your last<br>
one like adding +1000 to it and that might do the trick. But I would<br>
definitely avoid as much as possible brute forcing it by small steps else your<br>
service will add undesirable load to the network with a lot of upload<br>
attempts.<br>
<br>
Now lets say you are able to pull that off, if I understand your question<br>
correctly, once an onion address goes offline, if the other peer would become<br>
the service then few seconds later, all clients will be able to connect to it.<br>
In other words, launching a new service takes few seconds before it can be<br>
reached. The new descriptor will be used by the directories immediately upon<br>
upload as long as the revision counter is higher than the previous one :).<br>
<br>
Hope this help!<br>
David<br>
_______________________________________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org" target="_blank">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/cgi-bin/mailman/listinfo/tor-dev</a><br>
</blockquote></div></div>