💾 Archived View for rawtext.club › ~sloum › geminilist › 007497.gmi captured on 2024-02-05 at 10:39:43. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
The Gnuserland gnuserland at mailbox.org
Tue Nov 2 13:46:17 GMT 2021
- - - - - - - - - - - - - - - - - - -
Dear Geminauts,
I am pretty aware the specs are somehow frozen, but I entered in the Gemini space about six month hence I missed a lot of its evolution. Even though I have not been very prolific in terms of pages made on my capsule, basically for lack of time, I work and use it every day since the day I started.
I hope you will give even for the late comers the opportunity to express their opinions!
The daily use of Gemini, since being both author and reader, let me consider that it would be useful create an alternative flavor of the gemtext =
link.
I think that adding a secondary behavior will increase the ability for both author and reader to have more control on the way the content is delivered and accepted, also this idea looks toward the future where possibly more GUI client will be available.
Today the specs define:
=
to provide links for every protocols your client and the capsule server can handle, if for instance you client is able to handle some of the content delivered it will be likely to be display in a line.
I suggest to also to add a second flavor:
<=
This flavor forbids any suitable content to be displayed in line even if the client is capable and should not used to provide link to GMI files.
For TUI clients serving <= and => is most likely the same even though with software like DucklingProxy you may open an http page on your client, but with <= you could not.
For a GUI client it would allow the author (even though Gemini is more for the reader) to decide how delivering certain content, for instance an author may decide to deliver a big and weight image with <= and triggering the internal download feature separately from the rendering of the page. Reader may decide that every media content that is delivered through <= to be saved in a /tmp like folder or even disable (if the client allows it) to hide any <= line for security.
To close, the point is with two flavors and two different behaviors authors and users will have more control over the content and over the client, as well a more predictable way to understand how a link line will work. However simple clients and TUI clients can still ignore <= and serve everything as =>; basically I think adding a second flavor doesn't break Gemini protocol and doesn't add more complexity.
Thanks for reading,
TGL