It's interesting but I'm not sure how I can trust the "web-of-trust" here. Traditionally web-of-trusts are built using real world relations. I've worked with pe

It's interesting but I'm not sure how I can trust the "web-of-trust" here. Traditionally web-of-trusts are built using real world relations. I've worked with person X for 5 years and I believe they wouldn't do something malicious, so I'm willing to trust sources they trust. It starts with trust us, and trust every username in this preloaded file we want to give you. That's not distributed, that's a centralized trust model. The trust boundaries themselves seem pretty broad as well. I may trust some developers to work on any code, but I may not trust them to review any code. A good example is anything relating to cryptography. I trust X to write that code as long as its been reviewed by expert Y, but I don't trust expert Y to review code in specialized field Z. A lot of this will come down to personal judgement. The "web-of-trust" model itself here also seems pretty limited. There is mention of a form of trust decay but its not clear how or when that happens, and its not clear what the trust levels mean in this app. What is "medium" trust of a developer? How does that impact whether code is considered reviewed or not? What happens when a developer two-degrees away from me adds someone malicious? Are they also getting the medium trust level? What if I explicitly _don't_ trust a developer that is directly listed in crev's root of trust repository? Can I add them to an ignore list? I might have missed it, but this also seems to be positive trust only. I can't see a way to publish a proof saying "whhoooaaa this crate is actively malicious stay away from it". Based on the getting started guide, the way this project is meant to be used is to start by trusting their central root of trust. If they want to expand on that they can create their own trust repository and start adding to it, inside an organization you can give your team access to modify the repo and you can now trust what your colleagues have reviewed. That's it though, that review process never feeds back into the community. The web-of-trust here is a hierarchy unless someone is blessed by the central repository to become part of their core trust. This model isn't distributed at all. "Wanting" a discovery, or actual web mechanism here may seem counter-intuitive with my first point but can provide important information without inherently trusting individual reviews. If a package has 20 independent reviews and a competing version of the package has none, I still don't know anything about the code or its quality, but I will lean more towards the one that has been reviewed. There is a wiki-page people can publish their proof repos there, but the only way to consume them is to add them to your trust network... Ultimately I think the problem is that while it can operate in independent trust networks, it's effectively been designed with a centralized trust model that I have no way of trusting and no way to establish that trust. I can't even use these proofs as metadata when deciding on dependencies to use in the future. There isn't any value add here as it stands.