Re: [tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

[grarpamp <grarpamp@xxxxxxxxx>]

Skimming thread...

Version or not is fine, provided if you want versions you
know you must store the bits somewhere, or ensure regex
parser rules to recognize and match an intrinsic version
represented by entire address format specification itself.

Note onion search spiders rely on such address recognition
and parsing. So it's not all just about the browser brain urlbar.

GPU capacity hasn't hit 16 char yet, mnemonic
brain memory has, but that's only happened based on
address luck and/or GPU prefixing. We're more or less
at the limits, new random bits past 16 won't matter and
shouldn't be considered much an argument to brain relavance.
Some other brain layer will come along, and if not, there's
always search.

If version goes in address, I'd wary against putting it last.
A lot of things naturally sort and route and default based
on higher order bits appear prefixing on the left.. IPv4 IPv6
bitcoin PTR DHT filesystem unix tools... the list goes on.
A single leading character is not a problem and gives
plenty of bits of version capacity regardless of encoding.
Trailing version just plain feels shaky to rely on or to
advocate to the world as a new standard. Certainly
not without consultation with other anonymous overlay
projects as to their future needs and direction as well,
or to develop such an interop standard.

At least until bumping against DNS length limitations,
all lower case should be obvious, without symbolics,
without nonprintables, etc.
Try to stick to most common compatible [a-z0-9]
or less unless forced otherwise.

Don't try to create new parsing headaches for application
authors / porters to work around who might already
be using rather basic charsets and routines with
existing protocols.

Whatever works.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev