I’ve spent most of my career working—in some capacity or other—on MetaMask Snaps, the eponymous wallet’s plugin system. Why, if you have heard of MetaMask, you have not heard of its plugin system, is a story for another time. But our ambition for the system was to let the user choose their features, and the providers of those features, at runtime. A “feature” could be anything from asset types, to key management methods, to something completely unrelated to wallets or cryptocurrencies. Anyone would be able to create and publish a Snap. This presented a problem: how do you know which authors to trust? Then as now, we despised the app store model, and had neither the resources nor inclination to maintain one. While I’m not working on Snaps anymore, I’m still trying to realize the ideal of what I now call fully malleable software. So, let’s consider how to decide who to trust with the keys to your life savings and/or monkey jpegs.
EigenTrust is an algorithm for reputation management in p2p networks:
We describe an algorithm to decrease the number of downloads of inauthentic files in a peer-to-peer file-sharing network that assigns each peer a unique global trust value, based on the peer’s history of uploads... In simulations, this reputation system, called EigenTrust, has been shown to significantly decrease the number of inauthentic files on the network...
The EigenTrust paper was published in 2003. It seems to me like it could’ve been used by BitTorrent, or at least torrent trackers, but I’m not aware of any major deployments of the algorithm. In any event, we considered EigenTrust as the means by which Snaps users determined which publishers to trust. The system was never fully built or deployed, but I don’t think it would’ve worked. To understand why, we need to review the algorithm itself.
The authors never provide definitions of “trust” or “reputation”, so let’s begin by venturing our own: trust is your willingness to be vulnerable to a particular party, with respect to some kind of harm, and reputation is the degree to which a party’s behavior has been honest or dishonest. In EigenTrust, each peer is essentially granted a trust budget of 1, which they divide between their known peers in the network. Each peer’s individual trust scores are then used to compute global trust scores for all peers in the network. These scores are a proxy for the network’s sense of how vulnerable we should want to make ourselves to a given peer. The authors reasonably assume that peers have an incomplete view of the network, and that peers are—aside from their upload histories—mutually anonymous.
This is all well and good for file sharing, because file sharing is a one-dimensional and quantifiable use case. Therefore, your performance and consequently trustworthiness are in turn quantifiable. Venture beyond the narrow confines of file sharing, however, and the honesty of Internet strangers becomes much harder to measure. A Snaps user, for example, could be interested in getting notified about activity regarding a particular asset, or a new account management solution. The possible harm in the former case consists of annoyance or deception. In the latter case, it’s bounded by the value of the assets placed in the account. These are completely different risk profiles, and you will be hard pressed to find a set of quantitative metrics with which to algorithmically compare the reputation of two publishers.
When we discussed this at the time, we talked about incorporating different “trust signals —e.g. “had an audit”, “is legal entity”—to create a trust score for each publisher. There are a number of problems with this: first, we’d be choosing the trust signals, which may or may not be the ones that user cares about. Second, publishers of vastly different Snaps would receive the same one-dimensional trust score, even if they provided services with vastly different harm potentials. And finally, it is not at all clear how do decide the threshold of a sufficient trust score. In other words, it’s a lot of math to poorly model something that people can figure out instantly if given the right tools.
When human beings make decisions about trust, they do not gather up their trust in a bucket and distribute it across every possible candidate. Rather, we make a series of qualitative judgments about the person or entity, and then decide what to do. If we for some reason cant make up our minds, we ask someone for a recommendation, and then follow their advice. With that in mind, if I had to design a decentralized Snaps publishing system from scratch, here’s what I would do:
This notion of transitive trust is dead simple, and closely models how people actually make these decisions socially. You can of course attenuate the transitivity in arbitrary ways: “just this once”, “trust this entity for all account management Snaps”, “trust this entity for all kinds of Snaps”, etc. The important thing is that the user directly makes the trust decisions, and that it is dead simple to understand. The platform maintainer can create reasonable opt-in or opt-out defaults, and for any successful deployment, community curators will appear.
Users in this model are nodes, and trust between them are edges. The users’ trust decisions form a transitive web of trust, which—in absence of more interesting ideas—we may as well name the algorithm. Although Snaps was the original motivation, there is no shortage of use cases in a world populated by increasingly capable agentic software and decentralized social networks.