[tor-dev] Scalability or Onionbalance for v3 ephemeral/ADD_ONION services
desnacked at riseup.net
Mon Jun 28 11:25:35 UTC 2021
Holmes Wilson <h at zbay.llc> writes:
> Would this return a list of currently-online onion addresses in possession
> of the frontend address key?
> Or would it just route traffic to one of those addresses invisibly?
I think the feature that Chad was asking for would just allow them to
enable OnionBalance through the control port (since setting
OnionbalanceMasterKey is a necessary step of configuring onionbalance
> 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.
Hmm, can you please give us some more details on what you are looking
for? What is peer discovery in the above context, and what do you mean
with "full list of ... onion addresses in possession of some frontend
key"? I'm asking because the frontend key of onionbalance is also the
onion address that users should access.
> I'd be interested in working with others on a spec for this!
> On Mon, Jun 14, 2021 at 6:25 AM George Kadianakis <desnacked at riseup.net>
>> Chad Retz <chad.retz at 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
>> > 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:
>> However it hasn't been implemented yet...
>> tor-dev mailing list
>> tor-dev at lists.torproject.org
> tor-dev mailing list
> tor-dev at lists.torproject.org
More information about the tor-dev