On 27 Jan (09:04:51), chelsea komlo wrote:
> Hello!
>
> I have some more thoughts on versioning, specifically in regards to the
> possibility of not including the version in the onion address and using
> only the version field in the descriptor.
>
> I'm not able to write out these scenarios now but I will do this in the
> next day. Thanks for making last call!
Here is some extra pressure for you ;).
The HSDir fetch/post URL has gone in 0.3.0 (feature freeze today in theory ;)
with the version in it:
--> /tor/hs/<version>/publish
So few things. First, if we don't have the version in the onion address, this
means the client needs to try to fetch the descriptor for multiple version
that is starting at the highest it knows and then going down as it's failing.
That, I'm really not too keen to this, uneeded load on the network.
Second thing is that HSDir might not all support the same version by the time
we roll out prop224 thus the importance of having it in 0.3.0 (a version
*before* the next gen release). Even with that, this is going to be an
interesting experiement to have a set of HSDir supporting v3 and a set not
supporting it because we kind of have this requirement of using 3 nearest
relays for a replica but what if one of them doesn't support v3?
Third thing, we could have a fix for this with a single descriptor supporting
multiple version but then this has implication outside the onion address
discussion and unfortunately 0.3.0 material again (that freezes today).
So I'm eager to hear your idea on this! But it's important to keep in mind
that 0.3.0 has already some building blocks with some version restrictions :S.
Changing those would mean delaying adoption by a 6 months (and it could be
OK!).
Thanks!
David
>
> Chelsea
>
>
> On 01/27/2017 08:09 AM, George Kadianakis wrote:
> > David Goulet <dgoulet@xxxxxxxxx> writes:
> >
> >> On 24 Jan (14:27:43), George Kadianakis wrote:
> >>> s7r <s7r@xxxxxxxxxx> writes:
> >>>
> >>> <snip>
> >> I like this quite a bit! Simple, easy, and trivial to understand. 56
> >> characters address, after that it will be the time to improve UX/UI with all
> >> sorts of possible tricks to make them easier to remember or copy paste or
> >> visualize or what not.
> >>
> >> Unless some feedback NACK this, I say push that in the proposal soon. I'll
> >> personally start implementing that scheme this week.
> >>
> >> Thanks!
> >> David
> >>
> > Hello,
> >
> > I made a torspec branch that alters prop224 accordingly:
> > https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop224-onion-address&id=50ffab9903880acf55fe387f4d509ecb2aa17f95
> >
> > I will merge this to torspec RSN if I don't hear any grave objections.
> >
> > Cheers!
> > _______________________________________________
> > tor-dev mailing list
> > tor-dev@xxxxxxxxxxxxxxxxxxxx
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
--
4lcjj+AhsleqJZQFfBojoNAIyPbpK6NoCJjCKxAzWoA=
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev