Building webs of trust (WoT) systems that add real value while remaining truly decentralized remains one of the great challenges of freedom tech. To achieve this goal, trust metrics must be contextual, personalized, and portable. This article reviews these characteristics and argues that they can only be realized if WoT systems are implemented independently from traditional nostr clients, with trust metrics communicated across nostr using solutions like Trusted Assertions.
WoT Should Be Contextual
The first goal of WoT should be to alleviate the armies of bots, impersonators, spam and other bad actors that plague legacy social media and remain a challenge within nostr. Already, we are seeing various types of baseline "Trust Scores" throughout nostr that are highly effective at sorting the wheat from the chaff.
But it's one thing for my WoT to tell me that a given npub is a real user, worthy of my attention. It's quite another for my WoT to tell me that Alice's claim to be a board certified physician is objectively true, or that I should believe her claim to have knowledge about the best restaurants in the town I'll be visiting next month, or that she can be trusted to give me good advice on cold storage best practices. Each of these represents trust in some particular context. And trust in one context does not necessarily imply trust in another. Some contexts are essentially binary yes-no questions of whether a given npub does or does not belong to a particular category, making the Decentralized Lists custom NIP a straightforward and useful tool to communicate trust. Other contexts require raw data that can be synthesized into a numerical value, such as average 5 star ratings weighted according to some trust metric. Fortunately, once baseline Trust Scores are widely implemented and used to curate Decentralized Lists, GrapeRank provides an extensible protocol to craft numerical trust metrics of this type.
Trust Metrics Should Indicate Confidence
If my WoT tells me that Alice is the smartest, or most skilled, or most qualified person in the world for some given context, I am going to want to know the degree of confidence that my WoT has in that assessment. If the assessment is communicated as an average 5 star rating, is it based on a single rating authored by a friend of a friend? Or is it based on 100 independent ratings, all authored by highly trusted members of my community? The confidence in any given assessment needs to be communicated independently of the assessment itself. This is one of the core design features of the Grapevine and its algorithm, GrapeRank.
WoT Should Be Personalized
Personalization allows each individual to manage WoT according to unique interests, priorities, and values. Here are some of the key dimensions of personalization:
Selection of Interests
Users have a variety of interests, and their WoT should reflect that. For instance, Alice might configure her WoT to track an up-to-date list of Citadel communities and package delivery service providers, rated on a 0-to-100 scale for reliability. Bob, conversely, could focus on discovering emerging and undiscovered Bluegrass musicians, preferring a simple 0-to-5-star system for talent and freshness. Calculating undesired or irrelevant metrics wastes storage and computational resources. In a mature nostr ecosystem, user-friendly tools will enable seamless selection and updates of these trust metrics, ensuring the WoT delivers value without unnecessary overhead.
Selection of Data Sources
The inputs feeding into trust calculations should also be customizable. For baseline Trust Scores, Alice might rely on basic signals like follows, mutes, and reports to separate trustworthy actors from bad ones. Bob might prefer engagement indicators such as reactions and responses as the foundation for his baseline Trust Scores. Charlie might incorporate zaps, while Dave might experiment with highly specific, well-defined statements like attestations of personhood. Elliot, seeking comprehensiveness, could blend all these elements, using a different weight for each input. This flexibility ensures that users have the power not only to select, but also to interpret signals of their own choosing in a manner consistent with their own individual value systems, not the value systems of influencers, developers, or anyone else.
Selection of Algos and Adjustments of Parameters
Most users are not computer programmers and will need someone else to write the scripts that ingest and utilize novel sources of raw data according to their preferences as discussed above. But even so, there will often be customizable parameters that allow fine tuning. Alice might set her baseline GrapeRank trust metric parameters to be conservative, casting a narrow net to minimize bad actors making it into her content. Bob, aiming for broader discovery, could opt for looser settings that err on the side of inclusivity. Such adjustments empower users to balance caution and exploration, making the WoT a truly personal tool rather than a rigid framework.
WoT Should Be Portable
Imagine Alice checking Bob's baseline Trust Score: it's 89/100 in Primal but 74/100 in Amethyst. Without any further explanation, these numbers are hard to interpret. Why are they different? Are they based on different data? Calculated using different algos or different parameters? Do they serve different purposes? Ideally, she will want to personalize how these scores are calculated. But of course this requires effort: upfront decisions on interests, data sources, algorithms and parameters, plus ongoing refinements as preferences and options evolve. So the last thing she wants is to repeat the laborious process of customizing every trust metric from scratch, every time she uses a new nostr client.
The solution is portability. Each trust metric should ideally be computed in one place (by a single service provider) and then seamlessly shared across clients throughout nostr. This is the only way to ensure consistency of her WoT experience across nostr without the need to repeat the same customization process with each new client.
Of course, this shouldn't mean relying on the same service provider for each and every trust metric. Alice could run her own Brainstorm instance locally for baseline Trust Scores, count on NostrHub to use her baseline Trust Scores to calculate and publish her personalized list of community-approved NIPs, rely upon her Citadel to keep track of trusted package delivery services (perhaps even using ratings available only to Citadel members), and defer to a client like Tunestr to calculate personalized musician recommendations.
And she may want to change her mind on which service provider to use for any given trust metric at any given time. She should be able to switch providers quickly and easily, maintaining continuity without needing to recalculate everything from scratch with each change.
Fortunately, all of the above is achieved in a simple and straightforward manner by using Trusted Assertions to communicate trust metrics across nostr.
Trusted Assertions: Making Life Easier for Clients
Client developers should not all be expected to reinvent the WoT-wheel from scratch. Instead, they should have the option to outsource calculation of (most or all) trust metrics to service providers. This removes the necessity for each client to spend more time and resources on WoT than desired, and is the only way to achieve portability and consistency across nostr.
But those service providers need a means to communicate metrics to clients. Ultimately multiple methods will be used, but as a general rule, for any given use case, service providers should always strive to use whichever method is most convenient for clients. If they fail to do this, their services will simply fail to gain traction.
This is one of the greatest strengths of Trusted Assertions: it is designed to make life maximally easy for the developer. If Client A wants a particular trust metric for Alice, as calculated by the logged-in user's web of trust, all the client has to do is fetch the corresponding kind 30382 note. Through integration of Trusted Assertions (TAs), a client developer can effectively integrate in one fell swoop with each and every service provider who exports metrics as TAs. This is simpler to implement than a DVM, there is no cost to the client, no need to navigate a new custom API for each service provider, and no need to worry about what to do if or when any given service provider's server goes down. Furthermore, TAs empower not the client, but the end user with the ability to select which service provider to use for any given trust metric: each selection is encoded in the end user's kind 10040 note, which can be updated by the end user at any point in time, and which can be encrypted to preserve privacy as desired.
Conclusion
To build Webs of Trust that are contextual, keep track of confidences, are personalized and portable, and to achieve a consistent WoT experience across nostr, we need a vibrant marketplace of open source tools for trust metric service provider systems competing on innovation, reliability, and user-centric features. This is a core mission of NosFabrica, which aims to bootstrap such an ecosystem.
Fortunately, solutions like Trusted Assertions pave the way. Client developers can focus their attention on consuming trust metrics relevant to the client, without the need to calculate metrics themselves unless to do so would be a natural feature of that particular client. Users are empowered to decide which trust metrics to track and service providers to use for each metric. By embracing these principles, nostr can evolve into a network where trust is not just decentralized, but deeply empowering for every user.
