Sorry, I probably made dm even messier. :CatBlush:

But not everyone is willing to hand over their nsec.

NIP-17 requires frequent encryption/decryption using the user’s keys. If a user accesses it via a browser extension, they would need to grant permission for all encryption/decryption requests at once. Otherwise, they end up constantly approving prompts one by one, often without really knowing what is being encrypted or decrypted, just blindly accepting them. If they use a bunker setup, the experience is even worse. For clients like Jumble, NIP-17 simply isn’t a viable option. On top of that, if the key is ever lost, all historical chat data becomes exposed. In the end, I tried implementing NIP-17 on top of NIP-4e (https://github.com/nostr-protocol/nips/pull/1647), which can address the issues above.

Jumble uses a DM protocol that isn't compatible with other clients.

My bad, I missed that.

I ran into a similar issue on iOS Safari before. It usually happened after focusing an input field. In that case it turned out to be a browser bug, so there wasn't much I could do to fix it. Fortunately, an iOS update about a month later resolved it.

Could you share a screenshot? Also, which browser are you using?

When a media resource fails to load, Jumble checks whether it's a Blossom resource. If it is, it will try loading it from each Blossom server in the user's server list until one works.

I know there are still some issues here. When a cache is available, it returns a promise, and if that promise doesn’t resolve within the timeout, it falls back to requesting the original URL directly. But in that case, the cache server should still have received the request, so I’m not sure why your cache server isn’t seeing anything at all.

Images rely on the browser’s caching mechanism. The browser caches them based on their URLs, so you may want to look up how to clear the browser’s image cache.