• Users only reveal their IPs to their home Lemmy instance (or, at least, to whomever is hosting the Tesseract instance they’re using). Other Lemmy instances will only see the IP address of the Tesseract server.

  • You can cache GET requests to the /image_proxy/ path in your reverse proxy (or, sigh, Cloudflare) to be a good netizen and reduce the load on remote instances. If you run a large instance, you will only have to fetch a remote image from another instance once time for as long as the cache duration is set. At least one hour is recommended.
  • Note: Direct caching is a work-in-progress optional feature so you can do the caching directly within Tesseract. Plan is to make it optional and allow configuring a max cache size (e.g. 2 GB) and a cache duration (e.g. 1 hour).

• Faster, more consistent loading. Since all of the images will be coming from the same origin, connection multiplexing can significantly speed up retrieval for your users. Combined with image caching, significant performance increases can be expected (haven’t done any benchmarks, just basing expectations on one to many HTTPS vs one-to-one.

Does this work?

Escucha

Escucha

Test