I created a quick diagram to illustrate the Primal cache issue in a simplified way that may help some people understand what is going on and help with choices about which client to use. There are many ways to build clients and there are advantages and disadvantages of each.
In Primal’s case, notes are served from Primal’s cache server which gets notes from the relays rather than the client getting them directly from the relays. The advantage to this is that much of the processing can be done on the server side resulting in a very smooth and consistent experience for users.
The down side to this is that it becomes centralised as, without the server infrastructure operated by Primal themselves, the client completely stops working (the cache is open source but I’m not aware of any other instances of the Primal cache being run and most users wouldn’t use a different one anyway). The issues with this centralisation are that it make Primal much more prone to outages and it would be very easy for ISPs to block Primal just by DNS blocking of the Primal cache server or blocking the associated IPs. Primal could also potentially filter or censor the feed from their cache although I’m not aware of whether they actually do this currently.
For me personally, I want a client that talks directly to the relays and does the processing locally but others may be comfortable with the limitations and loss of decentralisation and find that Primal provides a good experience.
One of the best things about Nostr is that you can take your key and move to a different client. It is worthwhile experimenting with different clients to find the experience that best suits you. 💜🫂
