Length is not nearly as important as bookmarkability. You mentioned that you are going to be changing stuff every day. That worries me.
his service. Though, the effect of this is limited, because descriptor ids are automatically changed every day. My idea was to use 32 bits for the service id.
Your other ideas: Breaking things into parts:
For downward compatibility reasons, those 200 bits could also be distributed by using 80 bits for the service id and 120 bits for the secret key. Then, people could start using the new descriptor by simply adding a dot and a secret cookie to their current (unchanged) onion address. This would look like this: http://6sxoyfb3h2nvok2d.6sxoyfb3h2nvok2d6sxoyfb3.onion/
I like this much, much more.
Maybe we shouldn't even extend the onion addresses at all, but allocate the 80 bits in another way, e.g. 24 bits for the service id and 56 bits for the secret cookie? Then we should use another virtual top level domain to distinguish current and new descriptors, resulting in something like the following: http://6sxoyfb3h2nvok2d.hidden/
I think this is the best. Use the current system for sites using the old method (central servers mapping .onion addresses to introduction points), and a onion.secretkey.hidden for stuff using the new, non-central servers.
What do you guys prefer? How do you exchange onion addresses? Publishing them on non-hidden web pages, pasting them to IRC chats, writing them on business cards, memorizing and telling them, ...? I think it's important to find a balance between security and usability here.
Business cards? Hadn't thought of that. Yea, that would give a bonus to short.
