Rep/Review Logical Analysis Needed

Apps
,
#1

Question: What do you think is the best way to structure a review/reputation system for Souq?

I would assume a upto 5/5 stars type of system would be the best approach because its already widely used on sites such as ebay. (5 being best, 1 being the worst)

I would also assume the primary way of validating the claim to review would rely upon the reviewer having an actual transaction with the requester of funds (eg to review, the reviewer has to actually donate).

This leads me to the following questions:

  • Are my assumptions flawed? eg is there a better way to approach this?

  • If the donor is substantiated as actually donating fund… should there be a minimum donation amount before review is considered valid? to try to sheer off haters willing to dump some dust to kill someones averaged rep.
    (perhaps by fixed % of total being requested, or perhaps by minimum value set by project submitter, or by static min. value)

If the assumptions and above questions are are answered

We still need to model out the data aggregation and validation techniques to substantiate the users reviews as being valid as well as being properly presented at the right time while still being fully decentralized (eg when users inspect the details of a project the relative reviews are rendered in the UI)

The best I can come up with so far for modeling out the reputation is having the users who intend to leave reviews about projects(owners), first have at least a single registered id (or perhaps another namespace) that represents their array of reviews they have given/will give over time, this would ensure that only they can update their ‘reviews’ and thus is censorship resistant.

So the real conundrum is how to yield an aggregated scrore of all the actual applicable reviews when inspecting the details of owner of a specific project.
Assuming:
IF a Blockstack wallet can’t contain multiple owner_address(s) [hoping this can be confirmed]
IF a Blockstack withdraw command is executed, does the funds sent, come from the same owner_address (when sending funds to an intended recipient)

If both those IF’s are true, then should be possible in theory to do a get_names_owned_by_address against the owner_address of a project(name) in question to cache all the names owned.

Once a said cached list of all their names (projects owned) are known, one could then in theory do a get_names_owned_by_address against all the the donors pay from address(owner_address),
by doing a lookup against the standardized 'reviews` registered name

A visual model would probably be better to explain the design, I’ll build one in the next couple days to help paint a better picture of what I mean.

Feedback welcome!

Fake or Multiple Accounts/IDs
#2

I personally prefer fewer choices: Thumbs up/Down, Like/Dislike, Happy/Neutral/Sad emojis, etc.

It really depends. Is there a huge incentive, financial or otherwise, to kill someone’s reputation by donating tiny amounts of money? If there isn’t, I suspect that needing to spend anymore money might be a big enough deterrent. Might not know until you try!

The plan forward is to push people to 1 name per address. Privacy is one motivation. Not sure if this is or will be enforced at the network level, but it is our plan for the Portal.

Generally, users will have separate money (Bitcoin) wallets and identity (names) wallets. Both Core and Portal do this now.

Look forward to it!

#3

I’m not sure I know of any fully decentralized reputation/star_review solutions. Maybe @jude has an idea?

#4

Souq-Projects-Rep-Reviews-Model.jpeg2550×1788 246 KB

Here is the visual model, its a rush but hopefully it makes sense :smiley:

This visual model is massively simplified and does not include other obvious aspects of the application nor does it give alot of granular detail

Souq will call the Preferred node server when wanting to inspect (GET) the reviews about any given Project and or its Owner, the compiling/aggregation of all the reviews might be some what arduous to the preferred server since it will need to do potentially alot of cross referencing of payment history to find corresponding reviews if existing.

I’d love to get the project details in a unique namespace (.project :slight_smile: )
I’d also love to see a .review type of registered name, then could be used as described above with
with a simple a TXT record you could contain a simple json array of such as:
[{"owner":"Firstowner","name":"samplen.amespace","score":"4","detail":"Great job"},{"owner":"Secondowner","name":"sample2.namespace","score":"1","detail":"Terrible job"},{"owner":"Thirdowner","name":"sample3.namespace","score":"5","detail":"Super job, recommended"}]

Once a list all the user defined reviews about said target project and or owner of said project, are aggregated together you could locally calculate the score such as rendering an average X out of 5 stars with X amount of reviews total and list them individually in the ui.

#5

