NIP-85: Trusted Assertions (pull request) is one of several methods for third party providers of personalized trust metrics to deliver those metrics to nostr clients. NIP-85 is particularly useful when the client desires trust metrics from one or a small list of known pubkeys, in which case requesting a single Trusted Assertion (a kind 30382 event) for each pubkey is all that needs to be done [1]. Trusted Assertions and Declarations of Trusted Service Providers (kind 10040 events) are currently created and published by Brainstorm instances such as this one and this one and are made available to clients by a dedicated NIP-85 relay. Available metrics include two standardized NIP-85 metrics: rank (User Rank, an integer that ranges from 0 to 100) and followers (Follower Count, best interpreted as using some sort of verification criterion) [2]. These two metrics in particular should be relatively straightforward for any Service Provider to calculate -- there is no need for every provider to use the same methodology [3] -- and should have broad utility across many nostr clients. Integration of these two standard NIP-85 metrics into nostr clients will demonstrate a demand for third party personalized trust metric service providers and is an important next step in bringing web of trust to nostr. In this article I propose several use cases for these two metrics that can be implemented today.

Proposed NIP-85 Use Cases

individual profile pages

The most simple and straightforward use case is to show standardized NIP-85 trust metrics such as rank and followers on user profile pages.

Example: Jack's profile at straycat.brainstorm.social. See 🍇-Rank and 🍇-Verified Followers at the top of the page. Nonstandard metrics, including personalizedPageRank , hops and verifiedReportersCount are also shown.

stratification of followers

Followers can be stratified based on either of these two standard metrics, verified follower count or user rank. This could be particularly useful for any user who wishes to peruse the timelines of followers and consider which ones to follow back without wasting time on bots and other bad actors.

Example: Jack's followers at straycat.brainstorm.social.

stratified reactions

Stratify reactions to kind 1 notes and other content according to rank , followers, or some other standard (or nonstandard) NIP-85 metric.

weighted 5-star averages

NIP-85's rank metric is ideally suited to be used as an egalitarian [4] weight for 5-star average ratings, assuming it is designed to have the following interpretation:

• a rank of 100 means this is a verified user. The method of verification depends on the Trusted Service Provider. For Brainstorm, it means a GrapeRank score above an adjustable threshold.

• a rank of 0 means this is not a verified user. Known bots and bad actors (flagged by trusted users) as well as completely unknown users (no follows, no zaps, no content, no proof of work, nothing to go on) should have a rank of 0.

• A rank between 0 and 100: partially verified user. In other words, probably not a bad actor, but there is insufficient data to say that with 100% certainty. (Imagine someone 3 or 4 hops away from you with only a small handful of verified followers.) Depending on how rank is calculated, the partially verified category could very easily be much larger than the verified category.

The problem with average 5-star ratings is that bots and bad actors skew the results. Weighting each rating according to the rank of each rating's author is an excellent way to alleviate this problem.

Excellent candidates for immediate integration: Pollerama and Bitcoin Mints, which have already incorporated 5-star rating averages. Also: any nostr marketplace that incorporates product ratings.

vote tallying and other weighted sums

Imagine you want to tally up votes to get a total vote count. As above, we don't want bots and bad actors to skew the results. So instead of adding up all votes, add up the rank metric for each voter (and then divide by 100).

Weighted sums can be used to establish lists that are curated by your web of trust. The lists can be lists of anything - limited only by the raw data available to you. Example: using raw NIP-56 (reporting) data weighted using rank metrics, Brainstorm instances enable your Grapevine to curate ranked lists of impersonators, spammers, and other reported nostr profiles.

composite NIP-51 lists

Imagine creating a regex keyword search engine for NIP-51 lists and combining each returned list into a single, composite list. Now imagine filtering out lists from the search results authored by bots and other bad actors. This is easily implementable using NIP-85 trust metrics. The simple method: exclude lists authored by anyone whose rank or followers metric is above some arbitrarily chosen threshold. Slightly more complicated method: For each item on the composite list, add up the number of times the item shows up on one of search results. That number could be included in the composite list, used to turn it into a stratified list, and/or used as a cutoff for inclusion in the composite list. Even more sophisticated method: instead of a simple count, use the list author's rank as a weight (as discussed above) when tallying the number of times any given item shows up on a list.

This method, looking for "Nostr Devs" in the title, will currently return quite a few lists and will yield a composite list of all Nostr developers, truly curated by your web of trust. Imagine now using that list to curate a list of NIPs. How cool would that be??

profile search

Regex search engine for nostr users. Use rank to filter out unverified users from the results, and display results according to rank or followers.

Example: Brainstorm profile search.

NIP-85 Integration Steps

NIP-85 requires scores to be personalized to a pubkey. Personalized to whom? When a client incorporates scores personalized to Alice, we may say the client is showing Alice's perspective or Alice's view. To show Trusted Assertions personalized to Alice, she must publish a kind 10040 note, and that note must provide the relay and author pubkey for kind 30382 Trusted Assertions. The integration of NIP-85 into any given client should begin with a single default perspective and should progress with more and more perspectives being made available to the user.

Step 1: Create the default perspective. Each client may wish to use the client developer's personal pubkey as the default. Alternatively, a flagship pubkey affiliated with the client, like NosFabrica, Catallax, etc, could be created for this purpose. Then use that pubkey to sign up for a NIP-85 Service Provider like straycat.brainstorm.social. A handful of follows, appropriate to the client, should be a sufficient basis for calculation of standard metrics.

Step 2: Enable selection of alternative perspectives. Example: See the Grapevine selector at the top of this Brainstorm instance profiles page. Each option in this selector should have a kind 10040 note that instructs the client how to look up the kind 30382 notes with the desired trust metrics (rank, followers, etc).

Step 3: Perspective autoselection. Use Trusted Assertions from the perspective of the logged-in user. If not available, select the perspective of someone in the user's follows. If none are available, then fallback to the client default view.

Conclusion

Nostr will benefit greatly from the cultivation of a healthy marketplace for third party personalized trust metric Service Providers. Trusted Assertions (kind 30382) and Declarations of Trusted Service Providers (kind 10040) are now created and published by Brainstorm instances and available to developers. Our next step should be to integrate NIP-85 standardized metrics, rank and followers, into at least a handful of clients. Once a demand for these services is demonstrated, it should inspire the creation of more third party personalized trust service providers with NIP-85 support. More such service providers will, in turn, stimulate the incorporation of personalized trust metrics into more clients in a positive feedback loop. The fact that third party trust metric service providers should be readily monetizable (using the subscription model of nostr.build or the hosting model of Relay Tools as two possible options) provides a strong argument that NIP-85 integration provides a fruitful avenue for bringing a more sophisticated web of trust ecosystem to nostr.

Notes

[1] as opposed to the case where the client requests a list of pubkeys meeting some criteria (e.g.: top N pubkeys based on verified followers count), in which an API-based method may be more appropriate

[2] Several nonstandard metrics, including personalizedPageRank, hops, and verifiedReportersCount, are also available.

[3] Different service providers do not necessarily have to use the same methods to calculate these metrics. Brainstorm instances use follows, mutes, and reports to calculate personalized GrapeRank, a number that ranges from 0 (not verified) to 1 (verified). NIP-85 rank is then calculated by multiplying GrapeRank by 100, and followers is the number of followers whose GrapeRank score is above an adjustable cutoff.

[4] Egalitarian in the sense that for many applications, we will want all verified users to be weighted equally. Note that there will be instances where we may desire a non-egalitarian weight, e.g. we may want the rating of an expert to carry more weight than that of a non-expert.