Nostr escaped the platform trap. Your identity lives in your keypair, not a corporate database. Your notes live on relays you choose, not servers controlled by people who want to manipulate what you see. But there's a piece of the puzzle that remains unsolved: algorithmic curation.
Even decentralized networks need ranking. Without some way to surface signal over noise, a social protocol drowns in spam, bot networks, and context-free posts from strangers. The question isn't whether Nostr needs algorithms. The question is who controls them.
Two architectures have emerged to address this, each suited to different use cases. The first treats algorithms as services: you send a request, a server computes a result, you get an answer. This is the Data Vending Machine model, exemplified by projects like Vertex. It excels at real-time personalized queries where you need recommendations on demand.
The second architecture treats algorithms as Nostr citizens. This is NIP-85, Trusted Assertions. Instead of asking a service for scores on demand, algorithm providers publish all their scores as signed Nostr events. Tens of thousands of them. Every pubkey gets a score, every score is visible, every change is auditable. Users don't call an API. They follow an algorithm-key and subscribe to its outputs like they'd subscribe to any other Nostr feed.
The difference sounds technical. It isn't. Both models require trusting an operator who runs computation you can't verify. But they serve different needs and offer different tradeoffs.
DVMs shine at discovery and real-time personalization. You send a request with your pubkey and a target pubkey. The service computes a score based on your specific position in the social graph and returns it immediately. This is valuable when you're looking for recommendations, when you need results tailored to your network position, or when the computation is too expensive to pre-compute for every possible query.
NIP-85 serves a different purpose. The algorithm provider runs their calculations and publishes kind 30382 events to relays. Every pubkey gets a score, and those scores become persistent and queryable. The provider could still lie about what algorithm they're using. They could still manipulate individual scores. But the outputs exist as Nostr events that anyone can examine, compare across time, and analyze for inconsistencies. You can run the same query against three different algorithm-keys and see how their outputs differ. You can notice if a specific pubkey's score changed dramatically without obvious cause.
This doesn't eliminate trust. It enables a different kind of accountability through observability.
This is the insight that makes NIP-85 philosophically significant: each algorithm becomes an identity you can follow. The algorithm-key is just another npub. Its outputs are just another feed. Your trust relationship with that algorithm works the same way your trust relationship with a human account works. You can observe it over time, compare it to alternatives, and abandon it if its behavior changes in ways you don't like.
The tradeoffs are real. Vertex, which provides DVM-based web of trust services, has noted that pre-computed scores don't help with discovery. When you don't know which pubkeys you're looking for, you can't query for their NIP-85 assertions. A real-time service can recommend pubkeys based on your social graph; a database of pre-computed scores cannot. Processing a hundred thousand assertion events client-side is also computationally expensive, especially on mobile devices.
These are genuine limitations, not flaws. NIP-85 is better suited for verification than recommendation. If you already have a pubkey and want to know how trustworthy it is, querying pre-computed assertions works well. If you want to find new accounts to follow, a DVM makes more sense.
The computational burden is also real, but the burden is a choice. Heavy clients can process assertion events locally. Lightweight clients can trust a relay to filter for them. The point is that the data exists in a form that permits verification. Even if most users never audit their algorithm's outputs, the possibility of auditing changes the incentive structure for algorithm providers.
The case for NIP-85 is that it lowers the barrier to publishing algorithmic perspectives. With a DVM, you need infrastructure: a server running to handle requests, uptime, scaling. With NIP-85, you compute your scores, sign them, publish them to relays, and walk away. Anyone with a laptop and an opinion about trust can become an algorithm provider. The relay handles storage and queries. You just publish your view of the network as signed events.
This creates a different kind of market for algorithms. When outputs are published, providers can be compared. A provider whose scores diverge suspiciously from competitors, or whose rankings correlate with factors unrelated to stated methodology, faces reputational risk. Users can switch to a different algorithm-key. This isn't trustlessness. It's the weaker but still useful property that manipulation becomes harder to hide.
The architecture also enables interesting compositions. A user could follow multiple algorithm-keys and combine their outputs. They could weight recent assertions more heavily than old ones. They could filter for algorithms that other accounts they trust have also chosen to follow. The algorithm layer becomes subject to the same web of trust dynamics as the content layer.
The ecosystem needs both. DVMs handle real-time personalized recommendations, computationally intensive queries that don't make sense to pre-compute, and use cases where latency matters. NIP-85 handles verification, historical comparison, and use cases where observability matters. A client might use a DVM to discover new accounts to follow, then check those accounts against NIP-85 assertions from algorithm-keys it trusts. The two approaches compose naturally.
NIP-85 adds a useful tool to the kit. Algorithms can publish their outputs as protocol data, available for comparison and analysis, while DVMs continue to handle what they do best. Different problems, different tools. Nostr gave users portable identity. Between DVMs and NIP-85, it's building portable curation too.