Hacker News Reader

No technical limitation is suitable. The appropriate number or size of images depends on the accompanying text. Setting it high enough to allow all legitimate uses makes it weak enough that you might as well have no limit. And even a low limit does nothing to prevent annoying use up to that limit.

The best possible limit is "must convince the reader to click it".

I guess that's a reasonable position to take. It reminds me of paper publications where you have all the figures on color plates bound in the middle/end, so I guess it isn't without precedent

On the other hand, it made me think of old Usenet posts and discussions. That was another medium where you were limited to plain-text only. Posts were often forced to resort to awful ASCII-art drawings of things they wanted to explain and that was just a horrible experience altogether (not to mention how fun those drawings are to decipher today where modern archives have mostly messed up the white space).

Binary attachments were somewhat fiddly in Usenet, AIUI? I don't think MIME/8-bit clean support was really consistently there at the time. In Gemini, you'd just serve it as a binary file.

There are a number of text-based diagram formats that could be supported, like PlantUml and such.

Surely a motivated ad designer could make a "good enough" ad in PlantUml?

Sure. They can also use ascii art or plain text.

also not really sure, how a protocol wants to be simpler than http (send bytes to port 80, get bytes, print bytes...) if it has baked in content limitations...

What about "inline images can't be linkable?" Caption text could still link to an enlarged/detailed version. But if images can never be clicked/linked, it would be hard to abuse them for ads the way we see today.

