You mentioned both in the same comment…
[…] NPR apparently blocks the former
I’m just saying, their employer can’t block like NPR does, because they are fundamentally different things. The one is a server receiving a request, the other is a firewall seeing encrypted packets.
Edit: the other could also be a DNS resolver that just does not resolve certain domains.
Are you sure? In your post you’re talking about fetching an image for a link preview, not an image post.
Usually, when I see an image post, the source is actually the pictrs of the source instance, so in that case I think it is federated.
You’re talking about 2 different kinds of blocking here. NPR can’t block a URL, that concept doesn’t really exist at this level. They could block ip addresses, or user agents as you mentioned.
A workplace can’t block by user agent (at least not on any website using TLS), as this header is not readable by any intermediary devices.
That’s weird. Is that how it’s supposed to work, or did they just implement it in a bad way?
I don’t think compute resources should be an issue, if anything it saves other instances resources.
As far as I understand, right now, all instances are fetching this data individually, so they all have the same compute load from this. Doing it on one and sending it along with federation should keep resource useage pretty much the same on the originating instance, and less for all others.
This would still increase bandwidth of course, but at least with all VPS providers I have used, bandwith is pretty cheap.
I figured a post with a link with preview image wouldn’t be the same in terms of event as an image post. Turns out it pretty much is, but also, I checked a few posts and cross-posts across instances, all of them have an image url of the original instance, not the one I’m viewing on. So if they are individually fetching this image, they’re not using it.
Edit: I was wrong, two of the crossposts just didn’t respond to the request for activity, so I was looking at the wrong response data