[Proposal] Public JSON attributes for delegates

[Thom]

Just in case anyone else has struggled with updating their delegate's public_data fields here is a template you can use to get the job done in the CLI wallet or GUI console. In a month or 2 we won't need this but Bytemaster asked all delegates to update their public_data fields in last Friday's mumble so I dutifly complied, tho I truly understand after the experience why so few have bothered.

The last parameter is your payrate so make sure you adjust it accordingly.

Code: [Select]

wallet_account_update_registration delegate.verbaltech delegate.verbaltech {"services":"BitShares investors since 2014","gravatarID":"https://avatars0.githubusercontent.com/u/11077042?v=3&s=460","version":"0.9.2","website":"http://digitalgaia.io/","email":"tfreedman@thecomingbitsharesrevolution.website","delegate":{"role": 3, "handle":"thom, wackou","country":"us, es","description":"Reliable backbone, bts_tools development, technical gurus and writer", "proposal": "https://bitsharestalk.org/index.php/topic,13837.msg227914.html#msg227914"}} 100

Here's how it appears on bitsharesblocks: Delegate Info tab

[xeroc]

Our plans with DPOSHub actually would bring a revival and utility to those fields again.

I hope they will remain and perhaps even become expanded. Maybe this becomes a worker proposal that dposhub brings forward after we collect enough feedback and data to determine what practical fields work best for providing information people need from delegates profiles.

That sounds great! It gives incentive to delegates(witnesses/workers) to publish more information about that as they are more exposed!! Eagerly awaiting DPOSHub!

Just keep in mind that even though this "protocol" is part of the wiki, it does not necessarily mean it is "standardized" or set in stone. It's simply a first step for consensus about how things may be "right".
If you think some fields may be changed or extended, let's discuss. Everyone is open to this and as you seem to be among the first (after gui and bitsharesblocks) to leverage this "protocol" you can assist improving it!

[Thom]

The images are generated based on the account name, but we're using a hash of the account name that I guess is different from what's being input when you use the generator directly on the website, that's why it's different.

The relevant code is here:

https://github.com/bitshares/web_wallet/blob/master/app/js/directives/identicon.coffee

And the hash is generated using this library:

https://github.com/bitshares/web_wallet/blob/master/vendor/js/sha256.js

BitShares Login is much older than these identicons and the public data fields, I believe they wanted to use gravatar in the beginning but it was abandoned early on.

That explains the reason for the difference and provides the components involved, but not the algorithm. I'm only vaguely familiar with node_js, angular or coffee, tho I'm highly experienced with javascript. I poked around but couldn't find the actual code that embodies the processing of an account name into a hash to produce the jdenticon. It may be within identicon.coffee, but I can't tell from looking at that what javascript code is produced. Could it be as simple as generating a hash of the account name (using the sha256.js function) and passing that as the input value to jdenticon?

The BitShares Login was under development around Christmas. I still see a few questions posted related to public_data and gravatar images, but no explicit answers to kencode's questions or which public_data fields svk is displaying on bsb (if any) besides Delegate bid, role, forum name, client country and client version. I presume the "description" field is being displayed as the last value under the PUBLIC DATA column of bsb.

Also, most delegates publish their node's version, is that still done via json in public_data? If so the publisher must preserve all other values in order to update just the one value for version.

[svk]

What value is used to generate the jdenticon? I tried the public keys and acount name on the demo page but those values don't generate an image that matches the wallet. Every registered account has a unique jdenticon image. Is that image accessible through the toolkit API? It must be possible to use info obtained from the toolkit API along with the jdenticon js lib to generate a jdenticon image that matches the wallet image, otherwise how are you displaying the correct image on the accounts page of bitsharesblocks?

I said "abandoned" b/c I saw no further discussion of it and even the BitShares Login code doesn't display the jdenticon image, instead BM pulls from the json public_data. I would like to display the jdenticon images for both server and client in the login process and I need some info on how to do that.   

Where does this effort stand? I seem to recall DataSecurityNode discussing these fields, but can't locate that thread. Moreover, it seems this entire approach was abandoned? The original thread never went anywhere after November, why is that?

In playing around with the example code BM used for testing BitShares Login, the gravatarID was pulled from this public_data, but that's not where the geometric account representation seen on the wallet dashboard is coming from. How is that image determined? Are those account identity images keys in a 3rd party lookup or are they now integrated into the wallet so they will remain constant? If they're coded into the wallet is there a toolkit call to retrieve them?

