rns.recipes

This release completes the foundations for page image caching, and adds an automatic image conversion handler to the page node. This means that it's now possible to use images in any format directly when hosting nodes, as everything will automatically be converted to the required webp format.

The automatic conversion requires that you have a suitable backend installed on your system, for example magick, convert or ffmpeg. If you do not, images will have to be pre-converted to webp before being included in pages.

The image conversion helper is imported from RNS itself, so you can use it directly in other page-serving programs as well, to easily add image support to your programs. See the nomadnet code for how to do this.

This completes quite a bit of the image serving and loading functionality, and the remaining functionality, such as bandwidth-aware profiles, automatic scaling and compression, and additional image tag functionality will be included in upcoming releases.

For now, enjoy!

Changes

• Optimized page rendering and scroll performance quite significantly, by Zenith
• Added auto-conversation of non-webp image formats to webp for nodes serving images
• Added full local caching system for page images
• Fixed images not being displayed in the built-in page editor

Also, there's likely going to be opportunity for extending the image tag functionality a bit, so if you have any sensible ideas or wishes in this regard, feel free to post them here.

This is all quite new and has a lot of moving parts, so if you find any bugs or weirdness, please also do share them here in this thread.

I posted in the topic of the previous release so not sure if you read that. Could we have a size tag, so LoRa only nodes cloud decide whether to request the image or not. Or perhaps there is another way the requesting node to check the file size before getting it?

This is pretty sweet, thanks.

I do have a suggestion that builds upon circfruit's one. Would you be interested in creating an optional feature that allows a node to serve variations of an image based on the interface bandwidth?

Basically if a user requests an image over a backbone/tcp/etc, it's reasonable to serve the original resolution. But if requesting that image over I2P, Lora (or even HF), the serving node could generate a smaller image to conserve bandwidth. "Smaller" here may mean lower resolution, reduced color palette, heavier compression, or some combination of multiple such factors. I imagine that the beta version would just start with resolution, of course.

The serving node would then cache that image, and serve it to other users who request it under the same bandwidth constraints. I imagine the 'image cache' would function a lot like a Propagation Node's message store, in that the operator would specify how much disk space they are willing to set aside for this cache.

The operator would also specify what kind of cpu usage / bandwidth tradeoff they're willing to work with. Some would burn 2x the cpu cycles to save 3% on bandwidth / disk, others would not. Either way, eventually the serving node would eventually 'settle' on which images persist in its cache, arriving at an optimal balance between image quality and bits spent.

Regarding interface bandwidth aware content service: I'm guessing this is going to be in some way reliant on upcoming QoS support in Reticulum; any other measure slapped on top with NomadNet would probably work against that design. Definitely curious to see this sort of implementation at some point in the future though.