Does any client supports proxying images or links? If that's a client settings, users would control whether to use proxy or not, maybe even which proxy to use.
this post was submitted on 26 Feb 2026
104 points (99.1% liked)
Fediverse memes
3031 readers
404 users here now
Memes about the Fediverse.
Rules
General
- Be respectful
- Post on topic
- No bigotry or hate speech
- Memes should not be personal attacks towards other users
- We are not YPTB. If you have a problem with the way an instance or community is run, then take it up over at !yepowertrippinbastards@lemmy.dbzer0.com.
- Addendum: Yes we know that you think ml/hexbear/grad are tankies and or .world are a bunch of liberals but it gets old quickly. Try and come up with new material.
- This is not the place to start flamewars between Lemmy, Mbin and Piefed.
Elsewhere in the Fediverse
Other relevant communities:
- !fediverse@lemmy.world
- !yepowertrippinbastards@lemmy.dbzer0.com
- !lemmydrama@lemmy.world
- !fediverselore@lemmy.ca
- !bestofthefediverse@lemmy.ca
- !fedigrow@lemmy.zip
founded 1 year ago
MODERATORS
I don't know what "image proxying" is. Can someone give me the q&d?
It's a feature of Lemmy where your instance will proxy image links for you, it can be useful in some cases to do things like bypass regional censorships (If you can access your home instance from your country, but not instance lemmy.example.com your home instance can proxy the image from lemmy.example.com so you can still see it (text is handled by federation already, so no proxy required for just text)) or to cache images in case an instance goes down
But it seems to be poorly implemented where it's end user experience is a pain at best, and the more aggressive it's set the more annoying it is.
Take for example this instance I'm currently on, infosec.pub, they seem to have it set to aggressively replace all image links including in comments no matter what.
So now my attempt to reply to this comment https://infosec.pub/comment/20590443 is utterly broken because the image service just doesn't like it despite me just wanting to link to the off-site gif link manually typing the markdown instead.
This is what that gif looks like proxied:
https://infosec.pub/api/v3/image_proxy?url=https%3A%2F%2Fi.ibb.co%2F8gHKNsT1%2Fmichael-scott-why.gif
A good thing about proxying is that it prevents auto-loading of resources from potentially malicious domains. For instance, I could make an image comment containing an image link to a server I control. When you reply to my comment, since you clearly have seen my comment, I can now look at my server logs and see the IP addresses of everyone who viewed my image. I now know that your IP address is in that list.
Exactly this.
I've heard this security concern before, but I'm a bit confused about the real attack vector here. I mean let's say you do this - you post an image to some random Lemmy instance and behind the scenes, you gather all the IPs which fetch the image. What malicious thing could you do with that? Genuinely curious.
Hack their Gibson of course.
Neither of those links display an image for me. One shows a tiny empty box in your comment and the other lands me on a weird little error page about "msg too wide"
Yeah, because the proxy has decided it doesn't like it
This is what I actually wanted to link to/embed
https://i.ibb.co/8gHKNsT1/michael-scott-why.gif
Well actually I originally tried with a direct tenor link
But it didn't like that either
Tenor in particular is shitty like that too. If I directly link to a tenor gif on discord, people have to click the link and open a webpage to view the gif. To embed it in discord I have to save it and upload it.
"code": "validate-width",
"msg": "Too wide"
}```
stripped the headers, your image didn't make it through the infosec.pub proxy.
X-Firefox-Spdy: h2 access-control-expose-headers: vary, date, content-length, content-encoding, content-type cache-control: public, max-age=60 content-encoding: br content-type: application/json date: Fri, 27 Feb 2026 02:10:57 GMT server: nginx vary: accept-encoding, Origin, Access-Control-Request-Method, Access-Control-Request-Headers
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 Accept-Encoding: gzip, deflate, br, zstd Accept-Language: en-US,en;q=0.5 Connection: keep-alive DNT: 1 Host: infosec.pub Priority: u=0, i Referer: https://piefed.social/ Sec-Fetch-Dest: document Sec-Fetch-Mode: navigate Sec-Fetch-Site: cross-site Sec-Fetch-User: ?1 Sec-GPC: 1 TE: trailers Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0
The proxy link returns a funny error; “too wide.”
It's a gif of OP's mom
I was wondering why your reply shows up empty on my instance.
Interesting, I can comment on piefed (just did a test) to the comment above. But I get a new tab when I try to see the proxy link.
Is it the "?format= " at the end of a url that usually turns a quick download of a .jpg or .gif into a .webp or .webm download?
I fuckin hate webp format. Pointless format given the use case coverage between jpg and png.
I usually change the url to ".jpeg?format=jpeg" just in case that formatting takes any extra computing on their end. They want to use a boondoggle I'm gonna use the boondoggle.
Yep. And most damning, a lot of my image viewing or editing apps don't like the webp format.
I especially hate it when the source is already the same as whatever the target is, but it still breaks the image. Removing the format parameter suddenly makes the image work again, it's so dumb.
I like it because it protects my privacy.
pict-rs (the proxy software) is using ffmpeg in the background to recompile the image which will crash and burn it the image has even the slightest issue/corruption.
Pict-rs has options to specify maximum width etc which need adjusting else it blocks too much
Yea I know there are certainly tangible benefits like privacy, censorship bypass, caching etc
But the crux of the issue
using ffmpeg in the background to recompile the image which will crash and burn it the image has even the slightest issue/corruption.
Does it really need to do all that? IMO it's a proxy and it should just proxy things, not mess with things. Some basic checks at the most to just verify the image is an image and reject non-images, but that's it. If there's a need to also manipulate images then it should be handled separately
The idea is that by saving the image and thumbnail it saves on processing and bandwidth is the server hosting the proxy.
Pict-rs is the same image store used by Lemmy for it's own embedded images.
I agree with you that there are improvements to be made. I've spent too long troubleshooting images on lazysoci.al.