Extended identity fields

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Extended identity fields

Post by domob »

I was contacted by someone interested in extending the NameID profile page. He was kind enough to include his suggestions in the wiki page: http://wiki.namecoin.info/?title=Identity

What do you think, are they ok? If no one has objections, I will implement this in NameID.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: Extended identity fields

Post by virtual_master »

domob wrote:I was contacted by someone interested in extending the NameID profile page. He was kind enough to include his suggestions in the wiki page: http://wiki.namecoin.info/?title=Identity

What do you think, are they ok? If no one has objections, I will implement this in NameID.
Thanks for managing and developing the the Namecoin ID related issues. :)
Since you are doing it it is a great advancement forward by Namecoin.
If you already asked I will tell you what I am thinking.

1. Unfortunately we have only 512 bytes for each entry as some objected to increase the size.
2. We should think about what fields we really need in the entries to support further applications.
I don't think that name entry fields like hobby would be required by any new Namecoin ID implementation.
Entries like 'retroshare', 'torchat', 'torsion', 'torIM' on the other side could be more helpful in this direction to implement NamecoinID based connections by that applications.
3. If we have exhausted the above cases on point 2. we could implement fields which could be more helpful for some other cryptocoiners like 'litecoin', 'peercoin', 'dogecoin' :lol: .
Eventually some from point 3. could enter in the 2.(to become an application implemented by another community)
4. Find other useful fields or attributes which would enhance macroeconomic interactions in the crypto-economy with pseudonymous identities.
I am sure they are a lot of gamers who would like maybe to introduce their pseudonym used by different online games. This could help eventually to spread among the gamer communities.
For such entries like date of birth, social security number or credit card number better if we don't define an attribute field. :lol: At least not in id/.

But we can let a field 'more' or 'other data' where anybody could introduce this if some place left.
Another possibility would be that we let no hazardous fields in the id/ but a field 'link to real ID' where with a link anybody could introduce a link to his Facebook profile, homepage or to another namespace entry (in an own namespace, for ex ri/ - real identity) with attributes defined extra for this purpose.
Here could come also the gender, hobby or photo link attributes also.
To search partners it would be better the u/ or an own namespace.
This could be also chained like id/ -> ri/ -> ph/ where the namespace photo could be only for small 0.5 kB profile photos then everything is in the blockchain.


Of course these are only some logical considerations from my side but maybe others see it from a different point of view.
Last edited by virtual_master on Fri Apr 18, 2014 7:40 am, edited 1 time in total.
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

John Kenney
Posts: 94
Joined: Sat Mar 29, 2014 2:20 pm
os: linux
Location: Sheffield, England
Contact:

Re: Extended identity fields

Post by John Kenney »

I'm not sure listing hobbies on the blockchain is useful. We need firm specs on the date format for 'birthday'.

Also, there's still no specification for the gpg field, can somebody explain exactly how that works on the wiki please.

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: Extended identity fields

Post by domob »

Of course, the new fields will be optional. I believe this person wants to see NameIDs as a kind of "decentralised Facebook". IMHO, everyone should be free to put in the profile what they like (as you mentioned already, the space is limited anyway, so they will have to decide what they think is important). Regarding the "hobby" field, I'm with you that it isn't really important - and I'll implement it last. But I think that country, locality are useful, as well as profile picture, gender and birthday.

