No community appreciates the value of personalized web of trust better than nostr, and there is no better place for personalized web of trust services to flourish. Currently, a number of nostr clients calculate personalized trust metrics of varying degrees of sophistication for internal use within the client. However, centrality algorithms such as personalized PageRank and personalized GrapeRank [1] remain underutilized. In this article I make the case that it is time for nostr to cultivate a healthy and varied marketplace of third party (independent of clients) service providers -- Brainstorm and Vertex being two examples of such service providers -- to calculate these metrics and communicate them throughout the nostr ecosystem.
What is a trust metric?
For the sake of this article, trust metric refers to the results of any calculation relevant to profiles or content that assigns a number, instills an ordering, or effects a categorization. When we decide whether a user is "verified," filter and stratify what content does and does not belong on the "trending" list or in any particular feed, or calculate 5 star averages of ratings authored by whitelisted users, we are using trust metrics in one way or another.
What does personalized mean?
Personalized metrics are calculated from the perspective of each user individually, as opposed to global metrics that are the same for all users on any given platform or client. An early example of a personalized WoT score is Coracle's WoT score, displayed next to each profile throughout Coracle. The logged-in user's follows list is integral to calculation of this metric, which is what makes it personalized.
There are several ways that personalization can be manifest:
Individualized access to raw data: The raw data that we use to calculate trust metrics must be not only relevant to the trust metric being calculated but also accessible to the entity that calculates the score. In nostr, different users from different communities should not be assumed to have access to the same data. Many communities use relays that restrict access to their notes to members-only. What's "trending" for one community may be inaccessible -- or even if accessible, of no interest -- to another, and vice versa.
This is a feature of nostr, not a bug. Consider, for example, a hypothetical nostr community that hails from a town living under a repressive government, wishing to discuss local politics, but happy to keep a low profile, with a network that has few or no connections to what we may consider the "main" nostr community. They may choose to keep their relay(s) hidden from the general public, in which case their trust metrics will be based on data that outsiders don't have any access to whatsoever.
Individualized interpretation of data: People do not always agree on the significance or meaning of data. Some users may trust zaps more than follows for the initial building blocks for trust networks; others may not trust zaps, on the grounds that zaps can be spoofed.
Individualized data processing: Even if users are working from the same set of data, and agree on its overall interpretation, they may wish to process it differently. For example: When using follows to calculate a generic whitelist or a "verified follower" list, some users may want parameters that cast a wide net; others may prefer greater selectivity. Even if Alice and Bob are using the same algorithm, they may wish to personalize the relevant parameters between these two extremes.
What does third party mean?
Currently, many nostr clients calculate personalized trust metrics. A third party would refer to a service, independent from the client, that calculates trust metrics on behalf of the user.
The ideal third party service would be open source and would perform the following functions:
-
collect raw data such as follows (kind 3 notes), reports, zaps, reactions, ratings, whatever data is both available and relevant
-
calculate trust metrics personalized to individual users
-
deliver trust metrics to clients throughout nostr
A truly "third party" service would be a service that users could potentially pay for. But it would be important for a user to have the ability to act as his or her own third party. Think of it like a relay: most users don't (currently) run their own relays, but many do, and the barrier to doing so is very low for anyone who is sufficiently motivated.
For this reason, it is very important for any third party personalized trust metric provider software to be open source.
Why should trust metric services be independent of clients?
Complexity: Today's web of trust scores are relatively simple calculations that require a relatively small amount of data and can be performed on the fly. But a mature web of trust is going to include calculations that require too much data and/or require too many calculations for clients to do them each time from scratch in a performant manner. Take personalized PageRank as an example, calculated using kind 3 follows as the raw data. Calculation of the personalized PageRank score of a single user profile cannot, in theory, be done without calculating scores for the entire network. Performing this from scratch on a prototype Brainstorm instance currently involves the processing of almost 1.5 million kind 3 events, resulting in the construction of a graph with over 200 thousand user profiles connected by almost19 million follow relationships. It is not reasonable to expect each client to maintain and keep track of such a large dataset. But a third party service focused on just this job? Very much doable.
Consistency: When more options become available for score calculations -- more algorithms, more trust contexts, more use cases -- it will take some time for users to become accustomed to what each new score means. If every client has its own set of custom scores, it's going to be that much more difficult for users to become familiar with each new score. Of course, there will be some highly specialized scores which will only show up on one or a few clients. e.g. a score that represents expertise in some narrowly defined wiki topic. But many trust metrics, e.g. the verified follower count, will likely be utilized throughout nostr on virtually every client. It will degrade the UX for the followers metric on clients A and B to be calculated using different algorithms, or even the same algorithm but with different parameters and cutoffs. Better for a user's personalized followers metrics to be calculated by a third party and then communicated consistently across all of nostr.
Specialization: It is fantastic that we have pioneering clients that have experimented with personalized trust metrics. However, there is a limit to what they should be expected to handle. Ideally, client developers should be empowered to specialize on their core mission. This will include, among other things, delivery of a fantastic UX. The more a team can offload the calculation of trust metrics, the more frugal they can be with their time and attention.
Note that a hybrid approach is also possible. Third party providers can calculate and deliver generic metrics with broad utility that require lots of data and compute (like personalized PageRank or GrapeRank); clients can subsequently utilize those metrics for calculating narrow-utility, client-specific metrics. As an example: a site like pollerama.fun could relatively easily calculate average scores using their 5 star rating system, using the NIP-85 rank metric for authors of the ratings that are obtained from a third party service provider.
Open Questions
There are many, but here are a few:
-
What is the range of use-cases for personalized trust metrics?
-
What methods exist to communicate scores to clients? Should score calculation and score delivery be handled by separate services?
-
How can a third party, personalized trust metric service provider monetize its services? (Hint: Look to nostr.build and relay.tools for two good models!)
Look for companion articles to address these and other related topics.
Notes
[1]
nostr:naddr1qvzqqqr4gupzpef89h53f0fsza2ugwdc3e54nfpun5nxfqclpy79r6w8nxsk5yp0qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcqp9nhyctsv4exzmnt8ka87y