sorting and filtering, not ranking

Why can’t a client alone do it?

How do you personalize it?

No they had a trust rank. Which was more of an internal thing but it existed. They calculated a trust rank for domain owners and authors which wasn’t openly publicized. And they backed it up with the DMOZ Directory that they had acquired. But when the commercial websites came, they quickly dropped that algo, because BMW & Co had absolute no trust rank by then 🙂.

Hiding it is even worse. Imagine if all the clients brought in shadowbans.

Just let amethyst be the safe space echo chamber app for onboarding bluesky users who love censorship.

I'm 100% serious

2 very successful WoT like relays i've seen so far are Spatianostra and Primus. Yes we could use more, but growth is always going to come from community building and relays are the way to go for that.

Have you joined any of our weekly #wotathon community calls?

I didn't realize a rebuild was underway. Good to know, thank you

Same, it seems very Black Mirror.

It should be fixed when we start broadcasting 🤞🏻

In 1992, Phil Zimmermann added a feature to PGP version 2.0 that was supposed to solve one of cryptography's hardest problems. He called it the "web of trust." The idea was elegant: instead of relying on certificate authorities to verify that public keys belonged to their claimed owners, users would vouch for each other. You sign my key, I sign yours, and through chains of these signatures, strangers could eventually trust each other's identities.

The vision was decentralized. It was also a complete failure.

Thirty years later, the PGP keyserver network is dead. GnuPG disabled web of trust functionality by default after spam attacks made keys unusable. The dream of cryptographic trust without central authorities died not because the math was wrong, but because the design asked too much of humans.

Nostr has quietly built what PGP could not. Its web of trust works precisely because users never have to think about it.

## The Ceremony Problem

PGP's web of trust required users to perform explicit trust rituals. You would attend a "key signing party," verify someone's identity through government documents, sign their key with your private key, then upload that signature to a keyserver. Back home, you would configure your keyring, assigning trust levels (unknown, marginal, full, ultimate) to various keys. The software would then calculate which keys were "valid" based on weighted combinations of trusted signatures.

This was not a workflow that scaled beyond cryptography enthusiasts. Tim Berners-Lee, reflecting on why PGP never achieved mass adoption, noted the UX failures: dialog boxes telling users to "do X" with no button to do X, multi-step processes to download and sign keys without explaining what any of it meant, the general sense that using encryption required joining a secret priesthood.

But the deeper problem was structural. Most users believed the web of trust worked like "six degrees of separation," where trust would propagate through long chains of connections. It did not. As Hal Finney explained in 1994, "You can only communicate securely with people who are at most two hops away in the web of connections." You could trust keys signed by people you personally knew. That was it.

By 2019, the keyserver infrastructure was collapsing. Malicious actors discovered they could flood popular keys with thousands of garbage signatures, causing GnuPG to crash when importing them. The SKS keyserver network, which had synchronized keys globally since the early 2000s, shut down entirely in 2021 after operators couldn't process GDPR deletion requests for a system designed to be append-only.

The explicit trust model created a bureaucracy. Bureaucracies don't survive contact with spam.

## Trust as Byproduct

Nostr takes the opposite approach. Instead of asking users to perform trust ceremonies, it extracts trust signals from actions they already take.

When you follow someone on Nostr, you publish a kind 3 event listing every pubkey you follow. This is not a security ritual; it is the normal behavior of using a social network. But that follow list, signed by your key, is now a cryptographic attestation. You are implicitly saying: these are the people whose content I want to see, whose judgment I find valuable enough to include in my feed.

When you mute someone, that too becomes a signed event. A warning to anyone who shares your sensibilities.

When you zap someone,, you attach an economic cost to your endorsement. Fake accounts are cheap; sats are not.

The Nostr protocol did not invent these actions. Follows, mutes, and tips existed on centralized platforms for years. What Nostr did was make them cryptographically signed, publicly attestable, and aggregatable into trust scores. The same behaviors that made Twitter addictive now make Nostr's web of trust function.

This is the design insight that eluded PGP: trust should be a byproduct of normal activity, not a separate task requiring special knowledge. The cypherpunk who wants encrypted communication and the normie who just wants to shitpost both produce useful trust signals by doing what they were going to do anyway.

## Computing Trust from the Social Graph

Raw follow lists and zap receipts are data. Turning them into usable trust scores requires computation.

