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 had some thoughts about a more-general solution for that before. This is probably relevant:

If you can simplify it to just attribute=value, by removing some of the less necessary types & combining them with attributes then it'll make the json much simpler. Need short simple attribute names too. Space is limited & we don't want to add too much overhead. A fairly long list of different attributes isn't a problem & I think some of the types you've listed are unnecessary.

We should add a new namespace for companies, groups & organisations too, that contains information about the organisation & links to the id of it's members. Maybe organisations could be done under id/, but I think they should be separate to people & linked, have namecoin behave more like a relational database, treat each namespace like a table that is linked to the other tables. Maybe I'm just too stuck in my old SQL ways.

I think we should link d/ to id/ (or the new org space) as well, ideally require an id/ to register a d/ & have the id/ of the owner as a required value for the d/, replacing the email value with a link to their namecoin id that has full contact details.

John Kenney wrote:and a new namespace for organisations with similar attributes to id.

Why would organizations need their own namespace? Is there a reason why they can't just use id/? I'm already using id/ for an organization I'm affiliated with. Organizations have identities just like people do, and as you say, the attributes stored are pretty much the same. Also, some users may not wish to publicly disclose whether they're an organization or a single person... so why make them choose?