Rewrite images to use local proxy

[Nutomic]

I decided to play around with markdown handling to see how we can rewrite image and link urls. Turns out its pretty simple. So far it does this:

• Add rel=nofollow to all links to discourage spammers. Note that this wont affect lemmy-ui or other frontends as they do their own markdown rendering. It will only affect emails, RSS feeds and different federated platforms.
• Rewrite all images to https://lemmy-alpha/api/v3/image_proxy?url={url} so that users dont connect directly to remote servers.

This PR doesnt have any breaking changes so it can be merged whenever.

Todo:

• Testing
• Use pictrs 0.5 for image proxying
• Add config option for image_caching (disabled by default for now)
• Need to handle image urls differently, so that api clients dont have to manually rewrite them with proxy url (Rewrite image links in markdown markdown-it-rust/markdown-it#36)
• Call markdown_rewrite_image_links() on all markdown before writing to db (api and apub)
• Also rewrite images for avatars, banners etc
• In image_proxy handler, check that image url corresponds to federated image so that it can't be abused as proxy for arbitrary purposes. This means keeping a db table of known remote images, and passing a db connection into markdown parser to write to the table. Remote avatars, banners etc also need to be written.
• Rewrite markdown links in RSS feeds, emails to set rel=nofollow
• Cleanup request.rs which generates link metadata and thumbnail
• Store content type of post.url in database
• Rename setting cache_remote_thumbnails to disable_external_link_previews
• Rewrite post url with proxy
• Federate post url as Activitypub Image based on mime type for better compatibility
• Add a cache for proxied images with configurable size, stored on disk (or rather leave this to nginx?) -> leave to pictrs

[dessalines]

@asonix would using the lemmy-backend to proxy picture requests be a better approach, or maybe waiting for pictrs v.50 which has picture proxying, and using those pictrs routes? Any pros/cons to either?

[asonix]

proxying images through lemmy is fine, but it means the original server must be online and capable of serving the image for each request. using pict-rs' proxy method in 0.5 will cache the proxied image and reduce load on the original server

I think doing this initial proxy work now probably makes sense, and using pict-rs' proxying in the future can be made a lower priority (and give more time to folks to upgrade to 0.5 when it releases before you start depending on 0.5 endpoints)

[dessalines]

In that case @Nutomic just add a TODO somewhere that we can remove this once pictrs 0.5 is released.

[Nutomic]

Sounds good, adding comment.

[Nutomic]

Changed it to use pictrs for proxying. Also added a config option for image proxy which is disabled by default, with comment noting that pictrs 0.5 is required.

[dessalines]

One other concern I have that makes me think image proxying should probably be done in front ends: cross-posting.

If a link URL points to an image on instance1.tld/...pictrs/, then its currently possible to see all its cross-posts across the lemmyverse. That might not work correctly if we rewrite all image links.

IE so maybe instead of actually rewriting links, we just provide the image_proxy endpoint, and let front ends use it.

[Nutomic]

@dessalines If multiple posts have the same url, those will all be rewritten to the identical image_proxy url so crossposts will still work. If this logic is handled in the frontend then each one will have to reimplement the same logic, doesnt make sense.

[Nutomic]

This setting might be unnecessary now. However the file request.rs where its used is quite the mess, not sure when I can get around to cleaning it up (it needs almost a complete rewrite).

[Nutomic]

Ready to review now.

Edit: Did some testing using local docker setup and its working as expected

[dessalines]

This block here is confusing now. Maybe we should remove cache_external_link_previews entirely now, and just leave image_proxy?

[dessalines]

The cache_external_link_previews and image_proxy seem like two bools that refer to the same thing now then.

I'm tracing down every usage of RemoteImage::create, and sometimes it uses the first setting, sometimes the 2nd. We should simplify and get rid of one of them.

[kroese]

@dessalines The cache_external_link_previews setting has a bit confusing name, I wish it was called store_thumbnails or something like that. Because that would make it much more clear what the setting does.

But it doesn't refer to the same thing, its purpose is to specify wether you want to store thumbnails locally (in pict-rs), or just hotlink to external images. And the image_proxy setting specifies if you want to use a proxy for external thumbnails.

In my case I dont want the images to be proxied and I also dont want to store them locally. So a single setting would not be enough.

[dessalines]

@kroese @Nutomic in that case they seem exclusive then, and we have 3 options, and should use an enum rather than 2 bools:

• Use the pictrs proxy for all external images
• Save all external images (cache is a bad term anyway)
• Directly link to all external images

Some names could be {UsePictrsProxy, SaveInPictrs, UseDirectLink}

[kroese]

Yes they are exclusive, because the value of image_proxy has no meaning until you set cache_external_link_previews to false. So I agree an enum would make more sense.

Also in the current release there is a bug that cache_external_link_previews is only applied to thumbnails coming from federated posts. But it should also apply to thumbnails generated from the og:image metadata for local posts. I hope this pullrequests solves that issue.

[Nutomic]

Makes sense, Ive converted it to an enum now. You can see it in config/defaults.hjson. For now Im keeping the existing behaviour as default to avoid breaking changes in a minor version. But if the proxying works well might be able to remove StoreLinkPreviews in 0.20 and make ProxyAllImages the default.

[kroese]

I still think the naming is not as clear as it could be. The setting is called image_mode but there are other types of images (inside comments, avatars, banners) to which the setting doesn't apply. Also values like StoreLinkPreviews are way more verbose than needed.

If it was my decision I would just call the setting thumbnails and the values store, link and proxy for example.

[Nutomic]

The new image proxying from this PR applies to all images, including avatars, markdown embedded images etc. However the old storing of preview images only applies to post urls. So I think the naming makes sense.

[dessalines]

Nice! BTW pictrs v0.5.0 is released now.

Did you want this to go in the upcoming release, or leave it for later? My main concern is I want our release notes to give full instructions on how to upgrade pictrs.

[Nutomic]

Should be fine to include it as it doesnt change the main behaviour unless you add the config option. For pictrs we can simply link to the readme.

[Nutomic]

Added cache_external_link_previews config option back in to avoid breaking changes.

[dessalines]

LGTM, but lets have @phiresky take a look before merging.

And when you can, please add some detailed instructions for LemmyNet/lemmy-ansible#213 , because I'm sure this will cause some issues unless people know the proper way to upgrade pictrs seamlessly.