💾 Archived View for skyjake.fi › gemlog › 2022-02_re-holes-and-diversity.gmi captured on 2023-01-29 at 03:58:00. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Re: Extensibility holes and client diversity

mbays over at gemini.thegonz.net has concerns about inline images:

Solderpunk tried hard to keep Gemini inextensible, such that the complexity of a "minimal fully-featured client" would not grow over time as it has with the web.

To actually have an inextensible specification, one would have to specify a fixed subset of URI schemes that are allowed. Otherwise any existing scheme, or one invented in the future, will potentially tilt the playing field in unexpected ways.

Diversity will help here, but any ecosystem that evolves naturally will not be so equally distributed in power that no one player has a substantially higher influence than others.

If so, how long before we see gemini pages which are 1KB text and 1MB advertising images?

Hopefully never!

It's pretty clear that the intention behind Gemini is against enabling large binary attachments. However, as a client author I am bound by the specification as written.

The specification hasn't (yet?) been updated with requirements related to this. I don't like imposing additional arbitrary restrictions unilaterally, but I will add a few mitigations that seem reasonable:

There will be a user-controlled setting for the maximum URI length. Link lines with URIs longer than this will be regarded as regular text. (Of course, Gemini URLs are always 1024 bytes.) That should prevent the worst abuses of data URLs, or any other URI scheme. The default will be 8 KB, which enables some of the potential benefits of data URLs while preventing massive images. My hope is that the Gemini specification will set a limit for link line URI length for non-Gemini schemes as it has for the Gemini scheme. Defining an arbitrary universal limit may prevent the proper use some schemes, but in the context of Gemtext this seems reasonable.
The ability to automatically show images inline from data URLs will also be an option, and disabled by default. I mentioned this is a "minor" change, and here's why: Lagrange has supported decoding data URLs since the very first release (v0.1), thanks to the gemini.conman.org client torture test. Since all "image/*" responses can now potentially become inlined when opened, the new feature is that data URLs, whose data is already in memory, can be inlined whenever the user wants them to be.

These restrictions, and the difficulty of encoding the data, should already be enough of a deterrent to prevent widespread use of image data URLs, while keeping the door open to interesting UI experimentation, as suggested by the "rich" image pages section in my previous post.

📅 2022-02-14

CC-BY-SA 4.0