How many and which usernames have been set aside by the dev team, and how were the decisions made to offer them to select people?
It seems to me that you will very quickly run out of useful names and instead get confusingly similar names. It gives the illusion of human-readable, but its really not. Refer to xkcd 1279 for why this becomes an issue :)
The bitcoin integration is flawed; People don't have one wallet address, any wallet can generate hundreds or thousands of addresses. Remember, there is no message you can send with a bitcoin payment so what you are expected to do is create a new bitcoin address for every payment you want made out to you.
What is with the limitation of only supporting 'a-z0-9' ? Swedes and Russians would probably appreciate a much larger set of characters. Not to mention Klingons!
1) Every username system has some limitation on usernames. Look at Twitter. There are 650 million twitter users, and all of them picked usernames in the same global namespace. This demonstrates that using a global namespace is quite doable.
2) You're right, people usually have multiple Bitcoin addresses and quite a few people prefer to use different addresses for different transactions. However, the protocol is extensible and is not limited to a single address. In the future, the protocol will support a list of bitcoin addresses instead of a single address. Further, you can use a hierarchical bitcoin address and direct people to different addresses in the hierarchy. In that sense, the bitcoin address listed is just a way to identify the tree of addresses the user owns. Last, the protocol supports data to be linked to from the blockchain, so if you want, you can have a next pointer lead to an API endpoint that returns a different bitcoin address every time.
3) As far as supporting only [a-z0-9_], those are the characters that most username systems support, including twitter. Some say this is due to the fact that those are the only "word" characters. Also, using this set makes it more difficult to confuse addresses. The domain name system has similar restrictions for similar reasons. I know that international readability takes a bit of a hit, but I'm sure we'll find ways to improve the experience. We're all up for suggestions.
I need my breakfast now
"P.S. The passphrase you wrote down earlier is the secret key that gives you access to your username and profile. We don't have a copy of this key, so if you lose it, your username will be lost forever. Just in case that happens, though, we've created a backup code for you. When combined with our own backup code, your secret key will be able to be recovered. Here it is: [redacted]"
I don't understand why the service is emailing out this key.
Admittedly, though, using SHA256(passphrase) without a salt to derive a key makes dictionary attacks easier than the others.
Where is that wallet located? Are you a wallet supplier on that website too?
Is there any way this can be a truly open-source project? Right now the "protocol" is open, but if wanted to host my own front-end for me and friends then I'm out of luck.
That would be awesome, and there would be a million other applications besides. The problem is "onename.io" is a central point, both for failure and attack. If others could run this same pretty frontend, then there could be third field on that page for "onename endpoint", which would default to "onename.io" but could be anything. I could have my own personal instance, my employer could run one, my ISP for my neighborhood, etc... Farther down the line it could even be something built into a browser or OS, where you can specify custom default endpoints just like you do with DNS.
I don't really have any say with what you've created, it's your thing and you do with it as you see fit. But in my opinion your "pretty front end" is the best one so far, and I think could actually have appeal outside of crypto-geek-world. You just need to open-source it :P
I love your pgp-messenger idea - you should do it!
And you're right - the pretty front end is a big component. Two things, though - 1) we're working on open sourcing the profile crawler 2) it shouldn't be that difficult to roll your own pretty front end.
In the meantime, if you're somewhat tech savvy, you can update your profile as follows:
1) download/install Namecoin-Qt or Namecoind
2) use the OneName profile builder and grab the JSON
3) calculate your WIF formatted private key from the passphrase (just a sha256 then a conversion to base58check - you can use https://github.com/halfmoonlabs/coinkit for that)
4) import your WIF into your namecoin client (you should now see the username in your possession)
5) perform a "name update" operation with the new JSON profile data
Source : http://www.reddit.com/r/Bitcoin/comments/201g66/onename_the_...
Do different namespaces exist? DNS at least gives a ton of different options, so if a top-level domain you like is taken, you just use .net, .org, etc.
The global namespace seems like it might get crowded really fast. How to prevent that?
You're right, the global namespace very well might get crowded, but we'll see how it plays out.
Forced namespacing is just a poor solution. Users can add whatever namespaces they want to their own username if they want to, after all, it's just a string.
For everyones reference however, should we include the spaces when applying the sha256, or should it be one continuous string which we hash.
eg. sha256("police helicopter apple") or sha256("policehelicopterapple")
Using my passphrase, I can successfully generate a sha256 and then import my bitcoin client, which then provides the same bitcoin public address as shown on my profile (I left it as the default on profile creation).
This shows that I have calculated the hash on the correct passphrase (no errors). However when importing the same key into namecoin-qt I'm getting "Invalid private key (code -5)".
Am I doing something fundamentally wrong, the key should be able to be imported into both -qt clients right? One for the ownership of the bitcoin address and the other for ownership and management of the u/name. I'm determined to get my head around this
Ok it looks like Armory will happily accept the 64 long private key, but namecoin-qt seems to prefer the 51 long keys. Perhaps in 'wallet import format'. No error anymore, still trying to determine if its worked though.