requirements of an image upload feature

[cblgh]

while we keep the philosophy, rationale and reasoning contained in #94, i wanted to put down some thoughts that i've had in the meantime since being sniped by @decentral1se.

the following contains a rough list of possible requirements for a speculative (!) image uploading functionality. if implemented, some of these may not be needed. regardless, it is easy for me in the current moment to share the context i've got built up in the event that it does become relevant. here we go!

• resize file to predetermined max size
• clearly communicate limits and that images will be resized
• communicate and show to users the amount of file storage taken up by them
• trim exif data
  • keep image rotational/orientation data intact
• handle
  • (android) jpeg uploads
  • (android, possibly) webp uploads
  • (ios) HEIF uploads
  • png uploads
  • svg uploads
• monitor
  • current total capacity taken up by uploads, and display it
  • all recently uploaded photos as a moderation precaution, and easily display it
• limit
  • file uploads to xxxx <unit>bytes
  • amount of uploads per user to yyy files / bytes
  • total amount of database space for media to zzz bytes
• consider
  • possibility of abuse uploaded in an image and how to systemically discourage, act on, and remove it.
    • impact on general posting and ad-hoc admin censoring as a result of this new piecemeal capability
  • javascript-free flow for uploading images, getting a referenced back, then using it somewhere in the post contents
    • the impact of people using cerca as a free image host by uploading images and then not referencing them in a post
  • config toggle to enable / disable media uploads
  • ability to restrict uploads to public only posts to limit spread of abuse material
  • separating the image database from the core cerca database
  • referencing the image database from a separate machine than is hosting the core cerca database
  • using simple files in a folder as the image database

[rscmbbng]

• the ability for users to delete their images
• the ability for users to see all the images they have uploaded
• automatically deleting images that are uploaded but not used (for instance because of aborted process)
• the ability for users to edit (as in replace) an uploaded image

[ForestJohnson]

Image uploads really are a pandora's box.

Even just something seemingly simple like resizing an image opens up a lot of complexity (go stdlib will not accept partially corrupted images that every other program under the sun will open,

Like you mentioned, the image EXIF rotation attribute is a sticking point.

HEIC images decoder is patent-encumbered as far as I can tell, and relies on custom SIMD instructions assembly stuff to run fast. (or something. I never really did figure this out.) I did find an easy to compile cross-platform version working in go (via WASM) but its slower than the original.

For bandwidth constrained environments, you really want to resize the image BEFORE uploading it, and, and, and, ....

Personally I love this kind of stuff.. But I understand the rationale to not allow images.

I have some code that I wrote for an image gallery for my friends and family to upload pictures to a shared bucket while we were traveling, which could show the front-end JS trick to use the <canvas> to resize the image and encode it to a JPG before uploading it.. But unfortunately it looks like I still haven't uploaded it and its not on this machine. I will try to upload it when I get home.

But also, IMO theres something to be said for the new fangled fancy image formats which can fit a whole lot into few bytes. here's one I made which is ~160kb

[ForestJohnson]

https://git.sequentialread.com/forest/image-gallery