On 2017-12-31 at 14:23:39 +1100, teor <teor2345@xxxxxxxxx> wrote:
Please read the naming layer API proposal before writing your proposal: https://gitweb.torproject.org/torspec.git/tree/proposals/279-naming-layer-api.txtIn particular, if you added a unique top-level domain (.bech?), you would only have to specify how a the bech translation plugin works. (It would be a much shorter proposal.)
Thanks, teor. I reviewed the spec (version 13cbcbc) carefully, and opened https://trac.torproject.org/24774 attaching a `git diff` patch with proposed changes.
The crux of the matter is support for what I will call alternative name representations. Prop-279 assumed quasi-DNS names resolved through some sort of a network or database lookup. However, an alternative representation can be entirely self-contained. Thus, one of the changes I request is to explicitly permit a global wildcard '*' tld for plugins which can be sandboxed with neither network nor filesystem access (and will return answers in microseconds).
I also proposed changes to permit the UTF-8 characters required for representing names in languages other than American English, and some other technical improvements. I added status code 5 to support plugins which can discern when a name is in a recognized format, but is intrinsically invalid e.g. due to checksum failure; and I expanded the description of status code 2, for plugins which do not have TLDs but do recognize a definite syntax.
The potential use cases here extend beyond my suggestion for Bech32-coded .onions. I also wish to encode .onion addresses in a mnemonic phrase, similar to those generated by this tool:
easyseed(1) BIP 39 mnemonic phrase generator https://github.com/nym-zone/easyseed manpage: https://raw.githubusercontent.com/nym-zone/easyseed/master/easyseed.1.txtOut of the box, that will make a mnemonic from the raw data for a v3 .onion address, but not v2 (too short). I could easily draw up a spec to represent v2 .onions as 8 words, and v3 onions as 24–25 words, each including a simple checksum. The mnemonic standard I’ve been using includes carefully designed wordlists for nine different languages; I will soon be adding multilanguage support to my tool, which I could copy over to a prop-279 name system plugin.
Now, imagine an activist under a repressive régime whispering in the ear of a whistleblower eight words for the address of a SecureDrop. Or scrawling a Bech32 address on a scrap of paper in a hurry. The possibilities are many.
Should my proposed changes be accepted, I will be eager to write tools and plugins for .onion alternative representations which look either like this (a real address, properly encoded in Bech32):
onion1kt50trm0nf4jxkskpcjy74...or approximately like this (random words off a wordlist, for example only):
mad century mirror awkward glory shine cake fat...with out-of-the-box support for Chinese (Simplified), Chinese (Traditional), French, Italian, Japanese, Korean, and Spanish, in addition to English.
Wordlists, all designed to minimize user error: https://github.com/bitcoin/bips/tree/master/bip-0039(In the English list, all words are unique within the first four characters; and similar/confusable words are excluded.)
Given appropriate prop-279 changes, I won’t need to draw a proposal. I’ll simply write code!
-- nullius@xxxxxxxx | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested: 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE) “‘If you’re not doing anything wrong, you have nothing to hide.’ No! Because I do nothing wrong, I have nothing to show.” — nullius
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev