Namecoin Forum

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.

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.

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.

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.

Storing extra data is done with "import"; it's valid for all JSON-based namespaces. (Not sure where this is documented.)

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

I like it justusranvier. The specs need reorganising for both id/ & d/ looks like you've made a good start for id.

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.

John Kenney wrote:One thing the onename guys have that is missing in id & justusranvier's proposal is social network profiles.

I don't understand why you would say that is missing from this proposal:

https://github.com/opennamesystem/opens ... c5f87218e7

Take a look at the "Site" array and the "Username" array.

justusranvier wrote:

John Kenney wrote:One thing the onename guys have that is missing in id & justusranvier's proposal is social network profiles.

I don't understand why you would say that is missing from this proposal:

https://github.com/opennamesystem/opens ... c5f87218e7

Take a look at the "Site" array and the "Username" array.

Sorry, I missed that bit.

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.

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.

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.

If someone really wanted to store a url for their key then they could use the Site array.

John Kenney wrote:I'm not sure all the other attributes are necessary

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.

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.

John Kenney wrote:what's the 'G', 'PG', etc under avatar?

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: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.

Maybe the objects can have an "attributes" attribute, where the list of attributes is a comma-seperated string.

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.

I agree that if that should be done, the verification proofs should be stored in a new namespace.