That is adorably naive. This is why we have interstitials. (see https://en.wikipedia.org/wiki/Interstitial_webpage )

The lack of inline links is less about aesthetics and more about predictability. When you request a gemini resource you know that there will be two things happening: a TLS handshake followed by, hopefully, the server response (hopefully with your requested document).

Adding images requires more requests and breaks the concept of "one url/document == one request". I love that I know that my client will do nothing I do not tell it to do.

If you want to use gemini and you want inline images I believe https://proxy.vulpes.one does inline images of some form or other.

That said, images have other issues beyond causing page loads/requests to be unpredictable: they are an accessibility nightmare (as we have seen on the web).

If images are inlined in the document, then you can maintain that one request correspondence.

i don't know if you understand what you're saying?? are you suggesting the binary content of a png file be inserted into the text-readable markup for a document? this doesn't make any sense. in-line images are linking to other resources. nobody just copy-pastes the hex content of an image into their website's html, because it will end up being 95% of the file size and a nightmare to look at in your editor.

> they are an accessibility nightmare (as we have seen on the web).

Audio is an accessibility nightmare for people who can't see, text is an accessibility nightmare for people who can't see or people who can't read, German is an accessibility nightmare for people who can't speak German.

At some point we have to accept that not every way something is presented is going to be equally accessible by every person, but the solution isn't to just decide we should jettison a rich form of communication because there is a small subset that can't fully benefit from it. Even books that are expected to be used by people who can see all the images usually describe the purpose of the image, what it is illustrating, and why it was included.

How’s about serving gzipped bundles of files? Just request that and get all your text and enriched content in one go

> I love that I know that my client will do nothing I do not tell it to do.

By this line of reasoning, you would have to manually approve every init process that your computer would want to start every time you boot it up.

"images" == "client doing things I don't tell it to do" is completely false. Clients have been built that have configurable policies for loading images and scripts, and they're conceptually very simple and easy to use - e.g. "don't load images by default, click to load temporarily, control-click to load and permanently whitelist" is an example of a user-agent policy that not only supports images, but conforms to your extremely convoluted definition of a user-agent "do[ing] nothing I do not tell it to do."

> requires more requests

Is the purpose of a document browser to minimize requests, or to actually serve useful information? Images can encode data that cannot be encoded in text, and a vast quantity of information is much more easily read and understood in graphical form. If you want to minimize requests, then just don't use the web at all.

Also, this isn't even necessarily the case. You could encode images as part of the page, as base64 or something.

> they are an accessibility nightmare (as we have seen on the web)

The web supports alt-text for images. When people don't provide alt-text, that's not a technical problem, that's a social one.

> requires more requests

This is solved by HTTP/2 multiplexing https://en.wikipedia.org/wiki/HTTP/2

> breaks the concept of "one url/document == one request"

I don't think anyone cares about this "concept"

This problem is easily solved by just not loading images by default but on-demand.

What prevents the Gemini client from adding a "click to display inline" button next to the image link?

I suspect, were gemini format to catch on, user agents would likely get an option to render images from links inline (either instead of links or as thumbnail previews attached to the links.)

Just as would happen with everything else about the modern web that the author objects to. That’s how we got into this mess in the first place.

Related: why can’t we just point the blind at a protocol optimized for just sharing text documents?

https://news.ycombinator.com/item?id=20225291

The ability for clients to render the markup as they please is actually one of the most important features, and a stark distinction from HTML, which only has one correct way to render.

I exploit this in my Unnamed Gopher Client[0], a client for the predecessor of the Gemini protocol, where I render links in a familiar files/folder format:

https://i.imgur.com/dw3e4Ou.png

And there are many more creative things that can be done with this.

[0]: https://github.com/zenoamaro/unnamed-gopher-client

> which only has one correct way to render

A website can be rendered at different resolutions, with or without stylesheets, in dark mode, in printer-friendly formats, in a text-like format, with user stylesheets, with some elements hidden, as plain text, etc.

True, but at a given resolution, with CSS turned on, and in dark mode all users will basically see the same HTML view. The user can't have a dark mode HTML page unless the web site offers one or the user has an extension that makes a best effort to create one. HTML with complex Javascript rendering makes it hard to give the user control.

The concept of a user agent that gives the user much greater ability to choose how they want to view content could mean each user will:

* Pick their own font, font size, line spacing, margins

* Pick their own text color and background color. Like dark mode, high contrast, etc.

* Choose how linked images are shown: inline, click to load, load in new window, expandable thumbnails, etc

* How sections, section headers are displayed. Add a table of contents? Add a button to jump to the next section? The user can choose.

I like reader view, which gives me the ability to choose how I view HTML, but only when reader view can figure out how to extract the content (sometimes disastrously missing paragraphs of text...)

Opera 12 can do all that. I'm sad that you ever only experienced shitty browsers which take away this sort of control from the user.

Most of my list is available as extensions on other browsers [1] (which I'd generally prefer to reduce bloat).

However, in my experience, the DOM for some sites is such a mess that trying to apply user preferences is a hack. I.E. reader view accidentally loses text. Does the implementation Opera has always work? That would be cool, although I'd still avoid Opera for privacy reasons.

Gemini seems to be to throw away all that complexity, which makes user customization easier. I.E. the problem is HTML/JS/DOM complexity, not a browser or its extensions.

1. https://www.ilovefreesoftware.com/29/featured/free-website-f...

This right here should be the headline selling point on Gemini existing as its own separate protocol segregated from standard HTTP.

This thread is the first I've heard, and up until this comment I was thinking in my head, "sheesh, what kind of value proposition would justify that amount of work. I'm just not seeing it."

It's kind of like what REST was meant to be. More about entities than verbs. Cool. I get it now.

I was writing a client for Gemini and added a toggle to display images inline.

Images are generally not the point. Formulas, diagrams and illustrations are.

Managing image assets is tedious. The web design community still by and large hasn’t figured out a great standard way to do for images (versions with reversible/cherry-pickable diffs) what git does for code.

Instead, diagrams and formulas could follow the lovely ideas of mermaid, graphviz, dot, and mathjax inlined into the markdown as text. Tooling for VSCode handles inline diagrams beautifully for Markdown already.[1]

And then, inline SVG would let you illustrate nearly anything.

WSJ got by fine without photos, as did most journals for most of my lifetime, and Kindle books mostly don’t have them today. I wouldn’t be too quick to say a medium has to be filled with photos.

1. https://github.com/shd101wyy/vscode-markdown-preview-enhance...

Just use ASCII art instead! It’s cooler anyway.

The reason to avoid linked images that are displayed inline in the page is because they would permit tracking.

If you mean something like Base64 encoded inline images, then those might be viable.

Or only allow content from the first party server?

I think a better way to deal with advertisement images is with AI and/or collaborative filtering.

If we can have spam filters for email, we can have ad filters for images.

> Even the most basic printed publications can include illustrations.

Streaming video is probably here to stay. /s