Hi All, As onion (hidden) service operators, what features would you like to see in release 0.2.8? I want to find out what will help onion service operators the most. I think I might be able to finish Rendezvous Single Onion Services, or help finish Rendezvous Handoff, but not both. A Rendezvous Single Onion Service (RSOS) is an onion service that connects directly to the introduction and rendezvous points. For services that don't need to hide their location, it provides better connection latency, and likely better throughput. (And a large RSOS puts less load on the Tor network than a large HS.) See proposal #260 for more information: https://gitweb.torproject.org/torspec.git/tree/proposals/260-rend-single-oni... And for the remaining tasks: https://trac.torproject.org/projects/tor/ticket/17178#childtickets Rendezvous Handoff allows Hidden Services and Rendezvous Single Onion Services to perform the introduction in one tor process, and then handoff the rendezvous to a separate tor process. This allows services to scale beyond the number of rendezvous connections (clients) that a single tor process can handle. We suspect that's about 100 at this point. See proposal #255 for more information: https://gitweb.torproject.org/torspec.git/tree/proposals/255-hs-load-balanci... And for the draft implementation: https://trac.torproject.org/projects/tor/ticket/17254 And the issue it's trying to solve: https://trac.torproject.org/projects/tor/ticket/8902 Some personal background: I have about a week to a month of development time left before I have to start some other work. At this point, it's unclear whether I will be working on Tor or not. So I'd like to maximise the impact of my remaining Tor development time. It would be great if you could help me work out how to do that! Thanks Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
On 27 Jan 2016, at 04:09, Tim Wilson-Brown - teor <teor2345@gmail.com> wrote:
Hi All,
As onion (hidden) service operators, what features would you like to see in release 0.2.8? I want to find out what will help onion service operators the most.
I think I might be able to finish Rendezvous Single Onion Services, or help finish Rendezvous Handoff, but not both.
A Rendezvous Single Onion Service (RSOS) is an onion service that connects directly to the introduction and rendezvous points. For services that don't need to hide their location, it provides better connection latency, and likely better throughput. (And a large RSOS puts less load on the Tor network than a large HS.) See proposal #260 for more information: https://gitweb.torproject.org/torspec.git/tree/proposals/260-rend-single-oni... And for the remaining tasks: https://trac.torproject.org/projects/tor/ticket/17178#childtickets
Rendezvous Handoff allows Hidden Services and Rendezvous Single Onion Services to perform the introduction in one tor process, and then handoff the rendezvous to a separate tor process. This allows services to scale beyond the number of rendezvous connections (clients) that a single tor process can handle. We suspect that's about 100 at this point. See proposal #255 for more information: https://gitweb.torproject.org/torspec.git/tree/proposals/255-hs-load-balanci... And for the draft implementation: https://trac.torproject.org/projects/tor/ticket/17254 And the issue it's trying to solve: https://trac.torproject.org/projects/tor/ticket/8902
Some personal background: I have about a week to a month of development time left before I have to start some other work. At this point, it's unclear whether I will be working on Tor or not. So I'd like to maximise the impact of my remaining Tor development time.
It would be great if you could help me work out how to do that!
Thanks
Tim
I can do the rendezvous handoff code. It's taking a bit longer than initially planned, mostly because of my terrible time management skills, but it'll definitely be there for 0.2.8. RSOS is your baby, I'd say focus on that one :-) Tom
My votes: 1) Certainly RSOS, please - frankly I'd like that in 2.7 2) Am I correct that OnionBalance is out of scope for this question, but perhaps Donncha can chime in on whether any core features for "OB with placement of distinct descriptors into HSDirs" is in-scope? I'll try to pull my rough plans together and post this week. -a
Me, my personal vote would be for RSOS, but that's mostly a greedy vote to improve latency (and because I think we're a ways from running into a scale issue on our onion site). What would be most beneficial to the network if a lot of non-hidden onion sites start to appear (say, more mainstream news sites), some with large traffic? I'm not sure if that would even be an issue, nor am I sure if it would happen, but it's a thought I have as I continue to share our onion site with my friends and counterparts. (My gut & basic understanding of the proposals says RSOS.) Mike Tigas News Applications Developer, ProPublica https://www.propublica.org/ @mtigas | https://mike.tig.as/ | 0x6E0E9923
On 28 Jan 2016, at 15:11, Mike Tigas <mike@tig.as> wrote:
Me, my personal vote would be for RSOS, but that's mostly a greedy vote to improve latency (and because I think we're a ways from running into a scale issue on our onion site).
What would be most beneficial to the network if a lot of non-hidden onion sites start to appear (say, more mainstream news sites), some with large traffic? I'm not sure if that would even be an issue, nor am I sure if it would happen, but it's a thought I have as I continue to share our onion site with my friends and counterparts. (My gut & basic understanding of the proposals says RSOS.)
RSOS reduces the number of hops between the client and onion service from 6 to 4. (With circuit cannibalisation, the hop counts can actually be as high as 8 or 6.) So it is better for latency, and puts less load on the Tor network. Rendezvous Handoff means that each Tor rendezvous goes through a Tor instance with a different set of guards. This overloads particular relays less, and loads each Tor onion service instance less. But this effect can be partially achieved with OnionBalance, or with Alec's "multiple onion services with the same key" failover arrangement. (Do you have a catchy name for this, Alec?) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
participants (4)
-
Alec Muffett -
Mike Tigas -
Tim Wilson-Brown - teor -
Tom van der Woerdt