[tor-dev] Comments on proposal 279 (Name API)
nickm at torproject.org
Mon Apr 3 12:50:01 UTC 2017
On Mon, Apr 3, 2017 at 8:20 AM, George Kadianakis <desnacked at riseup.net> wrote:
> Nick Mathewson <nickm at torproject.org> writes:
>> Section 2.1 and elsewhere:
>> I suggest that we require all address suffixes to end with .onion;
>> other TLDs are not reserved like .onion is, and maybe we shouldn't
>> squat any we haven't squatted already. I think we might also want to
>> have all output addresses end with .onion too.
>> I suggest also that we might want to reserve part of the namespace
>> for standardized namespaces and some for experimental or local ones.
>> Like, if we standardize on namecoin that could be .bit.onion, but if
>> we don't, it could be .bit.x.onion.
> I have mixed feelings about keeping the .onion suffix.
> One one hand it seems like The Right Thing to do, since we managed to
> get .onion standarized in the IETF which comes with various
> benefits. Also, starting to squat other tlds arbitrarily seems like a
> silly thing to do.
> However, I also dislike asking users to visit something.bit.onion
> instead of something.bit, since people are not used to the second tld
> having a semantic meaning, and I can imagine people getting very
> confused about what it means.
Indeed. And I'm not only concerned about people becoming confused: I
am also worried about confused programs.
Right now, it is easy to answer the question "will Tor handle this
address specially" -- the only special addresses are the ones ending
with ".onion", and the legacy suffices ".exit" and ".noconnect" as
documented as address-spec.txt. But if we allowed arbitrary TLDs in
this proposal, then _any_ hostname would potentially be an address
that Tor would handle specially.
More information about the tor-dev