It usually doesn't repeat. The app calls it, gets a 403 and if it calls again the image comes. I am not really sure why. But since the hash is also frequently not matching, it could be something on your caching system.

Reply to this note

Please Login to reply.

Discussion

You mean calling image url or api? 🐢🐾🫑

This is easy to see in gossip logs when image loading is turned on. Many 403s, but when you open the url manually it's fine. I think it might be some kind of rate limiting where clients are trying to simultaneously do a lot of calls and something in the stack is deciding that's too many..

Do you mean calling the image URL? I need more info to be able to look into it 🐢🐾🫑

Yeah the image url

I haven't had any problems in amethyst though since I actually upgraded, so, apologies for any mis-filed bugs on that one haha. Google broke side loading and I was on an old version.. πŸŽ‰

I just checked all the rules and the only thing that is blocked on the image serving end, is favicon for different devices. If that is what you see for favicon under that domain, that is expected 🐢🐾🫑

We are only using the download url that comes from the NIp 96 API for now.

Ok, http-403 is not something that CDN would return, http-429 sure (if request rate is too high) 🐢🐾🫑