The dominant approach borrows from Google's original insight. PageRank, the algorithm that made web search work, solved a similar problem: determining which pages were important based on link structure. A page linked by many important pages was itself important. The algorithm was resistant to spam because creating fake pages that linked to you didn't help unless those fake pages were themselves linked by real pages.

Personalized PageRank adapts this for social trust. Instead of computing a single global importance score, it computes importance relative to a specific user's position in the graph. If you want to know how much to trust some pubkey you've never seen, the algorithm simulates random walks through the follow graph starting from your account. The more often those walks land on that pubkey, the more connected they are to people you already trust.

This is what Nostr.Band does when filtering search results. It seeds initial trust to accounts with verified NIP-05 identities, then lets PageRank propagate through the network. "If initial weight is given to a spammer by some accident," their documentation explains, "they are most likely losing it all by the end of the calculation, because almost no one interacts with their content."

Coracle, the client built by hodlbod, implements a simpler version directly: your WoT score for someone equals how many people you follow who also follow them, penalized by how many people you follow who have muted them. Crude but effective.

## Vertex and npub.world

For developers who don't want to build graph analysis infrastructure, Vertex offers web of trust as a service. Their system crawls Nostr follow lists continuously, computes Monte Carlo PageRank scores, and exposes them through a DVM (data vending machine) interface. Query with a source pubkey and a target pubkey; get back a personalized trust score, follower counts, and the target's highest-ranked followers.

The companion tool npub.world provides a search interface for finding profiles within the Nostr network, leveraging the same trust infrastructure.

Vertex explicitly rejected the emerging NIP-85 standard for "trusted assertions," which takes a different architectural approach. Under NIP-85, service providers publish kind 30382 events that make claims about entities. The `d` tag identifies the subject (typically a pubkey), and additional tags carry the assertions: a `rank` score, follower counts, zap totals, or any other metric the provider computes. These events sit on relays like any other Nostr data, and clients can subscribe to assertions from providers they trust.

The model has appeal. It keeps everything in Nostr's event system. Users choose which assertion providers to trust, similar to choosing which relays to use. A client could subscribe to assertions from three different WoT services and weight them according to user preferences. The data is cacheable, auditable, and portable.

But Vertex identified a fundamental limitation: NIP-85 assertions are computed for a generic audience, not personalized to the querying user. If you ask "how trustworthy is pubkey X," the answer depends on who is asking. Your social graph differs from mine; your trust scores should differ too. Pre-published assertions cannot capture this. They answer "how trustworthy is X according to service provider Y" rather than "how trustworthy is X from my perspective."

The deeper problem is discovery. Static assertions require you to already know the pubkey you want to evaluate. But web of trust should help you find trustworthy accounts you don't yet know about. "Who should I follow?" is a harder question than "should I trust this specific person?" Real-time personalized computation, responding to the specific user asking the question, enables recommendations that static assertions cannot.

This is an ongoing debate. The WoT-a-thon hackathon running through April 2026 is pushing for NIP-85 adoption, with a dedicated prize track for implementations. Different approaches will compete, and the protocol will evolve. The tension between pre-computed portability and real-time personalization may not have a single correct answer.

## What Remains

Nostr's web of trust is not a solved problem. New users face a cold-start problem: without history, they have no trust scores, making it hard to break into existing networks. The computation itself, while based on decentralized data, currently runs on centralized services like Vertex and Nostr.Band. Public follow lists, which make WoT possible, also leak social graph information to anyone watching relay traffic.

But the fundamental architecture is sound. Trust signals emerge from normal behavior. Algorithms convert those signals into personalized scores. The user never has to attend a key signing party.

Zimmermann's 1992 vision was right about the goal: decentralized trust without certificate authorities. He was wrong about the method: asking users to do extra work. Nostr's contribution is recognizing that the work was always happening. It just needed to be captured.

---

**Artwork Suggestion:** "The Syndics of the Drapers' Guild" by Rembrandt van Rijn (1662). Guild officials whose role was verifying cloth quality through reputation and repeated honest dealing. Trust built through commerce and mutual accountability within a network, not through central certification.

This is def an intriguing experiment. If one trust calculation service becomes dominant, you’ve effectively recreated Twitter’s recommendation algorithm problem, just with extra steps though.