MethodX just made me realize it isn't very clear how to use these public data fields for your delegate. Here's an example output for his delegate:

Code: [Select]

wallet_account_update_registration marketing.methodx marketing.methodx {"website":"http://www.my-website.com","delegate":{"role":3,"handle":"MeTHoDx","location":"My Location","description":"","proposal":"https://bitsharestalk.org/index.php?topic=11663.0", "version":"v0.4.24"}} 100
To update your delegate you modify this with your data, then copy paste it into your client. You cannot do individual fields, so keep your final version for future use. The 100 is your payrate, adjust accordingly. Any field you do not want to use can be deleted.

role: 3 means he's an independent marketing delegate, you can find the other roles in the wiki link in the OP of this thread.

I'd like to write an example python code for the parameters in
http://wiki.bitshares.org/index.php/Delegate/PublicData

But want to wait until no further changes are 'obvious' to the proposals in the wiki ..

I wouldn't say abandoned, it's still as valid as it was back then but not a lot of delegates decided to take advantage of the options. I enabled some of the fields both in the wallet and on bitsharesblocks, but not everything that's in the wiki.

The images are provided by this js library and will remain constant: http://jdenticon.com/

The images are generated based on the account name, but we're using a hash of the account name that I guess is different from what's being input when you use the generator directly on the website, that's why it's different.

The relevant code is here:

https://github.com/bitshares/web_wallet/blob/master/app/js/directives/identicon.coffee

And the hash is generated using this library:

https://github.com/bitshares/web_wallet/blob/master/vendor/js/sha256.js

BitShares Login is much older than these identicons and the public data fields, I believe they wanted to use gravatar in the beginning but it was abandoned early on.

[Thom]

What value is used to generate the jdenticon? I tried the public keys and acount name on the demo page but those values don't generate an image that matches the wallet. Every registered account has a unique jdenticon image. Is that image accessible through the toolkit API? It must be possible to use info obtained from the toolkit API along with the jdenticon js lib to generate a jdenticon image that matches the wallet image, otherwise how are you displaying the correct image on the accounts page of bitsharesblocks?

I said "abandoned" b/c I saw no further discussion of it and even the BitShares Login code doesn't display the jdenticon image, instead BM pulls from the json public_data. I would like to display the jdenticon images for both server and client in the login process and I need some info on how to do that.   

Where does this effort stand? I seem to recall DataSecurityNode discussing these fields, but can't locate that thread. Moreover, it seems this entire approach was abandoned? The original thread never went anywhere after November, why is that?

In playing around with the example code BM used for testing BitShares Login, the gravatarID was pulled from this public_data, but that's not where the geometric account representation seen on the wallet dashboard is coming from. How is that image determined? Are those account identity images keys in a 3rd party lookup or are they now integrated into the wallet so they will remain constant? If they're coded into the wallet is there a toolkit call to retrieve them?

MethodX just made me realize it isn't very clear how to use these public data fields for your delegate. Here's an example output for his delegate:

Code: [Select]

wallet_account_update_registration marketing.methodx marketing.methodx {"website":"http://www.my-website.com","delegate":{"role":3,"handle":"MeTHoDx","location":"My Location","description":"","proposal":"https://bitsharestalk.org/index.php?topic=11663.0", "version":"v0.4.24"}} 100
To update your delegate you modify this with your data, then copy paste it into your client. You cannot do individual fields, so keep your final version for future use. The 100 is your payrate, adjust accordingly. Any field you do not want to use can be deleted.

role: 3 means he's an independent marketing delegate, you can find the other roles in the wiki link in the OP of this thread.

I'd like to write an example python code for the parameters in
http://wiki.bitshares.org/index.php/Delegate/PublicData

But want to wait until no further changes are 'obvious' to the proposals in the wiki ..

I wouldn't say abandoned, it's still as valid as it was back then but not a lot of delegates decided to take advantage of the options. I enabled some of the fields both in the wallet and on bitsharesblocks, but not everything that's in the wiki.

The images are provided by this js library and will remain constant: http://jdenticon.com/

[BunkerChainLabs-DataSecurityNode]

Where does this effort stand? I seem to recall DataSecurityNode discussing these fields, but can't locate that thread. Moreover, it seems this entire approach was abandoned? The original thread never went anywhere after November, why is that?

