For our application (a messaging app) it would be super useful to get the full list of known online (or recently seen online) onion addresses in possession of some frontend key. This would let us use onionbalance for peer discovery instead of blindly trying the set of all known peers, which won't work well for large groups / large numbers of peers.

On Mon, Jun 14, 2021 at 6:25 AM George Kadianakis <desnacked@riseup.net> wrote:

Chad Retz <chad.retz@gmail.com> writes:

> A quick glance at the code shows that ADD_ONION (i.e. "ephemeral"
> onion services) doesn't support setting an Onionbalance
> frontend/master onion address (specifically
> https://gitlab.torproject.org/tpo/core/tor/-/issues/32709 doesn't seem
> to have a control-side analogue). Would a feature request for adding a
> `*(SP "OnionbalanceMasterKey=" OBKey)` (or "OBMasterKey" or whatever)
> to ADD_ONION be reasonable? If so, just add in Gitlab?
>

Hell Ched,

that's indeed something that is missing and a reasonable feature
request. A spec/code patch would be particularly welcome ;)

> Also curious alternative scalability and load balancing options for
> ephemeral v3 onion services. I have read
> https://www.benthamsgaze.org/wp-content/uploads/2015/11/sucu-torscaling.pdf
> but unsure if anything more recent has been written. Beyond that and
> Onionbalance, any other interesting approaches I could employ
> (assuming I can dev anything from a control port pov, but am wanting
> to work w/ an unmodified Tor binary)?
>

Another complementary approach is to split the 'introduction' and
'rendezvous' functionalities to different hosts:
https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/255-hs-load-balancing.txt
However it hasn't been implemented yet...

Cheers!
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev