Chlu Design Considerations

The people over at Rebooting Web-of-Trust have been doing some excellent work on defining the areas of Decentralised Identity and Decentralised Reputation Systems. At the 4th Rebooting the Web of Trust workshop (April, 2017) the participants wrote a paper titled “Design Considerations for Decentralized Reputation Systems”; the paper lists ten design considerations for Decentralised Reputation Systems. In this post we describe how Chlu’s motivation, goals and design address those design considerations.

While describing how Chlu provides each of the design decisions, we refer a lot to our white paper and to our protocol specifications. To find out more about how exactly Chlu meets the design considerations listed next please refer to those two documents.

Ten Design Considerations

Context. What is the reputation value applicable to? What can be understood about an entity by seeing their reputation value(s)?

Chlu captures reviews and ratings for vendors who are selling their products and services on online marketplaces. Vendor reputation scores are computed by marketplaces using the decentralised data that vendors explicitly choose to share with the marketplace.

A vendor’s reputation score on a marketplace describes how they have scored on the attributes the marketplace gives importance to.

Participation. How is participation defined? Who can and can’t participate? Who can and can’t have a reputation value assigned?

Customers create reviews for vendors, but only if they have made a payment to the vendor. This payment in turn must have been requested by the vendor. Further, anyone can confirm the validity of this request for payment by cross referencing the marketplace and vendor public keys as well as a reference to the review included in the blockchain payment record.

Customers participate by paying through a cryptocurrency wallet that supports the openly developed Chlu protocol. Vendors participate by a) requesting payment directly from the Customer, or b) through a marketplace that supports the Chlu protocol.

A vendor can receive a rating/review only if they have received a payment that also has a proof that the vendor requested the payment.

It is important to note here that Chlu is cryptocurrency agnostic and while our reference implementation will work with both Bitcoin and Litecoin, we will strive to make it work with as many other cryptocurrencies as possible. This is also where the developer community will be very important to drive adoption for Chlu.

User Consent. Is consent required by a user to issue claims or a reputation value against the user? Is consent required to reveal claims or a reputation value of a user?

Yes, a vendor has to explicitly request a payment from a customer before the customer can make the payment and leave a review.

Yes, when a vendor receives a review it is by default encrypted using the vendor’s public key. The vendor can then share these reviews with marketplaces by decrypting them and re-encrypting them with the selected marketplace’s public key.

Chlu protocol specifies that vendor wallets should provide this ability to vendors, so that sharing their review history is easy to manage.

Confidentiality. To meet consent requirements, how is data that calculates a reputation value kept private? Can it be derived?

The data is stored on a decentralised peer to peer network so that no centralised authority controls it, and it is encrypted using the vendor’s public key.

The vendor can share this data with select marketplaces, who can use the ratings and reviews data to calculate a reputation score that is useful in their marketplace — i.e. by giving higher weight to attributes that capture the behaviours they want to encourage.

Value Generation. How is the reputation value calculated or generated? How are claims contributing to the reputation value normalised?

Calculating reputation scores is purposely not part of the Chlu protocol. We believe each marketplace wants to encourage different behaviours by their vendors, and though we provide a set of frameworks to calculate the reputation scores, we encourage marketplaces to decide on or build reputation scoring algorithms that work best for their ecosystem.

Vendor reviews and ratings history stored on IPFS and validated by payments on blockchain results in a decentralised data network of vendor ratings and reviews. Customers create review data which is then owned by the vendor the review was written for, and marketplaces can be granted access to this data by vendors.

Performance. How does the system manage the performance and behaviour of the users? How does it manage the performance of the network for speed, reliability, and data integrity? How do users have confidence in this?

Chlu makes Sybil attacks expensive by requiring a misbehaving vendor to buy their own products from marketplaces who will be charging a commission on each sale. A vendor can list items for very low prices and give himself positive reviews, but the vendor will have to register the sock-puppet accounts with the marketplace which adds friction to executing a Sybil attack. Further still, we recommend that marketplaces consider the relative amounts that support each review when determining a reputation score. For example, if a vendor has a thousand sales of $0.01, but then lists items worth $1,000, then clearly there is something wrong. Chlu will publish libraries that take such attacks into account while computing reputation scores.

Chlu relies on IPFS to store the ratings and reviews data, and to support this ecosystem, Chlu will “pin” the ratings and reviews data referenced from payment transactions on blockchains. Further, we will provide replicated pinning servers to help the ecosystem have quick access to data in case no one else is pinning data for the ecosystem.

Users, can verify that each vendor, marketplace and Chlu are abiding by the rules as all the data used is available on a public peer to peer data network and linked to transactions on various blockchains.

We will also publish tools to help anyone run the above mentioned verification - the same tools that we will be also be using.

Sustainability. How does the system stay relevant over time?

By publishing the Chlu protocol under MIT license and providing the reference implementation under the same license, our goal is to grow an ecosystem of developers, marketplaces, vendors and customers that use and contribute to the ongoing development and adoption of the Chlu protocol.

Claim Lifecycle. How are claims valued over time? Can they be revoked and under what conditions?

To decay the importance of reviews is up to the marketplaces. They can choose to give less weight to reviews that are older by time or older by order. Chlu doesn’t impose any restrictions on how the reviews data is used by marketplaces.

Resilience. How does the system protect against attacks that reduce the integrity of the reputation value?

Our white paper explains how we prevent vendors from hiding any reviews, and how we prevent anyone (including the vendor and the marketplace) from tampering with the reviews, or selectively hiding reviews, by using signed and encrypted proof of payment requests, review records and updates to review records.

Legal. What is the legal environment in which the system sits? Are there potential violations of ‘natural’ law?

This design consideration deserves a separate post, and we are working on one.

Conclusion

We hope that by analysing our goals and design decisions against the design consideration proposed by thought leaders working on Redefining the Web of Trust, we have helped the community further understand our motivations, our design and our future product roadmap.

If you have any questions or want to know more about Chlu, please visit our site https://chlu.io or email us directly at info@chlu.io or reach out to us on twitter https://twitter.com/chlunetwork