In playing around with the example code BM used for testing BitShares Login, the gravatarID was pulled from this public_data, but that's not where the geometric account representation seen on the wallet dashboard is coming from. How is that image determined? Are those account identity images keys in a 3rd party lookup or are they now integrated into the wallet so they will remain constant? If they're coded into the wallet is there a toolkit call to retrieve them?

MethodX just made me realize it isn't very clear how to use these public data fields for your delegate. Here's an example output for his delegate:

Code: [Select]

wallet_account_update_registration marketing.methodx marketing.methodx {"website":"http://www.my-website.com","delegate":{"role":3,"handle":"MeTHoDx","location":"My Location","description":"","proposal":"https://bitsharestalk.org/index.php?topic=11663.0", "version":"v0.4.24"}} 100
To update your delegate you modify this with your data, then copy paste it into your client. You cannot do individual fields, so keep your final version for future use. The 100 is your payrate, adjust accordingly. Any field you do not want to use can be deleted.

role: 3 means he's an independent marketing delegate, you can find the other roles in the wiki link in the OP of this thread.

I'd like to write an example python code for the parameters in
http://wiki.bitshares.org/index.php/Delegate/PublicData

But want to wait until no further changes are 'obvious' to the proposals in the wiki ..

I wouldn't say abandoned, it's still as valid as it was back then but not a lot of delegates decided to take advantage of the options. I enabled some of the fields both in the wallet and on bitsharesblocks, but not everything that's in the wiki.

The images are provided by this js library and will remain constant: http://jdenticon.com/

Our plans with DPOSHub actually would bring a revival and utility to those fields again.

I hope they will remain and perhaps even become expanded. Maybe this becomes a worker proposal that dposhub brings forward after we collect enough feedback and data to determine what practical fields work best for providing information people need from delegates profiles.

[svk]

Where does this effort stand? I seem to recall DataSecurityNode discussing these fields, but can't locate that thread. Moreover, it seems this entire approach was abandoned? The original thread never went anywhere after November, why is that?

In playing around with the example code BM used for testing BitShares Login, the gravatarID was pulled from this public_data, but that's not where the geometric account representation seen on the wallet dashboard is coming from. How is that image determined? Are those account identity images keys in a 3rd party lookup or are they now integrated into the wallet so they will remain constant? If they're coded into the wallet is there a toolkit call to retrieve them?

MethodX just made me realize it isn't very clear how to use these public data fields for your delegate. Here's an example output for his delegate:

Code: [Select]

wallet_account_update_registration marketing.methodx marketing.methodx {"website":"http://www.my-website.com","delegate":{"role":3,"handle":"MeTHoDx","location":"My Location","description":"","proposal":"https://bitsharestalk.org/index.php?topic=11663.0", "version":"v0.4.24"}} 100
To update your delegate you modify this with your data, then copy paste it into your client. You cannot do individual fields, so keep your final version for future use. The 100 is your payrate, adjust accordingly. Any field you do not want to use can be deleted.

role: 3 means he's an independent marketing delegate, you can find the other roles in the wiki link in the OP of this thread.

I'd like to write an example python code for the parameters in
http://wiki.bitshares.org/index.php/Delegate/PublicData

But want to wait until no further changes are 'obvious' to the proposals in the wiki ..

I wouldn't say abandoned, it's still as valid as it was back then but not a lot of delegates decided to take advantage of the options. I enabled some of the fields both in the wallet and on bitsharesblocks, but not everything that's in the wiki.

The images are provided by this js library and will remain constant: http://jdenticon.com/

[Thom]

Where does this effort stand? I seem to recall DataSecurityNode discussing these fields, but can't locate that thread. Moreover, it seems this entire approach was abandoned? The original thread never went anywhere after November, why is that?

In playing around with the example code BM used for testing BitShares Login, the gravatarID was pulled from this public_data, but that's not where the geometric account representation seen on the wallet dashboard is coming from. How is that image determined? Are those account identity images keys in a 3rd party lookup or are they now integrated into the wallet so they will remain constant? If they're coded into the wallet is there a toolkit call to retrieve them?

MethodX just made me realize it isn't very clear how to use these public data fields for your delegate. Here's an example output for his delegate:

Code: [Select]

wallet_account_update_registration marketing.methodx marketing.methodx {"website":"http://www.my-website.com","delegate":{"role":3,"handle":"MeTHoDx","location":"My Location","description":"","proposal":"https://bitsharestalk.org/index.php?topic=11663.0", "version":"v0.4.24"}} 100
To update your delegate you modify this with your data, then copy paste it into your client. You cannot do individual fields, so keep your final version for future use. The 100 is your payrate, adjust accordingly. Any field you do not want to use can be deleted.

