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

[Linda Naeun Lee]

On 2017-01-23 07:50, George Kadianakis wrote:
> George Kadianakis <desnacked at riseup.net> writes:
> 
>> Hello list,
>> 
>> <snip>
>> 
>> [D3] Do we like base32???
>> 
>>       In this proposal I suggest we keep the base32 encoding since 
>> we've been
>>       using it for a while; but this is the perfect time to switch if 
>> we feel
>>       the need to.

I am generally in favor or keeping the same encoding unless there is an 
unmistakable and objectively advantageous reason to switch. It throws 
users off when there is an "unnecessary" switch. Additionally, .onion 
addresses of variable lengths might be confusing.


>>       For example, Bitcoin is using base58 which is much more compact 
>> than
>>       base32, and also has much better UX properties than base64:
>>          https://en.bitcoin.it/wiki/Base58Check_encoding#Background

Is the better "UX" the fact that "A set of 58 alphanumeric symbols 
consisting of easily distinguished uppercase and lowercase letters (0OIl 
are not used)"? Currently, the addresses are too long to memorize, hard 
to type out, and not pronounceable enough, to consider such properties.

But for the sake of discussion, if we were to consider some usability 
properties, but I think base 32 is "easier to use" because it doesn't 
use both upper and lower case letters.

Base 32 (RFC 4648 Base32 alphabet): ABCDEFGHJKLMNPQRSTUVWXYZ234567
Base 58: 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz

My justification is that it would be harder to memorize upper/lower case 
letters in addresses, that it's hard to type with alternating cases, and 
there isn't a good way to distinguish the two when you pronounce it.

That being said, I stand by my original stance that the addresses are 
too long to memorize, type, or pronounce, so this shouldn't be a huge 
consideration. So I vote to keep the base32 encoding for the reason of 
keeping it the same as it was before.

>>       ...but I could be persuaded that now is the time to use a better
>>       encoding.

I won't be persuading you. :) Thanks for doing good work!

Cheers,
Linda

-- 
Current Key: https://pgp.mit.edu/pks/lookup?search=lindanaeunlee
GPG Fingerprint: FA0A C9BE 2881 B347 9F4F C0D7 BE70 F826 5ED2 8FA2