Comment by 🌲 lojikil
Re: "I've been thinking a lot about how we can make Gemini more…"
Oh definitely; I figured eventually I'd have to issue a PR for Lagrange at the very least haha
And there's definitely a RESTful/HATEOAS style to be done for sure, but it would feel neater to just allow a user to fill in a form that is nicely encoded and validated to some degree locally for catching simple errors (obvs requiring validation on the server side as well). It also doesn't seem _too_ radical a departure from the current spec, and wouldn't rely on adding much to clients save for new Ask Response Codes and some form processing.
What I keep coming back to is: how do we make Gemini a little easier for folks to make cool stuff, server side?
2025-07-30 · 9 months ago
15 Later Comments ↓
👻 darkghost · 2025-07-31 at 02:13:
I think it could fragment an already small community. Last time I looked at servers a good 80% of them haven't been touched in years and yet they are still feature complete. I suppose the answer is both backward and forward compatibility at least for the intermediate term. Given the small size and niche of the community, it will be hard to get people to change. This is in opposition to the heavy handed approach of the past (you need to update to the latest version/use browser X to see this page.) Progress would be glacial and there's a risk it never sticks. Like how programmers coded to the least common denominator in the old 8 bit computers. (No commodore 128 software since it runs in 64 mode.)
👾 jecxjo · 2025-07-31 at 02:14:
After looking at nex and nps, this is exactly what other protocols are for. If you want a multi valued input having a structured input protocol can be designed for that problem. On its founding site, nps is used to "submit a form" and all that is required is you type in the leading line to state which form and subsequent lines represent specific fields.
For example if you had a contact form that takes name an email you could easily do
And on the server it knows that the 1st input of CONTACT INFO is name and the second is email.
🌲 lojikil [OP] · 2025-07-31 at 07:54:
@darkghost: I agree, that's also part of why I was thinking about Gopher+-style (well, that and I think about Gopher+ often enough I guess) interactive queries, so that we're not moving too far afield, but also at least as far as I understand, it should degrade gracefully: clients that don't support higher Query type codes should just default to a simple line input, and the server would have to validate it anyway, so could handle nicer user experience still...
but it's a very valid point that I'd rather not split the community for sure.
🌲 lojikil [OP] · 2025-07-31 at 07:58:
@jecxjo: I'm not opposed to a Gemini+ per se, esp if it can degrade gracefully like Gopher+ was meant to. And whilst I understand that it's rather simple to structure your input, I just think if we can provide some guidance to the client, it would make Gemini just ever-so-slightly more user friendly and accessible.
🪐 Fer-24 · 2025-07-31 at 08:42:
Fair enough, but how do you convince people to embrace this change??
🌲 lojikil [OP] · 2025-07-31 at 09:26:
@Fer: I think in two ways:
- make it backwards compatible, so no one is excluded, but those folks who can use it are supported
- make great software that uses it
It would be nice as well to socialize a change, but I also understand that the Gemini spec wasn't meant to be extended much (at least, not in a formal way).
🌆 skyjake [...] · 2025-07-31 at 11:55:
The idea of introducing some kind of syntax and semantics for the query prompt string has been discussed somewhere before, IIRC. That would allow specifying a list of predefined options that a client could present as a menu, keypad, etc. while another client that does not support this would simply show the prompt as-is with the standard text input field. The assumption is that the prompt is always human-readable.
This solution could be a "companion spec" similar to gemfeed indices and completely optional for clients to implement. No changes to server software would be needed. I have considered implementing this in Lagrange, however the actual spec would have to be created first.
@lojikil:
just ever-so-slightly more user friendly and accessible
...
make it backwards compatible
While you are presenting a perfectly valid case from an engineering perspective, it is incongruent with the Gemini ethos. There are always small additions and improvements that could be done, but each would add to the costs of understanding the spec and implementing the software. For "ever-so-slight" improvements, is that really worthwhile? Furthermore, making something "backwards compatible" implies that these additions represent some sort of "forwards" progress, which in turn implies a trajectory towards ever-increasing complexity such as we see in most areas of technology. This as a concept is something that should be consciously rejected, IMO.
In any case, the Gemini specification is meant to be non-extensible and immutable on purpose, so bolting on extensions goes against that design intent. (Titan gets a pass here because it is formulated as a protocol of its own, with its own set of semantics.)
🚀 stack · 2025-07-31 at 12:08:
Typically, a newcomer will want a few "improvements"... Guilty of it myself. But now I am happy to let it be as is.
Gemini provides just enough to be useful, and stability is maybe its best feature. Consider that you can still run a Common Lisp program from 1985, but Python code from three years ago will likely fail to execute without extreme measures.
👻 darkghost · 2025-07-31 at 12:34:
Stability is underrated. There are Gemini clients that haven't been updated in years. While there may be some hassle compiling them, they're still as compliant with the spec now as they were then.
🌲 lojikil [OP] · 2025-07-31 at 13:00:
@stack: this is very much a "long time listener first time caller" post here haha; part of what I value so much about Gemini *is* the permaculture feel, which is why I am aiming to be tactful here in a pulse check.
🌲 lojikil [OP] · 2025-07-31 at 13:03:
@skyjake: this is part of why I wrote here, I respect the input a ton, and I think that a companion specification is the right direction, esp because the Gemini spec as written leaves open this sort of work. Do you have any notes from your previous thoughts? I'll try writing up some longer form companion this weekend and maybe we can compare?
🌲 lojikil [OP] · 2025-07-31 at 13:03:
@darkghost: absolutely, and I believe things would degrade for Gemini proper gracefully. Part of what I would expect with a companion spec would be a test suite that we can make sure we're not actively breaking anything for exactly this reason.
👽 spc476 · 2025-08-01 at 06:40:
There are only about 300 gopher servers still in existance, none of which
support Gopher+ in my experience. I've read the Gopher+ spec, and I found
it a bit baroque in nature, which is probably why it hasn't been
implemented.
My only comment on this---go ahead and Just Do It! Write a server (or fork
one), and a client (or fork one) to support the feature you want, and make
them available for people to play with (or to see). That's what I did with
Gemini (Hi! I wrote the very first Gemini server, beating Solderpunk to the
punch and got this ball rolling). Over the years, I found that most people
would rather talk about an implementation rather than do an actual
implementation. I found that got old rather fast. There was plenty of
ideas that was being talked about (ad naseum) but got nowhere until someone
(usually me) just went ahead did the bloody thing. Most of the time the
reaction was "Oh ... um ... meh" and the idea was dropped. But until that
time, it was just talk talk talk talk talk talk talk talk talk talk talk.
Just Do It.
🌲 lojikil [OP] · 2025-08-01 at 14:23:
@spc476: definitely there! I paused some work I was doing on my Gopher server to try this out.
🚀 stack · 2025-08-01 at 16:59:
But..but...but talking is so much easier than doing!
Original Post
I've been thinking a lot about how we can make Gemini more accessible & useable. I think making queries easier would be huge, but I don't want HTML-style forms. I was thinking that Gopher+-style Interactive Queries could be huge here; for example, we already have Ask (Gemini Response 10), and AskP (11), but having a Select (and providing a list of options), as well as maybe a simple Form schema would be a huge boon for interactive applications, but still keep a Gemini-esque simplicity. [https...