Scaling Nostr via Open Caching Services
The idea that a user can sign a note and publish it to any number of relays is incredibly simple and powerful. That signed note can then be relayed further and with every new copy it becomes harder to censor. This core simplicity has made Nostr very popular with developers and users.
However, the brunt of the work is currently being done by just a handful of relays:
Given today’s network topology, it is not clear how Nostr could support say 100M users. In addition, the current breed of Nostr clients – while being impressive achievements of decentralized social media – suffer from sluggish UIs when compared to their legacy centralized counterparts.
Let’s consider an approach that might help with scaling, UX, and perhaps even decentralization.
Caching Services
Imagine a service with the following characteristics:
Stores all public Nostr content. Connects to all known Nostr relays and collects content in real time: user metadata, notes, reactions, all events. In short, the entire public Nostr network.
Can keep full archive or pruned content. Content can be pruned when the allocated disk space runs out. Service operators can decide how much of Nostr they wish to keep.
Provides fast response times. Clients connecting to the service can expect response times that match or beat the legacy centralized networks. Most content is served from the RAM.
Provides simple aggregations. Counters for likes, replies, reposts, zaps, and sats zapped are included with every post in the feed.
Such a service is definitely useful for many different applications. But wouldn’t standing up a service like this introduce a centralizing factor to Nostr? Let’s take this thought experiment a step further.
Now imagine that anyone can stand up a caching service with minimal effort and a modest hosting budget. Imagine that caching services are built in a standard and open manner, so that they can interoperate, sync content, and help bootstrap new instances. Considering the incentives, we could end up with hundreds of Nostr caches all over the Internet. Each new copy makes Nostr more robust.
Client Behavior
For Nostr clients, there are pros and cons to using a caching service. The obvious benefits are the UI speed and the improved UX. The downside is that a certain amount of trust is placed in the caching service. Let’s take a closer look at how this would work and how trust could be reduced.
The client connects to a caching service and immediately receives and displays the full feed for the specified user. To reduce trust, the client connects to a subset of relays in the background and fetches the content for comparison. Since all content is signed, the caching service can only lie by omission. The client displays and clearly visually marks any content it found on the relays that was not sent by the service. If the user loses confidence in a cache instance, they could simply point their client to another one, or turn caching off altogether. The client should be fully functional when caching is turned off. The ability to work with a caching service is an extension of Nostr client functionality, not a replacement for standard client capabilities.
When it comes to publishing, there are no changes to the standard Nostr client behavior: all content is published directly to the relays. Caching services should be viewed as a transient layer whose purpose is to improve the UX and reduce the load on the relays.
A Scaling Scenario
Let’s now imagine that Nostr is a raging success. The network has grown to 100M active users. There are hundreds of Nostr apps and services, thousands of active relays. Apps range from highly specialized “micro apps”, to the more elaborate Nostr “everything apps”, dedicated Nostr browsers, and other amazing things we can’t even imagine today.
In this scenario, it is likely that Nostr apps will use a range of caching strategies to serve their users. The most popular apps, with millions of active users, are likely to invest in their caching infrastructure. The up-and-coming apps that wish to compete with the best, but don’t yet have a lot of users are likely going to stand up small scale caching services and grow them as their userbase grows. Finally, there would be a number of apps that don’t use a caching service at all.
The beauty of this outcome is that even users who have millions of followers could publish their content to a handful of low-powered relays. As long as those relays are publicly accessible, the caching services will pick up their content and dramatically reduce the load on them. In addition, taking down any individual cache instance does nothing to hurt Nostr. Users can simply point their clients to any other cache instance, or the relays themselves. Censorship is strictly harder in a world where caching services exist. Those who wish to enforce censorship would have to take down all the relevant relays plus all the cache services.
Conclusion
Caching solutions for Nostr are inevitable. They are very useful, and the incentives are there for them to be built. The only question is whether they will be done in an open and interoperable way or a closed and proprietary way.
If you’ve made it this far, I know what you’re thinking: “Can we see this in action?”
Yes! A preview of this concept is available at primal.net.
The app itself is not fully functional yet, but you can definitely see caching in action. It’s fast. :)
We are actively developing Primal, so make sure you check back often. We have many juicy features in the pipeline. Feel free to reach out with feedback and feature requests. If you are going to Nostrica, then I’ll see you there in a few days! 🤙