💾 Archived View for gemi.dev › gemini-mailing-list › 000553.gmi captured on 2023-11-04 at 12:55:44. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Meanwhile, on IRC: [2020-12-21T11:12:29.422Z] <login> The one thing gemini should not do is allow the client to be 'smart', i.e., javascript Not allowed! But technically possible today. Any text/gemini document can embed any number of attachments, curtesy of the data URI scheme: https://en.wikipedia.org/wiki/Data_URI_scheme It would take a trivial amount of work for a client to start acting on, say, text/javascript (or, more likely, something akin to text/css to start with). Or some cute image/gif. The horror. Of course, Solderpunk could ban such heresies by pontifical decree. Alongside the evil authority's userinfo. And segments. And... whatever else doesn't toe the political line. Such edicts will most likely have the same net effect as the Pope's unwelcome intrusion into other people's bedroom. Have faith. N.B. Previously on Gemini: The Problems of Transclusion (was Re: More silly text/gemini spec proposals) https://lists.orbitalfox.eu/archives/gemini/2020/001195.html
> Of course, Solderpunk could ban such heresies by pontifical decree. Alongside the evil authority's userinfo. And segments. And... whatever else doesn't toe the political line. > > Such edicts will most likely have the same net effect as the Pope's unwelcome intrusion into other people's bedroom. This is becoming ridiculous. The front and foremost reason that gemini is unlikely to be extended over time is that *almost all features proposed are actually already in HTTP*, and that protocol has been around for a very long time and does these things way more efficiently than can be adapted to gemini. You can wish all you want that gemini should be extended, and believe all you want that it will be over time, but the fact is that gemini itself is basically one step up from gopher (which hasn't been extended for decades, and only extended very slightly after its inception). Yes, gemini *will* change. Things like TLS will evolve, and internationalization may require changes over time too. But most feature requests fall on the same technical arguments.
> On Dec 21, 2020, at 14:36, Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote: > > You can wish all you want that gemini should be extended Apologies. Perhaps it was not clear: Gemini can be extended in its current shape. That bridge was crossed long ago by introducing full-fledged URIs into the protocol. If people are going to actually use such esoteric capabilities has to be seen. Or not. But it could be done, technically speaking. It's crystal clear the commune is not interested leveraging such capabilities at this conjuncture. Fair enough. But this doesn't make them go away.
> Apologies. Perhaps it was not clear: Gemini can be extended in its current shape. That bridge was crossed long ago by introducing full-fledged URIs into the protocol. I?m not well enough versed in the capabilities of URIs to know what this means. Can you give an example? Cheers, ew0k Sent from my Lego Mindstorms set
> On Dec 21, 2020, at 14:36, Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote: > > * Gemini will not inline things or transclude things, because gemini > transactions are expensive in that regard. We don't reuse connections, > and that's a *big* thing about the philosophy and simplicity of > implementations. As this is meant to be a [tech] topic, I have to point out that data: URIs are fully embedded in the text/gemini document itself. Not further network connection is required (assuming self-contained resources). To illustrate the point, a popular Gemini custom requires an additional network connection to retrieve a favicon.txt document containing one UTF8 character for decorative purpose*. Fantastic. An alternative approach would embed such decorative emoji in a data: URI link: => data:text/plain;charset=utf-8;base64,8J+QsA== favicon.txt => data:text/plain;charset=utf-8,%F0%9F%90%B0 favicon.txt Monstrous, I know. Oh well. [1] https://gemini.rootkey.co.uk/x/mozz.us/files/rfc_gemini_favicon.gmi
> As this is meant to be a [tech] topic, I have to point out that data: URIs are fully embedded in the text/gemini document itself. Not further network connection is required (assuming self-contained resources). > > To illustrate the point, a popular Gemini custom requires an additional network connection to retrieve a favicon.txt document containing one UTF8 character for decorative purpose*. Fantastic. Ugh. Yeah, I?ve seen that. As far as I know only one client supports this (not by default, but by toggling a setting in config). I hope it doesn?t gain traction. Even if it looks nice it seems pretty preposterous to do a full TLS handshake to send a single character at most. Experiments like this will pop up, but I still think the general gemini community is pretty resilient to it because ? as I mentioned earlier ? another protocol just does this better. > An alternative approach would embed such decorative emoji in a data: URI link: > > => data:text/plain;charset=utf-8;base64,8J+QsA== favicon.txt > => data:text/plain;charset=utf-8,%F0%9F%90%B0 favicon.txt A better approach, but I think you?d have a hard time getting browser implementers to adopt it. But yeah, experimentation will happen and that?s a good thing. I just believe that almost none of those experiments will lead to de facto changes of the protocol or gemtext. It?s too hard to convince enough implementers to adopt something. Not like the web world, where Chrome *is* the de facto standard. Cheers, ew0k Sent from my Roomba
> On Dec 21, 2020, at 15:47, Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote: > > But yeah, experimentation will happen and that?s a good thing. Yes. > I just believe that almost none of those experiments will lead to de facto changes of the protocol or gemtext. There is nothing to change. The protocol and document format can be used 'as is'. The capabilities of each is defined by their building blocks. The only limit is your imagination. See Astrobotany* for an illustration. > It?s too hard to convince enough implementers to adopt something. Not like the web world, where Chrome *is* the de facto standard. Ironically, I for one, never use Chrome :)
On 21-Dec-2020 13:36, Bj?rn W?rmedal wrote: > > * Gemini will not get a PUT/POST feature, because there isn't a > reasonable way to fit it in. Instead you'll see lots of competing > "companion protocols" that do this, and I honestly don't believe that > any of them will gain great enough traction that more than one browser > will pick any up. HTTP does this better, after all, and you can always > build specialized tools for your particular platform too. > * Gemtext will not get feature X, because it's actually just a > somewhat souped-up text/plain. If you want more out of it there are > already formats that support that a lot better -- markdown, html, pdf, > odt to name a few. Solderpunk mentioned (a long time ago now?) that he > was pondering an even simpler format that would just be plain text > lines and link lines. That point is moot now, because gemtext is so > easily parsed and brings so much more readability at such a low cost > that I think people would just write gemtext anyway. > * Gemini will not inline things or transclude things, because gemini > transactions are expensive in that regard. We don't reuse connections, > and that's a *big* thing about the philosophy and simplicity of > implementations. I get that some people will want to add this, but why > fight that uphill battle when HTTP already has it and does it better? Hi ew0k Let's not leap to too quickly to unsubstantiated assertions - otherwise I shall feel obliged to mutter some opaque comment about the realm of the possible being indeed wider than it may seem at first. :) - Luke
> On Dec 21, 2020, at 21:16, Luke Emmet <luke at marmaladefoo.com> wrote: > > otherwise I shall feel obliged to mutter some opaque comment In my experience, this would be frown upon. This place is all business. Official correspondence only. Also, no IRC (Internet Relay Chat) log transcripts. It's considered rude. Beyond the pale.
---