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:
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
The original Gemtext version of this page can be accessed with a Gemini client: gemini://skyjake.fi/gemlog/2022-02_re-holes-and-diversity.gmi