BTW, "litecoin" and "ppcoin" are already fields recognised by NameID. ;) (Dogecoin is not, but we can of course add it, too.) GPG keys: Yes, they should really be defined on the wiki page ... the format can be seen in my own value id/domob, for instance, and is based on what the old wiki had. (But it wasn't really explained in detail there, either, mostly by example.)

My thoughts about the suggestions:
birthday: Format should be ISO dates, i. e., 1988-12-18 instead of 1988/12/18 as specified in the wiki for now.
weblog: We already have website, although I realise it is not on the wiki page for now. I suggest we allow this field to have an object with keys as value, so that you can specify multiple "types" of websites. For instance, also your blog if you want to have it explicit.
photo_url: What about making this "pic" and not specifying that it should depict the person, but instead make it a more general "profile picture" or "avatar"?
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

crosser
Posts: 18
Joined: Thu Apr 03, 2014 7:05 am
os: linux
Contact:

Re: Extended identity fields

Post by crosser »

There is an obvious solution to the problem of limited space in the blockchain. Do not keep any data in the blockchain. Instead, only keep an URL (or other "global address") pointing to a "document" containing the data, and the MAC of this document.

The same approach could be used in the DNS, by the way. You could have JSON document for your zone elsewhere, and pointer+MAC for this document in the blockchain. Or alternatively, "translate" that points to a legacy DNS zone, accompanied by "ds" for that zone.

Perhaps we could even have a namespace for "legacy internet", to keep DS records for "legacy" domains, like this:

Code: Select all

i/average.org -> {"ds":[[43804, 5, 2, "B9B264BC7EE92E2DB25E64A1F9F1A2312F80246C02AF52386D9A41219348D07D"]]}
Except what will you do if somebody takes over your name?...
Eugene; id/crosser

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: Extended identity fields

Post by virtual_master »

If picture or photo doesn't matter as anybody will put there what he wants and we are anyway not able to control if it is his real photo or not.
The problem is more that we should think about a reasonable development strategy which will make possible future enhancements, applications and interconnections.
If somebody puts there his birthrate then maybe he also want to put there his skype, QQ, YahooIM address, mobile or land-line number or other interconnection data.
We also discussed about weighting pseudonymous IDs with depositing namecoins on an address given in the id/. We should define a field for that also.
Therefore I would suggest two possible paths:

- We define more fields as the space would enable where application oriented, interconnection and cryptoeconomy type fields would be there but social site type fields(hobby, birthday, gender, picture ...) and everybody elects the most important fields for him.
Here could come twitter like features like 'following' or 'friends'.
If it is not enough space for all what he wish to include then he can chain it with a specially defined field like 'next' another id/ entry or a special namespace entry like 'id2' or 'ri' as described. Where the social type fields would come more in the following chain-member.
This type would fit with the desire of your friend and wouldn't give up the interconnectivity development possibilities of the Namecoin ID.

- The other possibility would be a more clear separation in the definition of namespaces. The social related fields would come in another chained entry even if the id/ have enough space for all wished fields.

In both cases the NameID could show the id/ fields and the chained entry fields also as part of the same ID.

What do you think about ?
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: Extended identity fields

Post by domob »

crosser wrote:There is an obvious solution to the problem of limited space in the blockchain. Do not keep any data in the blockchain. Instead, only keep an URL (or other "global address") pointing to a "document" containing the data, and the MAC of this document.

The same approach could be used in the DNS, by the way. You could have JSON document for your zone elsewhere, and pointer+MAC for this document in the blockchain. Or alternatively, "translate" that points to a legacy DNS zone, accompanied by "ds" for that zone.
Yes of course, that's clear (and has popped up in discussions from time to time). For instance, when discussing an increase in the value field, some argued that we need the field at least large enough to hold a 4096 RSA GPG key. IMHO, that's not necessary, since the key's fingerprint is enough. On the other hand, I think it makes sense to put some basic info still directly into the blockchain (IP addresses and TLS fingerprints for the DNS, for instance). This simplifies application lookups. If someone doesn't want all of that information, one can in principle remove it from the blockchain anyway in a lighter client - it is just not yet implemented. (But neither is a full pointer-hash system.) This idea is something to keep in mind, though, at least for certain applications (especially if they require relatively large data).
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: Extended identity fields

Post by domob »

virtual_master wrote:- The other possibility would be a more clear separation in the definition of namespaces. The social related fields would come in another chained entry even if the id/ have enough space for all wished fields.
This sounds interesting. So you suggest that the ID is basically only for things like key fingerprints and signing addresses (to clearly define the "cryptographic identity" together with a nick name) and to use a separate namespace for "social network" like features? The ID could then link to one (or multiple) social network profiles. Sounds like a nice idea!
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: Extended identity fields

Post by virtual_master »

domob wrote:
virtual_master wrote:- The other possibility would be a more clear separation in the definition of namespaces. The social related fields would come in another chained entry even if the id/ have enough space for all wished fields.
This sounds interesting. So you suggest that the ID is basically only for things like key fingerprints and signing addresses (to clearly define the "cryptographic identity" together with a nick name) and to use a separate namespace for "social network" like features? The ID could then link to one (or multiple) social network profiles. Sounds like a nice idea!
Basically yes. Cryptographic identity and application inter-connectivity fields should be 1. priority in the id/ namespace.
Even inside of this category maybe not all would fit in an id/ space. In that case less used features or less weighted features with a formula
(worldwide usance)*(probability of application implementing NamecoinID).
Of course that can be roughly estimated and those with less weight could come in a chained entry with 2. priority.
It would be nice if a billion user IM like QQ would support NamecoinIDs. We could ask them. !!!
Unfortunately larger public keys like Khal's DSA key can be only linked externally but smaller DSA or or large ECDSA keys maybe could fit in a 0.5 KB entry space.
Social network like features should be more 3. priority and designed from beginning to come in another namespace. Twitter-like features like 'friends' also.

Of course NameID is your project and you have the final decision. It also depends on how is easier for you to implement it.
I just gave some ideas.
Thanks.
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

crosser
Posts: 18
Joined: Thu Apr 03, 2014 7:05 am
os: linux
Contact:

Re: Extended identity fields

Post by crosser »

domob wrote:Yes of course, that's clear (and has popped up in discussions from time to time).
I am sorry, being relatively new here I missed many previous discussions.

Still I think this approach deserves more attention. Trying to cram more data into the blockchain (via separate transactions in separate namespeces or otherwise) is less scalable than "outsourcing" the data and only keeping the addresses and MACs in the blockchain.

Of course if there is not much data to outsource, it's better to just keep it in the blockchain. And here's the point: keep the data in the blockchain until you start running out of space. Once you do, it means that it's time to "outsource".
Eugene; id/crosser

Post Reply