I've always been intrigued by Primal's caching server.
How does it work? What are the advantages, drawbacks, tradeoffs?
So I cloned primal-server and had a conversation about it with an LLM. With a clearer understanding, I input some of my ideas and here is a writeup of the result.
I am not a Primal hater (as many are). I respect the angle from which the team
@miljan @Marko @ODELL are tackling these hard UX challenges. If there is anything of value in here that can spark an improvement, awesome, if not, that's cool too.
A CENTRALIZED NOSTR-BACKEND
`primal-server` is a sophisticated, high-performance backend system that acts as a centralized processing layer for the Nostr network. It ingests a massive firehose of events from thousands of relays, processes them through spam detection and content moderation filters, and serves enriched, aggregated data to Primal clients through a proprietary websocket API. The system maintains a hybrid cache/database architecture that combines in-memory storage with PostgreSQL for complex queries, enabling features like intelligent feed generation, thread reconstruction, and personalized content filtering based on user mute lists and preferences.
ADVANTAGES AND CRITICAL FLAWS
The primary advantage of `primal-server` is its ability to transform scattered Nostr data into rich, contextualized information that powers a modern social media experience. It eliminates the need for clients to make dozens of round-trip requests by pre-computing complex queries like home feeds, user profiles with follower counts, and conversation threads. However, its spam detection algorithm is fundamentally flawed and easily gamed. The current system uses a simple content-similarity clustering approach that flags users with few followers posting similar messages. This can be trivially bypassed by varying message content slightly or using different accounts, while legitimate new users are unfairly penalized. A much more robust alternative would be a PageRank and personalized PageRank algorithm-based DVM that analyzes the social graph structure to identify genuinely influential users versus spam networks, providing both better spam detection and content ranking.
THE DVM ALTERNATIVE: STANDARDIZED, VERIFIABLE PROCESSING
A standardized DVM-based solution could replicate `primal-server`'s functionality while maintaining Nostr's trustless principles. Instead of a single proprietary backend, multiple specialized DVMs could handle different aspects: a "Feed Generation DVM" that accepts user follow lists and returns signed events with metadata, a "Thread Reconstruction DVM" that takes an event ID and returns the complete conversation tree as signed events, and a "Content Moderation DVM" that processes user mute lists and returns filtered event streams. Each DVM would operate on the NIP-89 (or newer) standard, accepting job requests and returning results that include both the original signed Nostr events and additional unsigned metadata.
IMPLEMENTATION STRATEGY AND BENEFITS
The key insight is that DVMs don't need to be simple microservices—they can be as sophisticated as `primal-server` itself, but with standardized interfaces. Just as an example – a "Feed Generation DVM" could maintain the same complex database architecture, caching layers, and optimization strategies as `primal-server`, but instead of serving a proprietary API, it would accept standardized job requests containing user parameters and return both signed events and enriched metadata. This approach would preserve all of `primal-server`'s performance benefits while eliminating its centralization problems. Any client could use any DVM implementation, creating competition and preventing vendor lock-in. Users would receive the original signed events they can cryptographically verify, while still benefiting from the enriched metadata and processing capabilities. The standardized DVM protocol would allow for interoperability between different implementations, and other vendors could run their own DVMs for maximum control.