role: 3 means he's an independent marketing delegate, you can find the other roles in the wiki link in the OP of this thread.

I'd like to write an example python code for the parameters in
http://wiki.bitshares.org/index.php/Delegate/PublicData

But want to wait until no further changes are 'obvious' to the proposals in the wiki ..

[xeroc]

MethodX just made me realize it isn't very clear how to use these public data fields for your delegate. Here's an example output for his delegate:

Code: [Select]

wallet_account_update_registration marketing.methodx marketing.methodx {"website":"http://www.my-website.com","delegate":{"role":3,"handle":"MeTHoDx","location":"My Location","description":"","proposal":"https://bitsharestalk.org/index.php?topic=11663.0", "version":"v0.4.24"}} 100
To update your delegate you modify this with your data, then copy paste it into your client. You cannot do individual fields, so keep your final version for future use. The 100 is your payrate, adjust accordingly. Any field you do not want to use can be deleted.

role: 3 means he's an independent marketing delegate, you can find the other roles in the wiki link in the OP of this thread.

I'd like to write an example python code for the parameters in
http://wiki.bitshares.org/index.php/Delegate/PublicData

But want to wait until no further changes are 'obvious' to the proposals in the wiki ..

[svk]

MethodX just made me realize it isn't very clear how to use these public data fields for your delegate. Here's an example output for his delegate:

Code: [Select]

wallet_account_update_registration marketing.methodx marketing.methodx {"website":"http://www.my-website.com","delegate":{"role":3,"handle":"MeTHoDx","location":"My Location","description":"","proposal":"https://bitsharestalk.org/index.php?topic=11663.0", "version":"v0.4.24"}} 100
To update your delegate you modify this with your data, then copy paste it into your client. You cannot do individual fields, so keep your final version for future use. The 100 is your payrate, adjust accordingly. Any field you do not want to use can be deleted.

role: 3 means he's an independent marketing delegate, you can find the other roles in the wiki link in the OP of this thread.

[cube]

I think BM is careful not to bloat the blockchain with these data which can be better served on bitsharesblock.

[xeroc]

The reason I'd like to discuss this is that with key edges and public data fields we could do all of this on chain and only really need a nice way of representing this to people that do not see the whole chain (thin clients) ..

so IMHO .. the job of bitsharesblock.com should be to DISPLAY the data nicely .. and not store it (as this comes with plenty of additional trust in your service, honesty, reliability .. blablabla .. )

Maybe alot more easy to have that stuff onchain ..

another advantage would be that you could TRACK changes in these info and you don't need to track this in your database .. the database is already there .. it's called: the blockchain

[svk]

Listening to the latest Mumble session i realize that BM also adressed this ..
however, it seems he likes to store data on bitsharesblock.com instead of the blockchain ..

Isn't it desirable to store verifiable identities of delegates ONCHAIN?! together with all the other "interesting" data of delegates

OK just found it! First time I hear BM talking so much about bitsharesblocks, nice to hear

What he's talking about is basically how I was envisaging the "facebook for delegates" site that I was thinking of doing with cass, although making it part of bitsharesblocks definitely makes sense. For now you have the public data fields that I've integrated that we've talked about in this thread, but this is definitely something I'll consider implementing.

On that note you can check it out on my delegate, they're the only ones using this capability so far I think:

http://bitsharesblocks.com/delegates/delegate?name=dev.bitsharesblocks

I'm gonna rework the layout a bit btw, not too happy with how it is right now..

[svk]

Listening to the latest Mumble session i realize that BM also adressed this ..
however, it seems he likes to store data on bitsharesblock.com instead of the blockchain ..

Isn't it desirable to store verifiable identities of delegates ONCHAIN?! together with all the other "interesting" data of delegates

I haven't time to listen to all of it yet, where does he talk about that?

I agree this kind of data should be handled using on-chain data, although it's definitely possible for me to add stuff manually if desired. I could always verify accounts through a memo in a transaction used as an identity check.

[xeroc]

Listening to the latest Mumble session i realize that BM also adressed this ..
however, it seems he likes to store data on bitsharesblock.com instead of the blockchain ..

Isn't it desirable to store verifiable identities of delegates ONCHAIN?! together with all the other "interesting" data of delegates