🪚🙂 My timeline images is heavier than my images being uploaded with Amethyst you know...
Discussion
Pretty much. That's why we decided to compress all new posts: to not add to the huge burden that nostr already has. But we can put an option to remove it for sure.
By the way, could you add a option for proxying attachments? There are times when i use tor, some images are not loaded because the origin host was blocking tor.
It could be used for adding compression proxy
Is there a standard API for proxies? All I see are multiple different standards on how to ask the proxy for images. So, it depends on which server people want to use. It's hard to code support for a good number of them. We had a NIP draft ages ago, but no one ever coded it. :(
mmmmm, this is quite complicated when it comes to standardized proxy API.
But if you don't want to get overwhelmed, Try to do the classic %s thingy:
```
https://www.example.com/?url=%s
```
And then let the user decide.
There are some numerous image compression services out there so it should not be hard for client.
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! 🙄)
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)]
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 :(
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.
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.
Especially for country under censorship，for instance,China.
It's always depending on their services. Yep. Could admit tho.
Wouldnt be better if a third party proxy app intercepted all app communications and made images go to their own proxy server?
