I keep noticing an issue with Primal’s caching system that’s causing some frustration. If you’re seeing a bunch of zeros on this dashboard on Primal, it’s due to a temporary API failure on our end. While the issue often resolves within seconds, Primal’s cache doesn’t update the original image path, continuing to serve the cached version instead. This is never an issue on Damus for instance, as the image path gets updated right away as it talks to the relay directly without a cache. This caching behavior definitely needs a fix, and I hope it’s addressed soon.

nostr:note19puum56jvmnhjzayz090mr7hwj4d9qxhhd434rlyhtpjtp2svg7semgvtc

Reply to this note

Please Login to reply.

Discussion

v interesting problem

I get that using a cache system could provide a very smooth rxperience making Primal prone to outages and what not but I’d prefer to get the notes directly from the relay without any caching on the middle. I’m sure Primal will never do it but technically they can filter/censor the feed from the cache which technically makes the whole thing centralized.

I thought turning off the option "enhanced privacy" would stop caching server being used and content gets pushed straight into their relays, when turned on it hides the ip via caching server and IP is never shared with the relay

No, the caching service is still active whether enhanced privacy is turned on or off.

I just recently learned how Primal handles caching compared to other clients. I have noticed a few issues as well. It will be interesting to see how the devs deal with it as the problem seems to be gaining more attention recently. Thankfully there is no shortage of Nostr clients to try out in the meantime.

Side note, I’ve been following the development of nostr:npub1gkkahxwca30rf2td22u9p3jnmlh79dylgmm2et0kykftle6tdcysj4zden , it looks to be a promising alternative to the “block clock!” I check the web dashboard frequently to see what’s new! 👀

Thank you, I appreciate it!