BitShares Forum
Main => Technical Support => Topic started by: pc on February 13, 2016, 02:22:24 pm
-
Hi,
before I start the formal process of writing BSIPs I'd like to get feedback on an idea. Actually it's more like one and a half ideas.
My starting point was that I'd like to have a way to attach generic information to an account in the form of key/value pairs. Examples would be contact information like email address, URL, PGP-key etc. - specific uses would be up to client software. External representation should be in the form of JSON or BSON, perhaps with an extra datatype for blockchain object references. The latter would make it possible to add a list of "friend" accounts, for example. All of this could be implemented mostly by extending existing data structures (account_object and account_update_operation) with optional add-ons. Since this permanently consumes node resources, more weight should be put on per-kb fees for related operations.
Now that we have defined a generic data structure, the next logical step is to allow storing arbitrary data objects in the blockchain. In addition to the data itself (again, key/value pairs like above), such a data object would require metadata like permissions (owner + active keys) and an expiration time. Fees should be calculated per-kb and per-time, and the expiration time of existing object could be extended by paying additional fees.
I think these generic interfaces could be used by a lot of blockchain-related businesses. Opinions?
-
Sounds useful. +5%
Does this include modification to the GUI or just the BSIP?
-
Could you provide some examples on how this would be useful? Is this because of the Synereo community approach?
-
Does this include modification to the GUI or just the BSIP?
So far this is just loud thinking, not a proposal or a GUI or whatever. Also, I'm thinking about a general mechanism. It would be up to application developers (or GUI developers) to build specific use-cases on this.
Could you provide some examples on how this would be useful? Is this because of the Synereo community approach?
I haven't followed the Synereo thread.
The OP contains some examples how to use key/value pairs attached to an account.
The generic data storage could be used for literally anything that is a public database of some kind. Think of something like imdb.com. Or wikipedia.
-
Thank you for posting this. We are looking for an application that could support an adjudicated factor where a knowledgable person provides a monetary valuation of a physical object, or a delta value added or subtracted from a nominal value. The market for that physical object would take into consideration the the adjusting value in their offer price. More specific, this would be akin to a CarFax for Real Estate that includes a physical inspection and ancillary data by a knowledgeable person (adjudicator) who are the multiple writers to the database. fees are generated by the owner of the property. database would be viewable by permission or made public.
-
Thank you for posting this. We are looking for an application that could support an adjudicated factor where a knowledgable person provides a monetary valuation of a physical object, or a delta value added or subtracted from a nominal value. The market for that physical object would take into consideration the the adjusting value in their offer price. More specific, this would be akin to a CarFax for Real Estate that includes a physical inspection and ancillary data by a knowledgeable person (adjudicator) who are the multiple writers to the database. fees are generated by the owner of the property. database would be viewable by permission or made public.
If there is a good demand for it, I think this could be a potential FBA.
-
If there is a good demand for it, I think this could be a potential FBA.
IMO a worker proposal would be much better suited for this, because
1) the implementation is probably quite simple, because it uses mostly existing objects + operations, and
2) the additional data causes significant additional costs for witnesses and seed nodes - so the fees should go to the network, not to the developer.
But that part of the discussion is really a bit premature. Let's define the WHAT first, then discuss the HOW.
-
If there is a good demand for it, I think this could be a potential FBA.
IMO a worker proposal would be much better suited for this, because
1) the implementation is probably quite simple, because it uses mostly existing objects + operations, and
2) the additional data causes significant additional costs for witnesses and seed nodes - so the fees should go to the network, not to the developer.
But that part of the discussion is really a bit premature. Let's define the WHAT first, then discuss the HOW.
Use account_object to store extended user info is good.
The physical object for me is like an asset, the owner issue one asset to himself, then others bid on it. This way we can use the market engine. But thousands of assets are hard to organize.
Another option is to use the custom_operation which is the golden grail, but it's even harder to index.
I don't think it's easier to do this on current system. It's not very related to our product imo. Maybe it's better to implement it on top of a VM?
-
This feature would also be useful for creating a web of trust for OpenBazaar (they also need to be able to store a network id (which is a hash for the DHT))!
-
This feature would also be useful for creating a web of trust for OpenBazaar (they also need to be able to store a network id (which is a hash for the DHT))!
Aren't they already using Onename for that?
-
yes .. they are .. and they should probably stick with it .. even though our chain could give them more flexibility for moderations ..
maybe it is easier to have a BTS name added to their onename entries