💾 Archived View for bbs.geminispace.org › u › mozz › 4857 captured on 2024-05-26 at 17:38:21. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-05-10)
-=-=-=-=-=-=-
But actually, I think the description is a better place for this.
Why do you think so? Personally I like the URL placeholder better. It's more flexible because it also works on bare links without a text description. And there's more of a chance that the query param will be preserved if the URL is copied around between capsules, cached by search engines, translated to a different language, etc.
Perhaps some suitable fancy unicode character would be better than "INPUT:", or could be an alternative to it. Maybe someone could suggest a good character.
I think you have to go emoji, just given the prevailing popularity of adding emojis to the beginning of link descriptions. Using "INPUT": will stick out like a sore thumb. The best I can come up with is the speech balloon (💬). Or, allow both "INPUT:" and "💬", so capsule authors can choose the one that best fits the style of their capsule.
My main concern would be the precedent this would set. Could this poke an extensibility hole in gemini?
Given I'm sitting here writing this gemini comment in a full-size textbox and uploading via titan://, I feel like that ship has sailed. Actually, if we could convince everyone to just implement titan:// already, that would solve the problem because titan always prompts for input before sending the request.
2023-08-28 · 9 months ago
🚀 mbays [OP] · 2023-08-28 at 21:50:
@mozz: The placeholder approach has a few problems. The big one is that the placeholder can't be given as the input without some ugly escaping mechanism. That means it can't be anything natural like the empty string or "?", because they are not infrequently valid values for the input. I thought of using the null character, but that leads to issues with string handling in cgi programs. So then with all the natural choices ruled out, we'd have to pick something quite arbitrary. \x10 (aka %10 or ^P or DLE) is the best I could come up with -- ctrl-P suggests Prompt, and %10 recalls the 10 response code. But it's slightly ugly.
A second problem is where to put the prompt. The obvious answer is to have the link description be the prompt. But then when the URL gets separated from that description, as in the various situations you mentioned, there's no indication of what the prompt should be.
I suppose that could be solved by putting the prompt in the URL, like "gemini://example.com/foo.cgi?%10What%20is%20your%20favourite%20colour?", but I'm not sure I like it.
Meanwhile, using a special character/string in the description has one major advantage: it can work as a signal to the user even without any special client support. However, we again have the problem of avoid clashes. The speech bubble is maybe too generic.
☕️ mozz · 2023-08-29 at 15:54:
@mbays
Good points. I wasn’t thinking about the prompt text itself, but that’s probably just as important as indicating that the resource will return an INPUT status. And any way that I can think of to smuggle the prompt into the URL (for example via the URL fragment) would end up being too ugly and difficult to write out by hand (requiring escaped %20’s everywhere).
I guess that overloading the link description with the input prompt takes advantage of the fact that the they are often the same, or the wording between them is close enough that they can be used interchangably. This is not always true, but it’s probably true most of the time.
Coming at this from a different angle, what if there was a more general mechanism to provide a “hint” for what the response header will be for a gemini URL? Beyond input prompts, it would be useful for knowing what mime-type a resource will return ahead of time (i.e. Lagrange’s image handling).
=> /input-link HINT:10<What is your favorite color?> => /image-link HINT:20<image/png> A picture of a cat
I guess this is the kind of “dangerous extensionism” you were trying to avoid 😅.
☕️ mozz · 2023-08-29 at 15:59:
@skyjake Looks like there's a bug in bubble here, it's prepending a dash for link descriptions even if the links are inside of a preformatted block.
🛰️ faildev_mode · 2023-08-29 at 17:54:
Why don't just empty query? Like this:
=> /cgi-bin/foo.cgi? This is input => /cgi-bin/foo.cgi And this is not
By a convention these links are equal, but for the client this can be a hint that the input is expected. No potential for extending and it's backward-compatible. Servers should respond with 10 code if empty query or no query has been sent.
🚀 mbays [OP] · 2023-08-29 at 17:58:
@mozz I can't see anything like this HINT mechanism taking off, it's too ugly for human readers.
Of course "INPUT:" still has the same problem. Rather than a speech bubble or other fancy emoji character, how about just ">"? It has a long history as indicating a prompt for user input, and it has the advantage of being an ASCII character. It isn't unambiguous -- but I think that's too much to hope for really. What ever character we settled on, someone would innocently use it for some other purpose while being unaware o f our convention. So in the end, I don't think this should go beyond being an informal convention meant to indicate to the human user that input will probably be expected, rather than something to be understood directly by the client.
So in short, here's all this proposal comes to:
🚀 mbays [OP] · 2023-08-29 at 18:02:
@faildev_mode There are two problems with that -- the theoretical problem that these are two representations of the same URI, so behaviour shouldn't depend on which is used, and the more practical problem that the empty string is not infrequently a valid response to an input request, so then it can't be used as the value which will elicit a 10 response.
☕️ mozz · 2023-08-29 at 18:05:
@faildev_mode
Many popular URL parsing libraries will throw out a trailing "?" if there's no query string after it (whether or not that's "correct" is a different discussion, but implementation trumps specification). So it would be an annoying footgun for gemini software developers to work around. Otherwise I agree, using a bare "?" is the obvious solution.
— https://github.com/psf/requests/issues/2912#issuecomment-161822824
☕️ mozz · 2023-08-29 at 18:26:
the more practical problem that the empty string is not infrequently a valid response to an input request, so then it can't be used as the value which will elicit a 10 response.
I have never seen anyone do this before, any examples?
🚀 mbays [OP] · 2023-08-29 at 18:54:
@mozz The only example which comes to mind is my own "gemrepl", which wraps an arbitrary line-based program (e.g. ed) for which empty lines could well be meaningful.
🕹️ skyjake [mod...] · 2023-08-29 at 19:42:
@mozz
I have never seen anyone do this before, any examples?
Bubble uses an empty query string to reset/clear some values in the Settings, for example the certificate password.
🕹️ skyjake [mod...] · 2023-08-30 at 12:49:
The extra dashes added into the links in preformatted blocks above have now been fixed.
🧇 Acidus · 2023-09-15 at 20:13:
Honestly, this feels best handled by the client:
1. They can have a setting like what @skyjake is suggesting for Lagrange and spellbinding. Basically: "This URL needs input, so always proactively prompt me for it"
2. Support Spartan-style link lines. Kind of like how some capsuel games offer a "ANSI mode" or "plain text mode", they could offer a "Spartan link" mode
🐐 drh3xx · 2023-09-18 at 12:21:
Although adding to the gemini spec would break handling of new content in clients which had not been updated to support it... a 2nd link markup of ?> or =? to signifying a link expecting data from a prompt seems reasonable. Easy to add to content, no scope for Link markup creep or add further checks to URL handling. Adding support would be a minimal patch for existing clients - to support the links with existing behaviour would just be an additional case match with fallthrough to the exiating code in C. Proper support shouldn't be much more work unless I'm missing something. It would also allow advanced clients to add support for inline text entry + 'submit' button should they want to.
Input indicator — I'm thinking again about something which has come up a few times before, which is how to deal with the annoyance that requesting input on gemini involves two requests -- the first to get a 10 response with a prompt, and the second for the actual input. The first is often not really necessary, and could be eliminated if there were some way to signal to the client that a link will expect user input. That extra request is wasteful and can be genuinely annoying -- I was prompted...