I am definitely with you on the issue with the client not verifying the signature on the notes locally, and you are absolutely correct that reading only from a single caching relay is a massive issue for censorship resistance, as has been seen in the past.

What's it take to run the caching service? I imagine that it's more resource intensive than a standard public relay by an order of magnitude, but is it feasible to be done? Are the resources needed to do so the barrier for why we haven't seen any others in the wild, or is it just that Primal tends to attract non-technical users that aren't interested in running their own infrastructure?

When it comes to NIP-01, surely the caching service must use NIP-01 to REQ from the relays it aggregates notes from, right? And the client is using NIP-01 to write events directly to the user's relays, unless they have the "enhanced privacy" feature turned on, so that the client writes to the caching relay, and the caching relay then uses NIP-01 to send EVENT write requests to the user's relays.

Now, I absolutely agree that this SHOULD be happening directly from the client, rather than going through the caching relay, but I also don't consider it so egregious a deviation from how I think Nostr clients ought to operate so as to classify Primal as not a Nostr client. That said, due to the censorship opportunities and past real examples we have, I would never suggest anyone use Primal as their only client. At minimum use at least one other client, and preferably one that has fully implemented outbox.