BitShares Forum
Main => General Discussion => Topic started by: xeroc on November 18, 2014, 11:57:57 am
-
From the discussion in
https://bitsharestalk.org/index.php?topic=11476.0
I proposed to have a standardized (read: consensus) way of publishing auxiliary data for each delegate (read: registered account)
Taking some attributes from
https://wiki.namecoin.info/index.php?title=Identity
I'd propose to have those attributes set by delegates:
=> http://wiki.bitshares.org/index.php/Delegate/PublicData <=
Services have been initially described in:
https://bitsharestalk.org/index.php?topic=11356.msg149525#msg149525
All attribute names, descriptions aswell as the structure are made up and need
discussion. So...
Discuss!
-
Looks good to me!
I'd like to add:
{"delegate.handle": "", # Bitsharestalk forum handle representing the delegate}
-
I'd like to add:
{"delegate.handle": "", # Bitsharestalk forum handle representing the delegate}
added "handles" as an object!
we might need to discuss a timeless description .. who knows when facebook will fall 8)
-
Oh and btw the guidata field that the wallet looks for is actually called "gui_data"
-
Oh and btw the guidata field that the wallet looks for is actually called "gui_data"
fixed .. thanks
-
Yes. Looks excellent!
-
Another idea: "delegate.ann": "" # announcements
This could even be an array of strings, but I think we'll quickly run out of space. That's another thing we need to find out: how much data can actually be stored in public_data.
BTW A possible issue with having all these fields and keeping things up to date is that currently you need to reenter every field when updating your account, so if you forget a field it gets erased.
-
I was thinking about this some more and thought of another thing that I believe could be very useful. My idea is to define a set of roles for delegates that would be hardcoded into the wallet, and that upon registration of a new delegate you would be presented with a dropdown list with a choice of roles. By default you'd get "Backbone" which basically means a 3% delegate providing feeds and staying up to date.
The list of roles could easily be expanded over time, but here's a possible shortlist:
["Core Development","Core Marketing", "Independent Development","Independent Marketing","Faucet","Backbone"]
The final list of course needs more thought. If you want to define your role manually in the CLI, you would simply set {public_data.delegate.role: 2} to select "Indepent Development" for example.
@valzav if you think this sounds like a good idea I'll have a go at implementing it in the wallet. I'd also like to flesh out the account page to take into account at least some of the JSON fields discussed in this thread.
-
I was thinking about this some more and thought of another thing that I believe could be very useful. My idea is to define a set of roles for delegates that would be hardcoded into the wallet, and that upon registration of a new delegate you would be presented with a dropdown list with a choice of roles. By default you'd get "Backbone" which basically means a 3% delegate providing feeds and staying up to date.
The list of roles could easily be expanded over time, but here's a possible shortlist:
["Core Development","Core Marketing", "Independent Development","Independent Marketing","Faucet","Backbone"]
The final list of course needs more thought. If you want to define your role manually in the CLI, you would simply set {public_data.delegate.role: 2} to select "Indepent Development" for example.
@valzav if you think this sounds like a good idea I'll have a go at implementing it in the wallet. I'd also like to flesh out the account page to take into account at least some of the JSON fields discussed in this thread.
I like that idea!
Will add this to the OP when I find the time!
-
Well done guys. So good to see you both jump in to action on this after our discussions earlier today. Shining examples to us all you both are.
+5% to public_data.delegate.role - was thinking this would be really useful too. Effectively allows for people to identify with over arching teams/tribes as DAC workers self organise.
-
+5% good idea, good information about the delegates
in the future it would be good to see from every delegate who gets paid more then 3% how he spend his money and what he did in the elected time.
-
I've made a pull request for an initial implementation of this idea:
https://github.com/BitShares/web_wallet/pull/464
-
I've made a pull request for an initial implementation of this idea:
https://github.com/BitShares/web_wallet/pull/464
Make sure you document the fields somewhere too. Probably at least a page on wiki.bitshares.org.
-
Make sure you document the fields somewhere too. Probably at least a page on wiki.bitshares.org.
http://wiki.bitshares.org/index.php/Delegate/PublicData
Needs some more work .. and a consensus about the attribute names etc....
It's not that I'd like to define a standard on my own ... thx to svk for the input sofar!!
-
Make sure you document the fields somewhere too. Probably at least a page on wiki.bitshares.org.
http://wiki.bitshares.org/index.php/Delegate/PublicData
Needs some more work .. and a consensus about the attribute names etc....
It's not that I'd like to define a standard on my own ... thx to svk for the input sofar!!
Good job on the wiki page. I only put one handle in the wallet for now, and it's bitsharestalk by default. If there's real demand for putting facebook handles and more in there we can always add them, but it feels a bit heavy to me.
I see you added some more roles, I'll add them to the wallet later. I've also added this to my website but I want to finish the translation setup before pushing the next version.
valzav merged my pull request so this will probably be in the next version of the wallet, start your engines! :)
PS. I was amazed by how much data I could actually add to the public_data field, you can see two images in the git pull request of what's possible :)
-
Good job on the wiki page. I only put one handle in the wallet for now, and it's bitsharestalk by default. If there's real demand for putting facebook handles and more in there we can always add them, but it feels a bit heavy to me.
I agree ... I also dislike the twitter handle .. But we should keep the
possibility to add arbitrary handles for later use .. who knows what happens in
5 years
I see you added some more roles, I'll add them to the wallet later. I've also added this to my website but I want to finish the translation setup before pushing the next version.
No need to do this right away .. let's first figure out if we need even more ..
There's no rush!!
valzav merged my pull request so this will probably be in the next version of the wallet, start your engines! :)
Bam! .. good job!
PS. I was amazed by how much data I could actually add to the public_data field, you can see two images in the git pull request of what's possible :)
Ui ..
-
I've made a pull request for an initial implementation of this idea:
https://github.com/BitShares/web_wallet/pull/464
+5% great work
-
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
-
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.
-
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..
-
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 8)
-
I think BM is careful not to bloat the blockchain with these data which can be better served on bitsharesblock.
-
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:
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.
-
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:
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 ..
-
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:
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 ..
-
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:
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/
-
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:
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.
-
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:
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/
-
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:
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.
-
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.
-
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!
-
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.
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 (http://bitsharesblocks.com/delegate/info?name=delegate.verbaltech)