Identity namespace
-
- Posts: 7
- Joined: Fri Jul 11, 2014 4:07 am
- os: linux
Identity namespace
https://wiki.namecoin.info/index.php?title=Identity
Taking a look at the at the specification for the id/ namespace, I can see some things that could be improved.
name should be capable of being specified as an array, just like email
birthdate should be in ISO-8601 format
weblog should be capable of being specified as an array, just like email
Instead of having a seperate bitmessage field, why not put that in the email object array with a Bitmessage: label?
In fact, why not take that a step further and have field for asynchronous messaging addresses (email, bitmessage, freemail, i2p-bote, etc), and a field with synchronous messaging addresses (xmpp, aim, skype, etc) and use type labels to differentiate between them?
That way you don't need to add new fields to the protocol every time somebody wants to add a new use case.
Taking a look at the at the specification for the id/ namespace, I can see some things that could be improved.
name should be capable of being specified as an array, just like email
birthdate should be in ISO-8601 format
weblog should be capable of being specified as an array, just like email
Instead of having a seperate bitmessage field, why not put that in the email object array with a Bitmessage: label?
In fact, why not take that a step further and have field for asynchronous messaging addresses (email, bitmessage, freemail, i2p-bote, etc), and a field with synchronous messaging addresses (xmpp, aim, skype, etc) and use type labels to differentiate between them?
That way you don't need to add new fields to the protocol every time somebody wants to add a new use case.
Re: Identity namespace
I agree. Some of the fields (like the birthday) have been added by someone relatively recently, and not yet gone through a "review process". If you have suggestions, feel free to post them or even update the wiki. There's not yet much out there that depends on the spec, AFAIK, so it is more like a draft at the moment.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
-
- Posts: 7
- Joined: Fri Jul 11, 2014 4:07 am
- os: linux
Re: Identity namespace
I'd like so see some improvements from the u/ namespace merged into the id/ namespace as well.
Linked lists to extend the maximum amount of data that can be stored is a good idea.
Adding a site field that collects (URL,username) tuples would be a better way to store the same data as onename.io.
Linked lists to extend the maximum amount of data that can be stored is a good idea.
Adding a site field that collects (URL,username) tuples would be a better way to store the same data as onename.io.
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: Identity namespace
Storing extra data is done with "import"; it's valid for all JSON-based namespaces. (Not sure where this is documented.)justusranvier wrote:I'd like so see some improvements from the u/ namespace merged into the id/ namespace as well.
Linked lists to extend the maximum amount of data that can be stored is a good idea.
Adding a site field that collects (URL,username) tuples would be a better way to store the same data as onename.io.
-
- Posts: 7
- Joined: Fri Jul 11, 2014 4:07 am
- os: linux
Re: Identity namespace
I've written a reply to the ONS specification on GitHub but it's equally relevant to this project.
Even if NamecoinID uses a different namespace than Onename, it would be highly beneficial if both namespaces could use the same specification.
https://github.com/opennamesystem/opens ... c5f87218e7
Even if NamecoinID uses a different namespace than Onename, it would be highly beneficial if both namespaces could use the same specification.
https://github.com/opennamesystem/opens ... c5f87218e7
-
- Posts: 94
- Joined: Sat Mar 29, 2014 2:20 pm
- os: linux
- Location: Sheffield, England
- Contact:
Re: Identity namespace
I like it justusranvier. The specs need reorganising for both id/ & d/ looks like you've made a good start for id.
-
- Posts: 94
- Joined: Sat Mar 29, 2014 2:20 pm
- os: linux
- Location: Sheffield, England
- Contact:
Re: Identity namespace
One thing the onename guys have that is missing in id & justusranvier's proposal is social network profiles.
I'd like to get to a place where onename are using id/ & can act as (one of many) verifiers for a web of trust to verify some of the information stored in id.
I'd like to get to a place where onename are using id/ & can act as (one of many) verifiers for a web of trust to verify some of the information stored in id.
-
- Posts: 7
- Joined: Fri Jul 11, 2014 4:07 am
- os: linux
Re: Identity namespace
I don't understand why you would say that is missing from this proposal:John Kenney wrote:One thing the onename guys have that is missing in id & justusranvier's proposal is social network profiles.
https://github.com/opennamesystem/opens ... c5f87218e7
Take a look at the "Site" array and the "Username" array.
-
- Posts: 94
- Joined: Sat Mar 29, 2014 2:20 pm
- os: linux
- Location: Sheffield, England
- Contact:
Re: Identity namespace
Sorry, I missed that bit.justusranvier wrote:I don't understand why you would say that is missing from this proposal:John Kenney wrote:One thing the onename guys have that is missing in id & justusranvier's proposal is social network profiles.
https://github.com/opennamesystem/opens ... c5f87218e7
Take a look at the "Site" array and the "Username" array.
It looks like you've missed out an url for a public key. The current id spec allows a gpg fingerprint & an url to link to your public key.
I'm not sure all the other attributes are necessary, what's the 'G', 'PG', etc under avatar? Also not sure on the best syntax, JSON is attribute & value pairs, not type, attribute, value, maybe "type" needs to be the first attribute? So like "name":[{"type":"personal","legal":"John Kenney"}] ? Or maybe they could be nested? My json isn't too hot either.
Onename are also doing some verifications of websites & social media profiles. We need a way to store these verifications (and others), along with the identity of the verifier. I think that might be best done in a new namespace.
-
- Posts: 7
- Joined: Fri Jul 11, 2014 4:07 am
- os: linux
Re: Identity namespace
Why would you need a url to a public key if the fingerprint is specified? The essential information that needs to be stored in this record is the association between a fingerprint and an identity. Actual key lookups can be done through existing key servers.John Kenney wrote:It looks like you've missed out an url for a public key. The current id spec allows a gpg fingerprint & an url to link to your public key.
If someone really wanted to store a url for their key then they could use the Site array.
An essential aspect of this proposal is that is uses a type/attribute/data model exactly because it means there is no need to specifiy every type/attribute ahead of time. Conforming implementations of the spec should gracefully handle any data that is properly formatted, even if they've never seen the particular attribute or type before.John Kenney wrote:I'm not sure all the other attributes are necessary
You'll never figure out all the kinds of attributes or types that users will want ahead of time, so it's best to not even try. What I listed in the proposals are examples.
Those are features from Gravatar. Given how popular they are in the hosted avatar business, whatever they are doing is probably right.John Kenney wrote:what's the 'G', 'PG', etc under avatar?
Maybe the objects can have an "attributes" attribute, where the list of attributes is a comma-seperated string.John Kenney wrote:Also not sure on the best syntax, JSON is attribute & value pairs, not type, attribute, value, maybe "type" needs to be the first attribute? So like "name":[{"type":"personal","legal":"John Kenney"}] ? Or maybe they could be nested? My json isn't too hot either.
I agree that if that should be done, the verification proofs should be stored in a new namespace.John Kenney wrote:Onename are also doing some verifications of websites & social media profiles. We need a way to store these verifications (and others), along with the identity of the verifier. I think that might be best done in a new namespace.