On Fri, 7 Apr 2017 11:44:03 +0100 Alec Muffett alec.muffett@gmail.com wrote:
If I was in charge, I would say that we risk overthinking this, and it would be better to:
- mandate use of fully DNS-compliant syntax, including but not
limited to: acceptable max length, max label length, charset and composition
Fully DNS-compliant only limits max length and max label length, unless there's something that supersedes RFC 2181. I'm fine with both of those restrictions.
- declare a registry of short, valid labels, in the
second-from-right position in the name
- reserve "tor" and "name" in that registry (ie: *.tor.onion,
*.name.onion)
- park the entire issue for 12 months
I intentionally left a lot of this unspecified because one of the use cases I envisioned was an "/etc/hosts" analog that lets users easily:
* Stick all their hidden services under their own name hierarchy.
eg: git.yawning -> <long public key>.onion
* Increase mobile quality of life by aliasing their HSes to addresses consisting entirely of emojis.
eg: 💯👏💩👏🖕.😫 -> <long public key>.onion
* Force redirect any site to anything else, really.
eg: git.example.com -> <long public key>.onion banner.ads.and.malware.example.com -> 127.0.0.1 social.spacebook.trackers.example.com -> 127.0.0.1
I could do this with MapAddress, but a plugin would make my life easier, especially since it beats editing multiple torrc files.
(Going further into this rabbit hole, I assume most exits won't resolve the OpenNIC TLDs... What do I do if I want to view `example.pirate` or whatever over Tor?)
Hence "parking" the issue because this is all meaningless until prop224 addresses ship, and there should be plenty of time in the next 12 months for people to think about how to fill the usability space with $PET_IDEA, and to my mind the changeover period between 80-bit and 256-bit addresses should be long enough that nobody need fret about it right now.
IMO the existing onion addresses already are a usability disaster. It should be easy for researchers to experiment with designs to solve the problem *now* before prop224 addresses make a bad situation worse.
There's also a world of difference between implementing/shipping the capability to override the name resolution via plugins, and "Shipping the YawningCoinNamezTLD plugin with Tor Browser, enabled by default".
Regards,