Is this where we want to go? I understand we want to solve real problems….spam, impersonation, and signal-to-noise ratio issues that plague open protocols but…? 🤔

I think that math was wrong. The 10,000,000 keys was not the number of keys inside the filter (which for NIP-76 would be 2-3 keys on average). But relays would have to check that filter against 10,000,000 + keys that can connect to them. The false positives claim was based on testing 10,000,000 keys against a simple filter like that.

I think that math was wrong. The 10,000,000 keys was not the number of keys inside the filter (which for NIP-76 would be 2-3 keys on average). But relays would have to check that filter against 10,000,000 + keys that can connect to them. The false positives claim was based on testing 10,000,000 keys against a simple filter like that.

I think that math was wrong. The 10,000,000 keys was not the number of keys inside the filter (which for NIP-76 would be 2-3 keys on average). But relays would have to check that filter against 10,000,000 + keys that can connect to them. The false positives claim was based on testing 10,000,000 keys against a simple filter like that.

They do, and I think individual scores will always be there.

But downloading 100K individual scores takes a while, uses a lot of data and space in the disk of the phone. Having ways to minimize that usage while providing some rough level of trust enables some light clients to exist.

For instance, a user search or tagging could use NIP-50 to download all the shit on relays and then filter by local bloom filters to know which users are real ones. If bloom filters are not available, then the app needs another round trip to download the individual scores of each key and discard them all when the user closes the search screen.

Internally yes (I have not saved into events yet). All my event, address and pubkey relay hints are saved as 3 massive bloom filters. So, when the app needs to figure out which relays have given IDs, it checks the filter. Which means that I don't need to save any of the events.

I have been doing:

:::

So,

100:10:AKiEIEQKALgRACEABA==:3

Means 100 bits, 10 rounds and the salt is 3

Then we can force in the event kind to always use MurMur3 for 32 bits (the best hash function).

The kind 9998 list header declaration could specify the hashing algo. Or we could leave the hashing algo unspecified and recognize that it is not necessary for all clients to support all hashing algos, just like it’s not necessary to support all NIPs. Probably the community will gravitate to one algo organically, unless some devs have strong preferences that are not always aligned.

If getting everyone to agree to all the details is trivial, is there any reason not to go ahead and write up a bloom filter NIP?

Not everyone, just those using the specific kind.

The main issue is that there are thousands of potential hash algorithms to use in bloom filters. If we leave it open, all clients must implement ALL hashing functions just so that things don't break when they suddently face a hash that they don't support. Which, in the end, means that nobody can declare full support to the NIP because there are always new algos.

Also, there is not really a huge gain from tweaking hashing algorithms for Bloom filters. We just need one that works and everybody will be happy.

Just like we only use SHA256 on nostr events.

I have been doing:

:::

So,

100:10:AKiEIEQKALgRACEABA==:3

Means 100 bits, 10 rounds and the salt is 3

Then we can force in the event kind to always use MurMur3 for 32 bits (the best hash function).

People can use many hash types, rounds, sizes and so on. We need to specify it.

That's because the free relays allow anyone to connect and the scammers and bots fill up the hard drive and slow it down.

The paid relays don't fill up very fast and are quite fast because it's only users that are willing to pay. The future is paid relays for npubs that are serious about using nostr.

Every relay right now has the kind 0 data and we are fine. The only relays that purge their data is the free relays.

I see what you mean. Yes we can have different reays but I'm sure eventually the direction nostr will go is less powe to the relays and more power to the client.

Why does it need to be specific relays? A better solution would be for NOSTR to introduce a NIP where users can specify their country, state, city, etc., and this info gets propagated across all relays. That way, we wouldn’t rely on just one relay; every relay would have the same data. If one relay goes down, the info is still available on others. This eliminates the need for country-specific relays entirely.

Relays are just a place to store our notes and data, relays are not going to become a community

yes that sounds good but why do I need to go on that website to do it, why can't I just add my country on my client like amethyst and then it will just give me country feed.

The client is where the power is, not so much someone's website

You can't right now. It's not possible. I'm saying they should add those type of feeds.

relays feeds don't make sense. Relays are just to store our notes and nothing else. I joined your relay because it was cheap not because I wanted to be part of your relay.

Everyone is joining relays with that same reason. They should just make us enter out country, hobby etc. to our profiles then we can use that event to see "country" feeds etc