To continue a discussion from github @ryan started last month:
I’d like to propose an alternate method in which one could include a list of name servers that are able to return the user data, and then make sure that the data returned is signed by the owning keypair:
{
“nameservers”: [
“172.8.0.1:5000/satoshi”,
“172.8.0.9:9000/satoshi”
]
}
Where the data would be formatted like so:
$ curl 172.8.0.1:5000/satoshi
Message:
{
"profile: {
“name”: “Satoshi Nakamoto”
},
“previous”: “cd372fb85148700fa88095e3492d3f9f5beb43e555e5ff26d95f5a6adc36f8e6”
}
Signature:
HNGhFYwjtfdU4TTAT3+xIYaXmQvmjezks/zH9HETThqL8lZ5RwMBKMst6ThrurEn6J/IzUypfMrDWiw5whjFjfo=
As you can see, the data returned includes a message and a signature. The message includes the profile of the user, as well as the hash of the previously signed message.
This has various pros and cons, which I’ll bring up in a further comment.
Big pro: profile updates are basically free, as they don’t require new transactions on the blockchain.
Con: this adds a good amount of additional complexity in terms of polling nameservers.
I think this makes a lot of sense. Users are used to centralized systems where changes are immediately visible. Profile updates that are free and fast are very important to user experience. I’d go so far as to say the blockchain should only store a pointer to profile data.
Also be worth addressing how we can get initial sign up time down. The ~3 hours delay a new user’s passname is in the blockchain is fine if the only application is the Onename profile viewer, since Onename stores a local copy of the data. It’s a signup conversion killer for a 3rd party site that sends a user to Onename to get a Passcard only for the user to have to wait ~3 hours until they can return and complete the signup process.
Yes, being able to do profile updates for free is a big win. We can’t put “sensitive data” outside of the DHT though e.g., public keys, PGP keys, payment addresses etc. Any change to “sensitive data” should require a new transaction on the blockchain. All other data can be outside of the DHT.
Small modification: Instead of nameservers, we can also think about expressing this in terms of “data storage service”. The reason for this is that static IP addresses are very inflexible for deploying systems – we experienced this first hand when we shipped OpenDig with a few static addresses hardcoded in. We had to go through considerable pain to keep servers at those exact IP addresses available/stable.
So you can express that your data storage provider is say Dropbox or S3 and here is the URI to the public signed data. Private data is a different story and we can get into it. I’m sure @jude will have a lot to say about private data.
@larry how would this appear to the end user? The reason I ask is because we don’t want to create something that could restrict the end user experience.
3rd party app (“Site”) sends user to Onename to get passcard
User registers at Onename
User returns to Site and provides passname…it doesnt work because ~3 hours hasn’t passed yet
User gives up or emails Site support “why doesn’t it work?” (we see this with Pay4Bugs)
Updating Profile:
User updates profile at Onename.
User reloads page with Nametiles and doesn’t see changes (because blockchain changes are slow)
User emails support and says something is broken because they don’t see changes to profile and/or gives up
Hosting profile data off blockchain would improve the user experience in the second example because profile changes would be almost instant like users are accustom to on current services.
