Open Seirdy opened 2 years ago
Thanks, @Seirdy !
I agree there are some performance and configuration issues that an image proxy could help work around.
In terms of real-world errors, the most common issues I see are images that are missing (or inaccessible due to a configuration issue) and mixed-content issues for folks whose sites are on http:
instead of https:
.
In terms of performance improvements with photos on the site currently, the most visible benefits would be in reducing the number of HTTP connections to individual sites, and in some cases serving smaller images when someone's photo
is quite large.
The performance changes in particular will only be useful for the Directory page.
In the interests of keeping this particular project as simple as possible, I have some constraints that put this out of reach for me at this time.
photo
URL changes, and maybe even every time a site is re-scanned, since folks can upload a new photo to the same URL. It also needs to honoring caching rules from each individual site's host, and gracefully handle images that are removed or otherwise disappear.All that said, I think the above constraints show the shape of what a functional image cache could look like, if you (or anyone) would be interested in working on that side of things!
I'll leave this issue open for discussion for now.
I think things are good as they are... if you are using http in 2022 is your fault that your site has mixed content issues same goes for other config. If the image is not reachable either the site is down or again is fault of the site maintainer.
I would support closing this issue.
Proxying remote images (IndieWeb u-photos) will reduce DNS lookups and avoid any CORS issues. With server-side caching, it could also reduce unnecessary traffic to servers of participating members. In the future, it could hypothetically open the doors to pre-processing excessively large images.