Explore blockchain-id Profile-Schema integration instead of a custom name resolver

[ericwooley]

blockchain-id Profile-Schema already exists, is blockchain based, and has public key support, why not leverage that project for username lookups.

for example my username is
https://onename.com/ericwooley

There is an API for getting a users info, which could be used as a second option to manually looking through the blockchain, which could take a long time.
https://api.onename.com/

{  
   ericwooley:{  
      profile:{  
         avatar:{  
            url:"https://s3.amazonaws.com/kd4/ericwooley"
         },
         bitcoin:{  
            address:"1ABYJjvgXoiQ2eY5Apu59px9Wo8mimPmBy"
         },
         cover:{  
            url:"https://s3.amazonaws.com/dx3/ericwooley"
         },
         facebook:{  
            proof:{  
               url:"https://facebook.com/eric.wooley/posts/10206812517728011"
            },
            username:"eric.wooley"
         },
         github:{  
            proof:{  
               url:"https://gist.github.com/ericwooley/a0e8fe9dcd2e4f8fdecf"
            },
            username:"ericwooley"
         },
         graph:{  
            url:"https://s3.amazonaws.com/grph/ericwooley"
         },
         location:{  
            formatted:"Atascadero California"
         },
         name:{  
            formatted:"eric wooley"
         },
         pgp:{  
            fingerprint:"949DF59F1B8DD286853DCB802DE3727B8E4993F",
            url:"https://s3.amazonaws.com/pk9/ericwooley"
         },
         twitter:{  
            proof:{  
               url:"https://twitter.com/ericwooley/status/652203639109324800"
            },
            username:"ericwooley"
         },
         v:"0.2",
         website:"https://ericwooley.github.io"
      },
      verifications:[  
         {  
            identifier:"ericwooley",
            proof_url:"https://gist.github.com/ericwooley/a0e8fe9dcd2e4f8fdecf",
            service:"github",
            valid:true
         },
         {  
            identifier:"ericwooley",
            proof_url:"https://twitter.com/ericwooley/status/652203639109324800",
            service:"twitter",
            valid:true
         },
         {  
            identifier:"eric.wooley",
            proof_url:"https://facebook.com/eric.wooley/posts/10206812517728011",
            service:"facebook",
            valid:true
         }
      ]
   }
}

One issue with this is that onename.com is obviously centralized, but after some research, I found that you can role you own "resolver" pretty easily. https://github.com/blockstack/resolver
So it may work to make the resolver a config option, in addition to the default option of parsing the blockchain yourself.

[cjb]

Thanks for creating the issue -- this sounds reasonable to me! Would accept a PR with gittorrent:{userid:"aaa..."}. I think we wouldn't need a separate proof if we also amend the user profile published to the DHT to claim the onename username, if that makes sense.

[ericwooley]

Sorry, I am brand new to the project. Still trying to get a feel for the project, but I would like to attempt this issue, to get used to working with the DHT, and especially BEP44, as I have a few other projects that will be using this.

I have been poking around a little bit, looking for the name lookup logic, I see https://github.com/cjb/GitTorrent/blob/master/gittorrentd#L77 and https://github.com/cjb/GitTorrent/blob/master/gittorrentd#L121, but I don't see anything that seems to do lookups based on names from the blockchain, or the list of usernames this repo provides.

Based on https://github.com/cjb/GitTorrent/blob/master/git-remote-gittorrent#L80 it looks like this feature only looks for a 40char hex (hash) and then drops back to git. Am I correct in understanding the name lookup is not implemented yet? Or am I missing something completely obvious?

[cjb]

Nope, you're right, it's not implemented! I started on a JavaScript port of the Python blockstore software (from onename), but using their project directly sounds like a better idea.

[ericwooley]

@cjb

I think we wouldn't need a separate proof if we also amend the user profile published to the DHT to claim the onename username, if that makes sense.

Are you saying that in the DHT, we wouldn't need to attach any additional proof other than providing the username?

I haven't fully thought through all of this, but I think that would be correct. The blockchain could (and should) be checked individually to find the public key once the username is known. Any input before I start working based on that assumption?

[cjb]

@ericwooley Yeah, exactly! Sounds great, thanks very much for looking at this!

We just need to map hash_of_pubkey <=> username. The blockchain does that mapping one way, and if you want the added assurance of having the hash_of_pubkey also specify which username it's associated with (to avoid someone associating their username with someone else's hash) then you can specify that username in the DHT statement, since the DHT statements are signed by the relevant hash_of_pubkey. Hope that made sense, feel free to ask any questions if it didn't. :)

[ericwooley]

Well, in terms if ease of use, this may have become more difficult. the public keys for onename.com are pgp and the BEP44, is eliptic curve. So I need to figure out a streamlined way to store and lookup names.

[ericwooley]

@ryan_onename on the blockstack slack said they are planning to add arbitrary values to one name, which would make registering easy, but until then I am experimenting with blockstack, which would make registering difficult until easier solutions were implemented.

[muneeb-ali]

We're working on the profile schema v3 which is the new version. You can propose the functionality you need and we can take it from there.

Also, blockstore is generic and you can write any key/value pairs to it e.g., in a new namespace. Also, I don't fully understand what you're trying to do and would love to learn more.

[ericwooley]

@muneeb-ali Right now gittorrent works by navigating the dht to find a mutable store, where the key is a sha1 IIRC of a public key from elliptical curve crypto. It uses that store to find a repo, example: gittorrent://<hash>/repoName.

The hash basically maps to a user. When I discovered this project, I saw the plan was to push hashes and username mappings onto the block chain, and thought that onename was basically the same thing, but with different info. Thats how I got to blockstore, and have been working on using blockstore instead of rolling our own scheme.

The main issue, is that its pretty cumbersome to install blockstack just to register your name, or resolve someone elses name. The onename, or equivalant api would suffice for most people, but onename doesn't support arbitrary data yet, once that happens it will be easier to register your name.

I don't think this feature will be used much until the barrier to entry is pretty low. Hopefully one name implements the arbitrary data feature soon, or I may just rollout my own version of it. Doesn't seem to hard, blockstack seems pretty nice.