rns.recipes

Is it something we want?

The screenshot is not a mockup, it's running live in nomadnet, but it is just a prototype for testing out whether it was actually viable.

Currently, it's only the client-side parts that are implemented, which, while not the simplest thing to get working, is really only a pretty small part of it.

The more important part is getting the whole serving side right, so that low-bandwidth connections aren't choked. That means it needs automatic scaling and compression for low-bandwidth peers, selective image retrievals, and having everything configurable and user-selectable, so pages with images can still be fetched in light-weight text-only mode.

Forgot to say, currently, I've only tested it in Kitty and Konsole. It should work in any terminal that supports the Kitty Terminal Graphics Protocol. I'd be really hesitant to add other terminal graphics protocols to the rendering backend, since most of those would require really heavy dependencies to handle image slicing, scaling, et cetera, et cetera. As it's implemented now, there's zero new dependencies; everything is handled in pure Python, performs really well, and is light on resources and memory. The terminal itself does the heavy lifting.

It also supports image buffer re-use, so the raw image data is only written to the terminal once, and can be re-used for as many image instances as required in a very light-weight way.

It supports basic sizing and alignment, such as setting width/height in cols/rows or percentages, and setting left/right/center alignment.

I'd love to hear what people think about this.

Hello Mark!

I think it's great, especially in the case of 'zero new dependencies'.

Question: How to determine if a terminal supports the Kitty Terminal Graphics Protocol? Do most Debian-based Linux distro's support this protocol?

Well I am not sure just having images is going to work it certainly doesn't meat your own requirements, however; Those requirements are something the wider net limited itself to and it grew as the infrastructure grew. In that time we came up with solutions that made content scale with capability. You could enforce progressive encoding for images and at the bottom render a skeleton in its place. There are so many tricks to this these days not worth going over them all here but some scaling maybe based on connect bandwidth would be in order. I believe you can drive progressive scaling algorithms in css these days even.

All (practically speaking) operating systems will have terminal emulators available that support graphics rendering. There's various protocols available for this, and different terminal emulators supports different sets of them. Some of the older, but relatively widespread protocols are Sixel and iTerm2. Both of those have some serious shortcomings; inability to efficiently place and erase graphics in interactive applications, only 256 colors, missing alpha support, various quirks and weirdnesses. The most efficient and complete terminal graphics protocol is currently Kitty. It was initially implemented in the Kitty terminal emulator, but now quite a few terminals support it, across all major platforms (not sure about Android though).

So, whether or not it is supported is not an OS thing as such, it's a question of whether your terminal emulator supports it. There's definitely a terminal application on your desktop OS of choice that does support it, but it may not be your current favorite terminal emulator.

It's a bit hard to find a conclusive overview, since terminals have features added all the time. I can say for certain that it works perfectly well in Kitty, Konsole (default on KDE-based distros) and Wezterm, just tested those. Ghostty seems to have support as well.

I even found a GH issue discussing the implementation of KTGP in the default Windows terminal, so it's apparently becoming pretty widespread ;)

In my current implementation, if the terminal cannot render the image, it just falls back to a text placeholder with the alt-text instead.

I saw a nomadnet node last week where the operator added truecolor images to their blog, with clickable buttons to show the images, it was quite nice. I didn't save the address, but if I find it again, I'll send it for reference.

That said, maybe there should be clickable buttons for displaying images?
Also, truecolor and ASCII fallbacks could be useful, if that doesn't complicate it too much

I really like the idea, but my vote is a no. Not as how you are suggesting it.

VTE barely supports anything as-is (a GNOME certified classic) and that's what more than half of Linux distros ship with.

If there were to be an image tag, I would suggest it to be opt-in, and function more as an inline preview than a static page asset. Nothing should download without the user directly requesting it.

My suggestion would be an "inline image preview" instead of inline images.

A preview would look like a link, but show the filename and filetype. Clicking on it would send a request to the node to fetch the image, and it could then be rendered inline. When inline images are enabled, a placeholder for the image boundaries could also be shown.

The progress of the Resource transfer could even be displayed too with some type of nice progress bar.

The preview could be collapsed like the new accordions, or expanded into some type of fullscreen dialog to see a better view, which could then be closed.

I don't know the specifics off the top of my head but it would also be good to check to make sure that kitty graphics has both WebP and AVIF support.

Mark wrote:

All (practically speaking) operating systems will have terminal emulators available that support graphics rendering. There's various protocols available for this, and different terminal emulators supports different sets of them. Some of the older, but relatively widespread protocols are Sixel and iTerm2. Both of those have some serious shortcomings; inability to efficiently place and erase graphics in interactive applications, only 256 colors, missing alpha support, various quirks and weirdnesses. The most efficient and complete terminal graphics protocol is currently Kitty. It was initially implemented in the Kitty terminal emulator, but now quite a few terminals support it, across all major platforms (not sure about Android though).

So, whether or not it is supported is not an OS thing as such, it's a question of whether your terminal emulator supports it. There's definitely a terminal application on your desktop OS of choice that does support it, but it may not be your current favorite terminal emulator.

It's a bit hard to find a conclusive overview, since terminals have features added all the time. I can say for certain that it works perfectly well in Kitty, Konsole (default on KDE-based distros) and Wezterm, just tested those. Ghostty seems to have support as well.

