Subnostr

That won't be enough. I tested it before. We have to encode the url (usually in base64), otherwise many images will simply fail to load. It's a mess. I gave up back them because it was creating more problems than solutions. It was common for the proxy to fail and the user would blame us for not showing the image correctly (censorship! 🙄)

Yonle 1y ago

Well, better not encode the URL to base64.

Try do something like encodeURIComponent() instead:

```

> encodeURIComponent("https://google.com") 'https%3A%2F%2Fgoogle.com'

```

You may add a switch to "request directly on failure" for that case.

[Still it may be useful for certain end users as compressor proxies are self host-able nowadays like https://github.com/Yonle/bandwidth-hero-proxy (for Bandwidth Hero browser addon)]

Reply to this note

Please Login to reply.

Discussion

Vitor Pamplona 1y ago

Yep we tested the basic url encoder with imgproxy for 4 months last year. Things would break so much that I had to move to their base64 version of it. Then I discovered that half of the formats weren't getting reduced in size and gave up :(

https://github.com/imgproxy/imgproxy

Vitor Pamplona 1y ago

It has to be something that works 100% of the time and when it doesnt, there has to be a way to alert the user that their proxy service sucks. Otherwise, it's going to rain complains on our emails.

Vitor Pamplona 1y ago

We probably need to teach people to add a caching server or a CDN in front of the proxy, otherwise processing compressions can get really expensive, even for single user servers.