mlemgroup
Inline Image Reuse Gallery
Introduction
People use inline images in their posts; maybe they're meme'ers, or they make guides, or something else I cannot think of right now. I would imagine the instances hosting the images have a boat-load of duplicate images because of this.
What I am asking for is that mlem keep track of the images that users have uploaded to pictrs to allow them to reuse existing uploaded images. This could be done by introducing a gallery view of previously uploaded items that would show thumbnails of the images.
Requirements
- A database for url storage.
- Optional iCloud storage for device sharing.
- Ability to remove one or more previously-uploaded images (for privacy concerns) from the database.
Discussion
From a cursory look at Lemmy, it does support showing thumbnails of images by providing a thumbnail=<size> parameter in the image url. So either not storing any image data or storing a cached thumbnail (for slow/low data situations) could be possible.
Possible future enhancements might include the ability to organize these images into groups to alleviate a growing database over the years.
Another possible enhancement that builds upon organization would be to tie into PhotoKit to allow storing inline images in a custom Photos album on the user's device. This would then allow the user to store, organize, and reuse their pictures (both already existing and future) using Apple's mechanisms.
If possible, keep track of the image file's checksum and detect if an image has already been previously uploaded and use the that picture instead. This wouldn't be foolproof, but could help in reducing some duplication and save on data for the user and instance.
What I Need
What would you like me to do? I'd be happy to buy the team a coffee/beer/scone of their choosing. Actually, I'd be happy to do that regardless.
Yeah, this is a cool idea! Post-0.19.5 there's an API endpoint to request all uploaded images from Lemmy directly, so that part should be easy. We could implement a basic "pin" system to keep favorite images at the top, which would require on-device storage.
Possibly child of #1253 (I'd personally like to implement #1253 in 2.0; it seems easy enough)
