Why not put the Syscoin Marketplace ranking system right on the Syscoin blockchain using data aliases?
Syscoin data aliases have some unique and powerful features. Data on the blockchain is essentially “broadcast” to the entire network in one confirmation, with the “dataupdate” command in the console, and viewable by all using the “datainfo” command.
Yet control of the data is restricted to one syscoin address at a time.
This makes for some potentially elegant solutions to some thorny problems, such as this one - how to publicly rank merchants in the marketplace, but authenticate the data and prevent spam.
Let us say I purchase a widget from sphericon and want to submit a ranking of that transaction. I can update my ranking data alias (lets call it “my_reviews”) with the buyer’s and seller’s addressees, the transaction ID, and my ranking score for that transaction. This is done right in the marketplace client. If a sufficient number of buyers did this after each purchase, the client would be able to query the blockchain to both authenticate the validity of the scores submitted, and display the score next to the seller in the client.
So I think it makes perfect sense to store a ranking for a particular user in the blockchain using the Syscoin alias system. We could come up with some custom properties in the data alias (AKA "seller profile") that could be referenced in other data aliases (AKA "user review"), not unlike a SQL database join. This could either be programmed into the marketplace or could be implemented into the Syscoin wallet at some point like you were suggesting.
The other option would be to create a website that allows users to rate specific addresses (sellers) like yelp. The problem would be that this data is centralized and therefore could be tampered with.
The truly honest solution would be to store any ratings in the blockchain. You would potentially get the problem of spam/defamation, but with a small cost of SYS to post, you could eliminate any large amount of spam.
My Proposal:Buy an item, and then after receiving, create a new data alias:
syscoind datanew "/rating/[syscoin address or alias of seller]/[transaction of purchase]/[positive or negative boolean value]"
This would be part of the "rating" dataset, and would reference both the seller's Syscoin address/alias as well as the transaction of the specific accepted purchase. There should only be a way to rate a seller on an item that the user has actually purchased. The rating would be a "good" or "bad" value, stored as 'true/false' in the data alias name.
After creation, the user could attach data to this rating:
syscoind dataactivate < dataName > < guid > [ < txid > ] < filename > < data >
The key part here is the "data" portion. this can store a base64-encoded chunk of data with a maximum size of 256kB. I'm thinking this could be used for a low-resolution picture, either showing a picture of the item with a hand drawn username or some other proof that this is a legit transaction. This would be optional of course, but could serve to further validate the seller as well as buyer. Additionally, if this "data" element was further encoded, we could split it out into multiple pieces of information, such as a picture
and a comment.
Once this has been completed, a user or application could simply query the data aliases on the blockchain using the datafilter command:
syscoind datafilter < regexp >
The regex could look for anything with the "/rating/address" chunk in the name and then do some sort of percent calculation of feedback, as well as return a list of comments associated with the data. This could then be used to show ratings for a user in a completely distributed fashion. Clearly the code is too complex to be used by your average user to actually rate a user, but an app could be developed to handle the back-end stuff. A full list of the data commands is
here if people are interested in researching further/other methods to do this.
Thoughts?
I like it... but you probably want a neutral position if they aren't positive or negative.. which won't weigh the overall, a positive would be +1 and a negative would be -1 which we can add/subtract to get final feedback.
The ability to tie in the purchase transaction is key.. the transaction has to be one that you made and hasn't had feedback yet... then you can give feedback after an order has been made at any time in the future.
The cool thing I did with aliases is.. if you type in a syscoin address to search it will also search it as an alias if that syscoin address isn't valid. If the address is valid it assumes that is what you want to search. This is for any command that takes in a syscoin address(alias is also valid in any of these cases).. so it doesn't even matter if you use aliases or addresses technically but its better to follow convention and using aliases is probably more usable for a search feature like this.
Usually ppl using our services would have an alias registered. We should make the language as such to sway people to use aliases everywhere.