First one clarification: relay.primal.net is simply a vanilla strfry relay instance for Primal users (and others) to use. Sorry @fiatjaf, we’re not quite there yet.
Now the good part. We are definitely going to standardize the API of the caching service through a NIP. We’ll base it on the standard relay API and expand where needed, since the caching service has more features, as Tony pointed out. This NIP would definitely be optional, so I don’t think this adds a burden to the Nostr protocol itself.
It’s good to see that other projects are starting to spin up their own instances of the caching service. As I said before, if Primal ran the only instance that would be a fail. Primal clients will soon have the capability to connect to any number of caching instances, along with any number of relays via gossip. Therefore the client is not trusting a single server; on the contrary it has the ability to keep the caching service(s) honest. I described this pattern in a blog post when we introduced Primal back in March, but nobody seems to have read it (except for Tony, by the looks of it). 😂☠️
cc @PABLOF7z, @ hodlbod, @Alex Gleason, @DETERMINISTIC OPTIMISM 🌞, @ODELL
Habla
Scaling Nostr via Open Caching Services - miljan
Given today’s network topology, it is not clear how Nostr could support 100M users. Let’s consider an approach that might help with scaling, UX...