I even found a GH issue discussing the implementation of KTGP in the default Windows terminal, so it's apparently becoming pretty widespread ;)

In my current implementation, if the terminal cannot render the image, it just falls back to a text placeholder with the alt-text instead.

Thank you very much for your extensive and very clear explanation, Mark!

Zenith wrote:

I don't know the specifics off the top of my head but it would also be good to check to make sure that kitty graphics has both WebP and AVIF support.

Ah wait nvm I forgot that's just APC sequences so really you can display anything as long as you can encode and decode it yourself

I very much like this idea and Zenith's addition to it. Being able to show things graphically would nice to have on nomadnet. For example, I wanted to show text art on my site, so I created an ANSII/ASCI text to Micron converter for myself. I was just thinking of a way to convert an image -> ANSII -> Micron, with some ways to compress the image or show the byte count in the UI with a rough estimate of transfer time at LoRa speeds.

Maybe you could show the Micron image of it to keep it text based and then opt to download the real thing like Zenith was suggesting :P

Mostly kidding but excited to see what ends up being decided. I especially like what Zenith said, nothing should download without the user directly requesting it

May I instead propose to make it configurable in Nomadnet to pass media directly to some util for one-time only viewing instead of this or downloading and storing media on-disk and only then opening it manually? E.g. pipe it into your favourite media player, or write it directly into X server's fb if you really want to. Hell, it doesn't even have to depend on a graphical environment at all, it could be sent to kernel's DRM, or be represented as terminal graphics (again, assuming one's term supports it) through img2sixel and whatnot, or perhaps even something completely different entirely.

I use elinks in combination with mpv and yt-dlp (the latter is not even needed for direct links) to surf WWW.
There are two types of sites: those that rely on browser's media player and those that reinvent the wheel (most notably YouTube, Twitter, Facebook, Fandom, Reddit, other social media BS, etc...) and use their own often laggy and buggy JS players, everyone doing their own separate thing. Instead there could've been a standardised way to pass media to user's preferred player and we likely could've had all the nice things like smaller and simpler browsers, less clutter on-page and HW decoding but handled by an external media player (remember when Firefox's HW accel used to break every other update on Linux?).

In my humble and lowly opinion a simple direct link and ability to pipe it would more than enough, and far more flexible. Though I suppose one doesn't have to exclude the other.

@Mark I am strongly in favor of your idea. I would love to see image rendering being added to nomadnet. After looking at the above suggestions, here is how I think it could be done: - Add a global setting to the nomadnet config file to enable/disable automatic image rendering. - Add a per node setting to enable/disable automatic image rendering that overrides the global setting. This setting could be placed in the "Node Info" tab below the "Trusted" setting. - Add a placeholder for every image to the page if automatic image rendering is disabled. The placeholder could consist of two links. One to download the image and the other to show the image inline. Example: ʼnnimgs.png (872.9 KB)ʼ ʼShowʼ. - Add a download link below every rendered image. Example: ʼnnimgs.png (872.9 KB)ʼ - "zero new dependencies", as you suggested, is the way to go.

I'm worrying that pictures might start a trend to make Nomadnet sites more flashy and at some point browsing nomadnet will become too slow for Stuff like LoRa.

But what Zenith and r8io suggested sounds great.

One addition: some mechanism to choose from different file sizes (if present) would be nice.

Ups, after editing a typo in my post above all line breaks are gone :) Here is a repost, for better readability:

@Mark I am strongly in favor of your idea. I would love to see image rendering being added to nomadnet.

After looking at the above suggestions, here is how I think it could be done:

• Add a global setting to the nomadnet config file to enable/disable automatic image rendering.
• Add a per node setting to enable/disable automatic image rendering that overrides the global setting. This setting could be placed in the "Node Info" tab below the "Trusted" setting.
• Add a placeholder for every image to the page if automatic image rendering is disabled. The placeholder could consist of two links. One to download the image and the other to show the image inline. Example: nnimgs.png (872.9 KB) Show.
• Add a download link below every rendered image. Example: nnimgs.png (872.9 KB)
• "zero new dependencies", as you suggested, is the way to go.

r8io wrote:

Ups, after editing a typo in my post above all line breaks are gone :) Here is a repost, for better readability:

@Mark I am strongly in favor of your idea. I would love to see image rendering being added to nomadnet.

After looking at the above suggestions, here is how I think it could be done:

Same oppinion here! Hey, you got an HF rig?!

@aetherlab, no I don't have an HF rig. Unfortunately I know next to nothing about radio stuff, but I have that on the list for my next life. Maybe I will take a class in Walhalla ;)

Personally, I'm in favor, as long as it's used sparingly by NomadNet sites and not transmitted over slow links like LoRa, HF etc. unless a download is explicitly requested by the client, and caching and compression are smartly used.

Could be useful for Retipedia and forums (like this one), along with probably some other uses I can't think of

r8io wrote:

@aetherlab, no I don't have an HF rig. Unfortunately I know next to nothing about radio stuff, but I have that on the list for my next life. Maybe I will take a class in Walhalla ;)

Oh sorry, I meant Mark's picture in Nomad! 73 de LZ1SWE