Hey @cryptocracy, looks like you’ve put a lot of thought and detail into decentralized reviews!

IF a Blockstack wallet can’t contain multiple owner_address(s) [hoping this can be confirmed]

It does not, for now. However, a single person can have multiple blockstack wallets.

IF a Blockstack withdraw command is executed, does the funds sent, come from the same owner_address (when sending funds to an intended recipient)

The funds actually come from the payment address. The owner address only has dust associated with it–just enough to pay for its UTXO. However, two things are possible:

  • The user can send BTC to their owner address

  • We can extend the withdraw command to take all but the dust amount out of the owner address, in addition to (or instead of) the payment address. The owner address needs to have at least one UTXO on disk, as part of the upcoming light name lookup logic.

If both those IF’s are true, then should be possible in theory to do a get_names_owned_by_address against the owner_address of a project(name) in question to cache all the names owned.

Yup! Just as long as the software knows that a single person can have multiple owner addresses (by way of having multiple wallets).

Are my assumptions flawed? eg is there a better way to approach this?

I think you’re right on both counts.

If the donor is substantiated as actually donating fund… should there be a minimum donation amount before review is considered valid? to try to sheer off haters willing to dump some dust to kill someones averaged rep.
(perhaps by fixed % of total being requested, or perhaps by minimum value set by project submitter, or by static min. value)

This is the crux of the difficulty with decentralized reputation systems :slight_smile:

Centralized systems have to solve this problem too (i.e. I can make sock puppet accounts on eBay, buy a bunch of cheap goods from one buyer, and leave a lot of 1-star reviews). They have an easier time with it, however, since a seller that gets grief-attacked can just ask eBay to change or remove the grief reviews.

This is harder in a decentralized system like Souq since there is no central point of control. I like the idea of having a minimum donation, since that will make grief attacks expensive (i.e. rare but not impossible) and since users who donate more have more “skin in the game” and want the system to work for them. Beyond this, have you considered these ideas?

  • Rank reviews by date and donation size, under the assumptions that (1) recent reviews are more indicative of future performance and (2) high-value donors have more interest in keeping the system working as intended.

    • A recent review would weigh more than a review from a donor with the same value paid but from a long time ago (e.g. maybe there could be an exponential decay in how relevant a review is, based on how old it is).
    • A high-value donor’s review would outweigh several small-value donor’s reviews from the same time period (e.g. one donor’s review of 5/5 with 1 BTC and 1/5 reviews from 10 donors’ reviews of 0.1 BTC each might work out to be something like 3.5/5).

  • Reviews from users who have run projects would be more heavily-weighted than reviews from users who have not. The assumption is that these users will be the ones who, on average, will be more fair since they want the system to work. It also incentivizes users to keep using the same owner address. This weight might also decay exponentially over a (long-ish) period of time, so that users who have not recently executed a project will revert back to being normal users.

  • Users who do not donate but have a vested interest in seeing the project’s successful completion (e.g. everyone who uses the road but did not donate to fix a pothole) could still post reviews, but the values they post would count for very little in the total review score.

We still need to model out the data aggregation and validation techniques to substantiate the users reviews as being valid as well as being properly presented at the right time while still being fully decentralized (eg when users inspect the details of a project the relative reviews are rendered in the UI)

One thing you might consider doing in a later version of the software is requiring a reviewer to include a link to a signed selfie of themselves with the completed project. The link would go in the zone file, and the user would put the signed selfie wherever is convenient (just as long as it’s compatible with Blockstack’s storage drivers, but that shouldn’t be a problem). The software could (1) use some basic client-side image-processing to detect the picture of the person, and (2) ensure that no one is re-using the same picture. It won’t stop the most clever griefers (who might take lots of selfies with different cardboard cutouts), but it will make griefing that much harder.

Anyway, just my 0.02 cents. This is a tough nut to crack, and we’d all be interested to see your approach :slight_smile:

3 Likes
#6

Thanks for the response @jude … Lots of info to digest in your reply.
Indeed this is a tough nut to crack :slight_smile: … I’ll get back with a reply soon on this endeavor.
Hopefully with some back and forth we can come to some sort of amazing epiphany to establish a fair and accurate implementation.

2 Likes