[tor-dev] prop224: What should we do with torrc options?

chelsea komlo me at chelseakomlo.com
Sun Nov 27 18:07:02 UTC 2016


>> Yes, the onion-service-version and the version of the descriptor that tor
>> publishes are now tightly coupled, comparing v2 and v3.  However, this may
>> not always be the case and, indeed, was not the case previously. I'm not
>> saying HiddenServiceVersion is not the correct torrc option, but please keep
>> these problems in mind. Also, realize that the current torrc syntax allows
>> multiple versions (so it would allow tor create both a v2 and v3 descriptor,
>> and if this is used for onion service creation, it could create both v2 and
>> v3 rend services).
> That's another possible thing we could do but it has some possible UX
> consequences. Let's say we have a tor version that by default creates both
> version for a configured HS. You would end up with two addresses for the same
> service and then the operator broadcast those somehow to their users.

I think the "multiple address window" is something we should try to
minimize, and consider how to avoid entirely for future versions if
possible, especially if multiple versions could be supported at once
(v3, v4, and v5, for example).

As an operator, I would need to publish multiple addresses for the same
service, and communicate which address corresponds to which version.

As an end user, I will either need to 1) try different addresses until
one succeeds, or 2) know my current version and use this knowledge when
selecting which address to use. Sharing addresses could also be
difficult (I might try to share a v3 address with my friend, but it
doesn't work for them because they are on v2). It might be good to do
user testing to see what other edge scenarios come up, what is
hard/confusing, etc.

Maybe it's impossible to avoid this for the v2 to v3 transition, but
minimizing this seems like a good thing to do!

All best,

More information about the tor-dev mailing list