💾 Archived View for gemi.dev › gemini-mailing-list › 000547.gmi captured on 2024-08-31 at 17:30:35. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Older protocols such as SMTP, POP3, IMAP, and NNTP have developed extension mechanism overtime: SMTP has EHLO. POP3 has CAPA. IMAP has CAPABILITY. NNTP has CAPABILITIES. The principle is always the same: the client invoke a well known server command to list the server capabilities. The client can then use these extensions in coordination with the server. The server capabilities are represented as a set of keywords, such as 8BITMIME, CHUNKING, PIPELINING, SIZE, etc, etc... For example, in SMTP: C: EHLO S: 250-8BITMIME This tell the client the server supports 8 bit data transmission, enabling the client to send such data, in addition to the 7bit defined by the standard. In Gemini, a consenting client-server pair would use a similar mechanism to discover and negotiate new capabilities; above and beyond the ones defined by the standard itself. Upon receiving a request at /.well-known/capability, a compatible server would respond with a text listing its capabilities, as keywords, one per line: C: gemini://mozz.us/.well-known/capability S: text IRI For example, the IRI keyword tells the client the server can understand and generate IRIs for both request and text/gemini links; in addition to the regular URIs defined by the specification itself. Another capability could be EHLO. EHLO tells the client it can extend the initial Gemini request with further keywords, after the URI: C: gemini://mozz.us/bunny.gmi IRI S: text/gemini => gemini://?.hole/?%20%26%20?.gmi ? & ?: Down The Rabbit Hole, a journey. Another server extension could be CHUNK, telling the client to expect chunked transfer encoding. Another server extension could be SIZE, telling the client to expect an additional size parameter, as part of the content type. Another server extension could be PERSIST, informing the client the connection can be maintained after a response, allowing the client to issue further requests over the same connection. Putting this together: C: gemini://mozz.us/.well-known/capability S: text EHLO IRI PERSISTENT SIZE <server drops connection> C: gemini://mozz.us/????.gmi IRI PERSIST SIZE S: text/gemini; size=90 => gemini://?.hole/?%20%26%20?.gmi ? & ?: Down The Rabbit Hole, a journey. <server maintains connection, awaiting a further request> In other words -after checking the server capabilities- the client request a persistent connection, with content size, and IRIs. That's all folks. Thoughts? Opinions? Likes? Dislikes? Something?
I will say this was the most annoying message to reply to as my preferred editor kept freaking out over the UTF-8 characters in this message. Yes, I am a aware that I might need to update some stuff around here, but please be aware that the Unicode standard changes yearly. I'm just saying ... Anyway, on with the show. It was thus said that the Great Petite Abeille once stated: > Older protocols such as SMTP, POP3, IMAP, and NNTP have developed extension mechanism overtime: [ snip ] > Putting this together: > > C: gemini://mozz.us/.well-known/capability > S: text > EHLO > IRI > PERSISTENT > SIZE > <server drops connection> > C: gemini://mozz.us/?.gmi IRI PERSIST SIZE > S: text/gemini; size=90 > => gemini://?.hole/?%20%26%20?.gmi ? & ?: Down The Rabbit Hole, a journey. > <server maintains connection, awaiting a further request> > > In other words -after checking the server capabilities- the client request > a persistent connection, with content size, and IRIs. HTTP is down the hall to the left. This is Gemini, it's different. I don't think this will fly with the community. > That's all folks. You forgot IFMODIFIEDSINCE, BYTERANGE, TITANSUPPORT, and STREAMING. This can get out of hand. Again, HTTP is down the hall to the left. > Thoughts? Opinions? Likes? Dislikes? Something? Not much. Strong opinion. Not at all. Yes. And nothing else to add. -spc
> On Dec 20, 2020, at 02:26, Sean Conner <sean at conman.org> wrote: > >> Thoughts? Opinions? Likes? Dislikes? Something? > > Not much. Strong opinion. Not at all. Yes. And nothing else to add. Brief, concise, and clear. Thank you. Cultural issues aside, such mechanism completely bypass the need for any protocol changes, while opening the door to infinite extensibility. Q.E.D.
> while opening the door to infinite extensibility. I mean no disrespect, but this is complete anti-feature to me. I agree with spc. makeworld
Petite Abeille <petite.abeille at gmail.com> wrote: > Cultural issues aside, such mechanism completely bypass the need for any > protocol changes, while opening the door to infinite extensibility. > Isn't infinite extensibility a thing we're trying to get away from? -- Katarina > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201220/f4b6 9df5/attachment.htm>
> On Dec 20, 2020, at 02:44, colecmac at protonmail.com wrote: > >> while opening the door to infinite extensibility. > > > I mean no disrespect, but this is complete anti-feature to me. I agree with spc. Fair enough. Time will tell how the protocol usage will evolve.
> On Dec 20, 2020, at 02:45, Katarina Eriksson <gmym at coopdot.com> wrote: > >> Cultural issues aside, such mechanism completely bypass the need for any protocol changes, while opening the door to infinite extensibility. >> > Isn't infinite extensibility a thing we're trying to get away from? > It is indeed, culturally speaking, at this point in time. But no amount of protocolar straitjacket can prevent evolution and change. Eventually. Even gopher evolved. A bit.
On Sat Dec 19, 2020 at 8:52 PM EST, Petite Abeille wrote: > It is indeed, culturally speaking, at this point in time. But no amount > of protocolar straitjacket can prevent evolution and change. Eventually. > Even gopher evolved. A bit. Sure, it did. But at this point in time, we don't need these changes. Let's stick to what we have, and just let Gemini be Gemini.
On Sat, Dec 19, 2020 at 7:39 PM Petite Abeille <petite.abeille at gmail.com> wrote: Older protocols such as SMTP, POP3, IMAP, and NNTP have developed extension > mechanism overtime: > However, some have not. Multiple versions of NTP exist, but backward compatibility is complete and there are no named extensions. FTP, which is actually older than TCP/IP, likewise has neither extensions nor versioning: new commands have been added and older ones have become unnecessary, but that's all. Gopher+ was backward compatible with Gopher, but was never widely adopted. The principle is always the same: the client invoke a well known server > command to list the server capabilities. The client can then use these > extensions in coordination with the server. > Note however that this is not normally bilateral. There is no way (like Telnet WILL/WONT/DO/DONT) for the server to find out what extensions the client supports. Consequently, servers either have to exploit no client extensions, or just use whatever client extensions they would like, and if clients don't support them, tough turkey for the user. The spirit of Gemini is that that clients and servers agree because they all voluntarily comply with the current standard. (Solderpunk keeps talking about a permanent freeze, but _haud credo_. What matters is that evolution of the protocol document stays controlled and that software authors have no incentive to ignore it.) (The .sig below was chosen at random.) John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. --Edsger Dijkstra -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201219/6880 48ff/attachment.htm>
> On Dec 20, 2020, at 02:26, Sean Conner <sean at conman.org> wrote: > > And nothing else to add. Another aspect of such mechanism, is allowing for safe experimentations, keeping esoteric interactions between consenting parties only.
> On Dec 20, 2020, at 02:56, John Cowan <cowan at ccil.org> wrote: > > Note however that this is not normally bilateral. There is no way (like Telnet WILL/WONT/DO/DONT) for the server to find out what extensions the client supports. Consequently, servers either have to exploit no client extensions, or just use whatever client extensions they would like, and if clients don't support them, tough turkey for the user. All is client driven, the server merely advertises its capabilities. Of course, the client could do the same: C: gemini://mozz.us/.well-known/capability?persist+size > The spirit of Gemini is that that clients and servers agree because they all voluntarily comply with the current standard. (Solderpunk keeps talking about a permanent freeze, but _haud credo_. What matters is that evolution of the protocol document stays controlled and that software authors have no incentive to ignore it.) The standard becoming the baseline. > (The .sig below was chosen at random.) Lucky draw.
> On Dec 20, 2020, at 02:55, Sebastian Alejandro <sebastian1231alejandro at gmail.com> wrote: > > On Sat Dec 19, 2020 at 8:52 PM EST, Petite Abeille wrote: >> It is indeed, culturally speaking, at this point in time. But no amount >> of protocolar straitjacket can prevent evolution and change. Eventually. >> Even gopher evolved. A bit. > > Sure, it did. But at this point in time, we don't need these changes. > Let's stick to what we have, and just let Gemini be Gemini. Sure thing. But no one can foresee what Gemini will be. Time will tell.
On Sat, 19 Dec 2020 20:26:23 -0500 Sean Conner <sean at conman.org> wrote: > > I will say this was the most annoying message to reply to as my preferred > editor kept freaking out over the UTF-8 characters in this message. Yes, I > am a aware that I might need to update some stuff around here, but please be > aware that the Unicode standard changes yearly. Your editor doesn't need to be aware of the latest changes to the Unicode code points to be able to edit UTF-8 without freaking out. In UTF-8, a code point can easily be identified without knowing what it means and the text rendering system can display a fallback character. > HTTP is down the hall to the left. This is Gemini, it's different. I > don't think this will fly with the community. Agreed. "Non-extensibility of the protocol was a major design principle for Gemini." (Gemini FAQ) -- Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201220/7924 b6e9/attachment.sig>
> But no one can foresee what Gemini will be. Agreed but we do know there's a strong and clear vision for what we want Gemini to be. ? Lokesh Krishna
> On Dec 20, 2020, at 11:40, Philip Linde <linde.philip at gmail.com> wrote: > > Agreed. "Non-extensibility of the protocol was a major design principle > for Gemini." (Gemini FAQ) True. And mostly achieved when viewed through a narrow enough lens. Tunnel vision is key. There are few moving parts to play. So, yes, from a strictly protocolar point of view, it's mostly done: a retrofuturistic goldilocks of sort. Nothing much to add or remove. Would make Saint-Exup?ry proud. Of course, this says nothing about actual use of the protocol. Which can be combined in all sort of weird and wonderful ways to fully subvert such grand "design principle" if needed. Perhaps the only cognitive dissonance is the idealistic narrative around the protocol: trivial to implement and use, non-extensible, one-trick pony. Your progressive grandma could whip it up in no time and run it out of her trusty gramophone to share haikus without much ado. These statements are misleading, naive, or outright wrong. The building blocks are chunky and complicate enough on their own to make it complex, both in terms of implementation and actual usage. Not to mention unattended consequences. The protocol can be trivially extended through conventions. And there is more to life than publishing samizdat poetry. A bit of realism would help. That's all. Nothing to lose sleep over. All is good in the grand scheme of things :) Happy holidays. Public Work | #EFF2020: A Holiday Campaign (Uncensored) https://www.youtube.com/watch?v=SWYnVepM8VM
On Mon, 21 Dec 2020 10:36:57 +0100 Petite Abeille <petite.abeille at gmail.com> wrote: > Of course, this says nothing about actual use of the protocol. Which can be combined in all sort of weird and wonderful ways to fully subvert such grand "design principle" if needed. Yes, and when that happens in practice in such a way that the specification no longer represents actual use, I guess it's reasonable that the difference between specification and implementations in the wild should be discussed here. > The building blocks are chunky and complicate enough on their own to make it complex, both in terms of implementation and actual usage. Not to mention unattended consequences. Agreed, but I don't see how inviting additional complexity through extensions will improve that situation. > The protocol can be trivially extended through conventions. The non-trivial part is convincing enough implementers to adopt such conventions that it becomes a problem for compliant implementations. That compliant extension is only possible through ugly, subversive hacks should add some resistance to the notion. Regarding the parts about retrofuturistic goldilocks, Saint-Exup?ry, my progressive grandma and her samizdat poetry etc.: as a response to my post it strikes me as inane and distracting. I'm not totally humorless, but it feels like a brain DoS when I have to sift through more than a handful of it to find some actual, fully expressed points that I can consider and respond to. -- Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201221/e246 1aed/attachment-0001.sig>
> On Dec 21, 2020, at 18:07, Philip Linde <linde.philip at gmail.com> wrote: > > strikes me as inane and distracting. Ok. Bone dry technical then. So be it. Thanks for taking the time to spell it out. We can surely accommodate.
> On Dec 21, 2020, at 18:07, Philip Linde <linde.philip at gmail.com> wrote: > > Regarding the parts about retrofuturistic goldilocks, Saint-Exup?ry, my progressive grandma and her samizdat poetry etc.: Perhaps this deserves further text explanations. > On Dec 21, 2020, at 10:36, Petite Abeille <petite.abeille at gmail.com> wrote: > > retrofuturistic goldilocks /retrofuturistic/ Retrofuturism (adjective retrofuturistic or retrofuture) is a movement in the creative arts showing the influence of depictions of the future produced in an earlier era. This refers to the very description of this mailing list: "A protocol that is slightly more complex than gopher, but significantly simpler than HTTP" Gopher being the "retro" part. HTTP the futuristic one; from the point of view of gopher (circa ~1991). This term has been used previously on the mailing list to describe the Gemini protocol, notably by Jason F. McBrayer on December 9th 2020 in "Some reading on IRIs and IDNs". /goldilocks/ The Goldilocks principle is named by analogy to the children's story "The Three Bears", in which a young girl named Goldilocks tastes three different bowls of porridge and finds that she prefers porridge that is neither too hot nor too cold, but has just the right temperature This also refers to the description of this mailing list. Too hot: HTTP Too cold :Gopher Just right: Gemini Therefore, the Gemini protocol is looking for that retrofuturistic, but elusive, goldilocks nirvana. /elusive/ difficult to find, catch, or achieve. /nirvana/ (in Buddhism) a transcendent state in which there is neither suffering, desire, nor sense of self, and the subject is released from the effects of karma and the cycle of death and rebirth. It represents the final goal of Buddhism. Hopefully this is now crystal clear. > On Dec 21, 2020, at 10:36, Petite Abeille <petite.abeille at gmail.com> wrote: > > Would make Saint-Exup?ry proud. /Saint-Exup?ry/ Antoine Marie Jean-Baptiste Roger, comte de Saint-Exup?ry, simply known as de Saint-Exup?ry, was a French writer, poet, aristocrat, journalist and pioneering aviator. This refers to Solderpunk quoting Saint-Exup?ry -without unnecessary attribution- in the context of "[Spec] Spec (un)freezes and the spec's future", circa December 20th : ?Perfection is achieved when there is nothing left to take away.?, (Transcriptions may vary) > On Dec 21, 2020, at 10:36, Petite Abeille <petite.abeille at gmail.com> wrote: > > Your progressive grandma could whip it up in no time and run it out of her trusty gramophone to share haikus without much ado. /your/ belonging to or associated with the person or people that the speaker is addressing So, not "your" as in Philip Linde own grandmother specifically, but "your" as everyone's. A generic grandmother. /progressive/ an advocate of social reform In this case, synonym for ""modern", "forward looking", "hip", "edgy". Like how the Gemini crowd like to think of itself. Previous art by Little John in the introduction to "The Saturday Morning Gemzine": ' ... a technology cannot be said to be "for hipsters' unless someone is using it to run an e-zine"... /grandma/ informal, one's grandmother. This denotes two concepts: old age (gopher), and tech savviness. Or lack therefore. This is meant to convey how easy Gemini is meant to be, as in "Even Your Grandma Can Use It". /gramophone/ old-fashioned term for record player. /record player/ an apparatus for reproducing sound from records, comprising a turntable that spins the record at a constant speed and a stylus that slides along in the groove and picks up the sound, together with an amplifier and a loudspeaker. old-old-fashioned like gother. Additionaly, there is quite a bit of retrotech going around in the Gemini milieu. Not judging, just saying. /haikus/ a Japanese poem of seventeen syllables, in three lines of five, seven, and five, traditionally evoking images of the natural world. Synonym for poem: short artistic text of sort. The Gemini commune seem to like poetry. Not judging, just saying. The rest of the sentence should be clear enough to comprehend. Do tell otherwise. > On Dec 21, 2020, at 10:36, Petite Abeille <petite.abeille at gmail.com> wrote: > > And there is more to life than publishing samizdat poetry. /samizdat/ the clandestine copying and distribution of literature banned by the state, especially formerly in the communist countries of eastern Europe. This refers to another aspect of the Gemini commune: a bit underground, a bit anti-establishment, a bit alternative. In conclusion, Gemini is meant to be a retrofuturistic goldilocks to let a hip grandma enjoy some underground poetry. All in all, my editor tells me this is a technically accurate, if obscure, description of the Gemini sphere. Your milage may vary. HTH.
Petite Abeille <petite.abeille at gmail.com> writes: >> On Dec 20, 2020, at 02:26, Sean Conner <sean at conman.org> wrote: >> >>> Thoughts? Opinions? Likes? Dislikes? Something? >> >> Not much. Strong opinion. Not at all. Yes. And nothing else to add. > > Brief, concise, and clear. Thank you. > > Cultural issues aside, such mechanism completely bypass the need for any > protocol changes, while opening the door to infinite extensibility. Lack of extensibility is an intentional feature. The only way we have to enforce that, other than social pressure around the spec, is to make sure that most attempts to extend the protocol will not be backwards-compatible. -- +-----------------------------------------------------------+ | Jason F. McBrayer jmcbray at carcosa.net | | A flower falls, even though we love it; and a weed grows, | | even though we do not love it. -- Dogen |
On Tue, Dec 22, 2020 at 01:14:40PM -0500, Jason McBrayer <jmcbray at carcosa.net> wrote a message of 23 lines which said: > Lack of extensibility is an intentional feature. The only way we have to > enforce that, other than social pressure around the spec, is to make > sure that most attempts to extend the protocol will not be > backwards-compatible. We have another tool for enforcement: simplicity of the system. That way, there will be many clients and servers and it will be more difficult to add a non-consensual feature. (Unlike the Web where Google can implement anything, the few others will have to follow. The lack of competition on the Web is one of the worst consequences of its complexity.)
---