Has anyone figured out if/how/why nostr:npub12vkcxr0luzwp8e673v29eqjhrr7p9vqq8asav85swaepclllj09sylpugg caching collides with VPNs? Hours and sometimes days of slow or no loading/updates, while nostr:npub18m76awca3y37hkvuneavuw6pjj4525fw90necxmadrvjg0sdy6qsngq955 works uninterrupted.
Discussion
the primal caching server will be a huge bottleneck, afaiu all reads have to go through their relay, so you don’t get the benefit of load balancing across many different relays if one become unreliable
In my experience, it is *not* working out.
They can probably get there, twitter is proof of that. It will just take lots of redundant servers and scaling up their server architecture. It’s a completely different model than what damus is going for, we’ll see which one works out the best. It’s nice you can switch between them if there are issues on either side. nostr rocks !
The centralisation of a decentralised protocol now live on Primalbase
I haven’t noticed any problems with it and I use a VPN on all devices
I have wss://relay.primal.net as one of my relays. Maybe that makes a difference.
Well, then. This is new. 
That probably means you don’t have any relays set using nip-65. Possibly it got rugged by someone. Primal switched to nip-65 a while ago.
Not sure why the caching server is red for you though. It’s green for me rn.
Very strange. They were all in tact yesterday.
I recommend backing up your metadata regularly by visiting https://metadata.nostr.com
I also have issues when using it in combination with a vpn, main feed typically works but clicking a specific thread sometimes doesn’t load, not sure if it’s the VPN or primal