Nostr without caching has really poor performance the moment you add any features beyond notes and reactions. Even reactions degrade the experience significantly.
If your client works really well without caching then you are a superstar dev, because this protocol is not made to “just work”
My 2 sats after dealing with it for several days with an LLM. I know I’m a low benchmark but I’ve spoken to other prominent nostr devs who expressed this sentiment.
The user experience must be at the heart of all Nostr customer thinking.
It’s really hard because you’re constantly connecting to a bunch of relays and trying to sort the data. All of the burden is on the client.
I welcome any designer to try it for themselves. Go to lovable.dev, feed it NDK, and try to get a basic feed client going. Try to get the latest notes and all their reactions to display correctly and make sure you don’t run out while scrolling - then come back and tell me how easy it was 😂
Client server architecture is way easier to work with. You have one user making an auth request to one server and all their data is retrieved that way.
It does lend some credence to the ATProto team's take. Basically their take at the start was:
- Network-wide cacheing is basically inevitable to preserve the user experience at scale
- Scaled cacheing architecture is expensive and hard
- If the protocol doesn't handle it, clients will handle it themselves
- Because it's expensive and hard, only a one ore two clients will truly go all in on it, other clients will see this and just give up
- Users will flock to the one or two clients
- Other clients wither and fade
So they decided to make the network-wide cache basically a commodity that *all* clients have access to and thus remove the incentive for each client to invest in building the same thing as everyone else (and to a lesser quality level). I think there is some logic there, it does remove duplication of expense and might help ensure a more level UX playing field among clients (though need to wait for first batch of ATProto clients to mature to see if this bears out).
I think Nostr's general architecture is still the way forward but it's worth digesting these takes.
Some logic … but still super centralizing
What they’re going for seems to be poly-centric as opposed to decentralised. So instead of switching from Relay A to Relay B you switch from Alphabet 1 to Alphabet 2 (but both alphabets are still A-Z).
There's a big difference between local and remote caching.
I'm not entirely against remote caching, but I'd always make it explicit and be selective in the implementation.
There's local caching on my end, but the user deletes it of course, and ya as you said it's not a good idea to burden the user handle such a thing to have a proper site/app experience.
I'll be doing remote caching, but doing it in a way that it's only to run it in parallel to what's already there, where if my server goes poof, the site/app still functions, just not optimally.
And now after a discussion, it'd evolve into giving the user the ability to changing to different caching servers/services too, or turn it off completely if they want. Here's the previous talk about it:
and
