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
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