Memorable email addresses?

[dcposch]

We would like people to be able to memorize their (generated) email address.

This would have significant benefits:

• Your username is your email address. Easier for new users to understand, vs having username, passphrase, and a hash email address.
• You don't pick your username, it's generated. Better anonymity by default.
• Users memorize their own email address, so they can give it to others more easily.

One cool way to create memorable email addresses would be to generate an English-looking phrase from the hash.

For security, the email address must encode the hash of the public key. It must encode enough bits to avoid collision attacks---currently 80 bits, same hash format as Onion URLs.

These hashes are unfortunately not memorable. But what if we created long lists of common nouns, adjectives, adverbs, and so on?

Then we could map our 80-bit hash to a phrase. For example, with a list of 2^9 adverbs, 2^11 nouns, 2^11 adjectives, and 2^9 verbs etc, we can map 80 bits as follows:

adverb-adjective-noun-adverb-verb-adverb-adjective-noun@scramble.io

I tested this out this morning. I got a list of common words: http://invokeit.wordpress.com/frequency-word-lists/ I got a part-of-speech database: http://wordlist.sourceforge.net/

I wrote a Python to combine both into a list of the most common nouns, most common verbs, and so on. Unfortunately, it looks like the resulting phrases are too ugly and still not memorable enough:

sometimes-fanatical-wynn-rudely-avenge-afterward-interplanetary-moulin
fondly-difficult-booking-gradually-arise-visually-hazy-alchemy

If anyone has a solution, let me know. @jaekwon

[jaekwon]

4 adjectives & 4 nouns, and let the user choose the association & order? That's almost 79 bits if my math is right.

Using adjectives & nouns from your example, "interplanetary alchemy", "hazy wynn", "difficult moulin", and "fanatical booking" isn't too hard to remember for me.

[jaekwon]

Name resolution is being implemented.

See https://github.com/dcposch/scramble/wiki/Addr-Resolution-via-Notaries for details. See https://github.com/jaekwon/scramble/compare/dcposch:1299b43...addr_resolution for progress.

[jaekwon]

If we really want to go with this solution (which enables token@host), some details on the client need to be planned out.

I'm thinking of adding scramble.io & hashed.im as default notaries for all users, and not even exposing them to the notary calls that will happen in the background as they type in a token@host in the To field. Should either scramble.io or hashed.im go down, the user will see a warning that explains the issue.

I think something like the green lock on browsers next to https: addresses is the kind of UX that ultimately makes sense. If there isn't a consensus from the notaries, users will see something else & probably a warning.

Scramble server administrators should be able to suggest new notaries to the client. Perhaps the user approves them, or if this is too confusing, perhaps the client can silently add the notary as long as there is a consensus from all existing notaries.

Feedback would be much appreciated at this point. I want to avoid going down the wrong rabbithole.

[dcposch]

Yeah, this doesn't seem to work. Tried it. The results are too long to be memorable and too weird to be usable...

[jaekwon]

blah blahblah

On Thu, Oct 24, 2013 at 2:40 AM, DC notifications@github.com wrote:

Closed #16 https://github.com/dcposch/scramble/issues/16.

— Reply to this email directly or view it on GitHubhttps://github.com/dcposch/scramble/issues/16 .