As it stands, Gemini [1] -and especially Mercury [2]- is refreshingly approachable and frugal. A -very minimal- one-liner Gemini client: # openssl s_client -quiet -crlf -connect gemini.conman.org:1965 <<< gemini://gemini.conman.org/ 2>/dev/null 20 text/gemini Welcome to Conman Laboraties Gemini Server! And that is that. The whole Gemini protocol in 3 lines. But what 3 lines! A request is a single line containing a fully specified URL. A successful response is a single line containing the numeric response code, a space, and a content-type. The canonical content, text/gemini, consists of two core line types: text and link. All UTF-8 encoded. Over TLS. And that is that. Quite spartan at first glance. But also, possibly, quite universal. Fancy jumping the shark over Zawinski's law [3] from the onset? Combine RFC5092 [4] for the request and RFC2045 [5] for the response: imap://minbari.example.org/gray-council/;uid=20 <imap://minbari.example.org/gray-council/;uid=20> 20 message/rfc822 Mime-Version: 1.0 ... Fancy supporting multiple protocols at once? Look at conman's nifty sigil script [6], which supports HTTP, GEMINI, and GOPHER for good measure. From one CGI script. In other words, because a Gemini request is a full-fledged URL, it can support any number of protocols, as long as such protocol can be expressed as an URL [7]. Ditto for the response, which can be any media type [8] a Gemini server cares to generate. In short, a Gemini URL request combined with a Gemini media type response is quite universal indeed. Ditto for the rather unassuming text/gemini content type. While at its core it only sports 2 line types, the presence of the link line, which is an URL, open the door to infinite composition. Fancy an atom feed? Add a feed URI [9] in your text/gemini: => feed://example.com/entries.atom Would you like to anchor your text/gemini in a point in time? Perhaps the tag URI can help: => tag:example.com,2004-01-01:1234 Indicate a location? A geo URI may help: => geo:37.786971,-122.399677 etc, etc, the possibilities are endless. Quite a lot of firepower for a two lines protocol, with a two line content type :) -- PA [1] https://portal.mozz.us/gemini/gemini.circumlunar.space/docs/spec-spec.t xt <https://portal.mozz.us/gemini/gemini.circumlunar.space/docs/spec-spec.txt> [2] https://portal.mozz.us/gemini/gemini.circumlunar.space/users/solderpunk /cornedbeef/the-mercury-protocol.gmi <https://portal.mozz.us/gemini/gemini.circumlunar.space/users/solderpunk/co rnedbeef/the-mercury-protocol.gmi> [3] https://en.wikipedia.org/wiki/Jamie_Zawinski <https://en.wikipedia.org/wiki/Jamie_Zawinski> [4] https://tools.ietf.org/html/rfc5092 <https://tools.ietf.org/html/rfc5092> [5] https://tools.ietf.org/html/rfc2045 <https://tools.ietf.org/html/rfc2045> [6] https://portal.mozz.us/gemini/gemini.conman.org/sigil-cgi.lua <https://portal.mozz.us/gemini/gemini.conman.org/sigil-cgi.lua> [7] https://en.wikipedia.org/wiki/List_of_URI_schemes <https://en.wikipedia.org/wiki/List_of_URI_schemes> [8] https://en.wikipedia.org/wiki/Media_type <https://en.wikipedia.org/wiki/Media_type> [9] https://en.wikipedia.org/wiki/Feed_URI_scheme <https://en.wikipedia.org/wiki/Feed_URI_scheme> [10] https://en.wikipedia.org/wiki/Tag_URI_scheme <https://en.wikipedia.org/wiki/Tag_URI_scheme> [11] https://en.wikipedia.org/wiki/Geo_URI_scheme <https://en.wikipedia.org/wiki/Geo_URI_scheme> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200602/3392 6e11/attachment-0001.htm>
Maybe Gemini is too open to protect users from the web as it is now... freD. ??????? Original Message ??????? On Tuesday 2 June 2020 03:14, Petite Abeille <petite.abeille at gmail.com> wrote: > As it stands, Gemini [1] -and especially Mercury [2]- is refreshingly approachable and frugal. > > A -very minimal- one-liner Gemini client: > > # openssl s_client -quiet -crlf -connect gemini.conman.org:1965 <<< gemini://gemini.conman.org/ 2>/dev/null > 20 text/gemini > Welcome to Conman Laboraties Gemini Server! > > And that is that. The whole Gemini protocol in 3 lines. > > But what 3 lines! > > A request is a single line containing a fully specified URL. > A successful response is a single line containing the numeric response code, a space, and a content-type. > The canonical content, text/gemini, consists of two core line types: text and link. > All UTF-8 encoded. Over TLS. > > And that is that. > > Quite spartan at first glance. > > But also, possibly, quite universal. > > Fancy jumping the shark over Zawinski's law [3] from the onset? > > Combine RFC5092 [4] for the request and RFC2045 [5] for the response: > > imap://minbari.example.org/gray-council/;uid=20 > 20 message/rfc822 > Mime-Version: 1.0 > ... > > Fancy supporting multiple protocols at once? > > Look at conman's nifty sigil script [6], which supports HTTP, GEMINI, and GOPHER for good measure. From one CGI script. > > In other words, because a Gemini request is a full-fledged URL, it can support any number of protocols, as long as such protocol can be expressed as an URL [7]. > > Ditto for the response, which can be any media type [8] a Gemini server cares to generate. > > In short, a Gemini URL request combined with a Gemini media type response is quite universal indeed. > > Ditto for the rather unassuming text/gemini content type. > > While at its core it only sports 2 line types, the presence of the link line, which is an URL, open the door to infinite composition. > > Fancy an atom feed? Add a feed URI [9] in your text/gemini: > > => feed://example.com/entries.atom > > Would you like to anchor your text/gemini in a point in time? Perhaps the tag URI can help: > > => tag:example.com,2004-01-01:1234 > > Indicate a location? A geo URI may help: > > => geo:37.786971,-122.399677 > > etc, etc, the possibilities are endless. > > Quite a lot of firepower for a two lines protocol, with a two line content type :) > > -- > PA > > [1] https://portal.mozz.us/gemini/gemini.circumlunar.space/docs/spec-spec.txt > [2] https://portal.mozz.us/gemini/gemini.circumlunar.space/users/solderpu nk/cornedbeef/the-mercury-protocol.gmi > [3] https://en.wikipedia.org/wiki/Jamie_Zawinski > [4] https://tools.ietf.org/html/rfc5092 > [5] https://tools.ietf.org/html/rfc2045 > [6] https://portal.mozz.us/gemini/gemini.conman.org/sigil-cgi.lua > [7] https://en.wikipedia.org/wiki/List_of_URI_schemes > [8] https://en.wikipedia.org/wiki/Media_type > [9] https://en.wikipedia.org/wiki/Feed_URI_scheme > [10] https://en.wikipedia.org/wiki/Tag_URI_scheme > [11] https://en.wikipedia.org/wiki/Geo_URI_scheme -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200602/007a 5d92/attachment.htm>
> On Jun 2, 2020, at 08:40, defdefred <defdefred at protonmail.com> wrote: > > Maybe Gemini is too open to protect users from the web as it is now... > How so? Gemini/Mercury has a quite impressive "power to weight ratio". A poster child for the principle of parsimony. Bravo. Such power, in and by itself, in no way help, hinder, or compromise anything on its own. Time will tell how it's actually used.
Howdy, Thanks for this enthusiastic summary of your very positive feelings about Gemini! I like the "approchable and frugal" characterisation. I fully share your enthusiasm about Gemini as a protocol, i.e. the use of nothing but URLs as requests as the the reduction of response headers to explicit status information and a media type. I really think that good design decisions have been made in this part of the spec and I don't think there's really anything there to change (note that the intended addition of the `lang` parameter is *not* a change to this level of the protocol, but rather an extension of the text/gemini media type which is a separte thing). On this front, I am content. I can't quite get as enthusiastic as you are about the range of possibilities for text/gemini. I fully grant that everything you wrote about is totally valid as text/gemini is currently specced. I will not even deny that many of your proposals seem genuinely super useful. E.g. I am by now a well-documented fan of Atom feeds, and the feed: URI scheme could be used as a way to add autodiscovery of feeds to Gemini, circumventing the fact that we have no <rel> tags. And the tag: URI scheme is also a nice way to put an unambiguous timestamp on a document. Not only could this be very useful for search purposes, but it would simplify the automatic generation of Atom feeds (it's now very clear that the use of filesystem timestamps as used by gemfeed is not robust against different people's workflows). However, it's also true that none of this is stuff I ever envisaged being in Gemini, because I had a naive mental model of what URIs were. I feel kind of powerless to prevent the use of these schemes. I don't want the Gemini spec to include an explicit whitelist or blacklist or schemes (although I'm tempted to forbid data:). This will lead to a maintenance nightmare as new schemes are proposed (I don't want to be constantly updating Gemini, I want to try to "get it right" and then just leave it be), feels authoritarian, and will anyway be unenforcible if popular opinion wants to use a certain scheme. So, it seems this stuff is going to happen. My big concern is not simply that people will do things with Gemini that I didn't envision. That was always going to happen to some extent anyway. My concern is that this stuff substantially complicates the job of designing and implementing clients. When text/gemini was designed, I used the mental model of "URIs as pointers to stuff you could fetch off the internet". This is clearly what links lines were "supposed to be". The spec says that clients can render those lines however they like, but because of that limited sense of what a URI could be, it went without saying that:
> On Jun 2, 2020, at 20:19, solderpunk <solderpunk at SDF.ORG> wrote: > > With stuff like data:, feed:, tag:, geo:, and the myriad other > "non-locational schemes", all of this goes out the window. What is a > client supposed to do with all these? Either a client understands an URI scheme, say http/https, and knows what to do with it (e.g. turn it into an interactive hyperlink of sort, pretty print it somehow, etc), or it doesn't, in which case just display it 'as is'. In short, only decorate scheme you know, leave the rest alone, and render it as static text. Never hide anything. Put another way, text/gemini is fundamentally text. Nothing more, nothing less. And that's good enough for a minimal client. More advance clients could choose to render links to the best of their abilities, say gemini:// links are turned into navigational aids of sort. And that is that.
On Tue, Jun 02, 2020 at 09:09:47PM +0200, Petite Abeille wrote: > Either a client understands an URI scheme, say http/https, and knows what to do with it (e.g. turn it into an interactive hyperlink of sort, pretty print it somehow, etc), or it doesn't, in which case just display it 'as is'. > > In short, only decorate scheme you know, leave the rest alone, and render it as static text. > > Never hide anything. > > Put another way, text/gemini is fundamentally text. Nothing more, nothing less. And that's good enough for a minimal client. > > More advance clients could choose to render links to the best of their abilities, say gemini:// links are turned into navigational aids of sort. > > And that is that. This sounds "short and sweet" and simple, but this basically makes Gemini infinitely extensible. Link lines stop having anything to do with the concept of "links", and become vehicles for anything that somebody wants to come up with a URI scheme for, which is a large and totally open category which will grow over time and may come to include very scary things (for the love of God, there was an IETF draft for a javascript: scheme! [1]). Giving clients the power to recognise any old scheme which comes along is guaranteed to induce a repeat of the evolution of the web. Basically we can now think of the line: => scheme:restofuri Human friendly label as equivalent to something like: <scheme arg1="restofuri" arg2="Human friendly label"/> text/gemini would be fully as extensible as HTML where client authors can just invent new tags like <blink> and <marquee>. It's exactly what nobody here wants. I am *so angry* that there isn't a construct in the internet architecture which is *nothing more* than a convenient way to concisely specify an application protocol, a hostname or IP address, a port, and a path. This is such an obviously useful thing to have. It's what almost everybody *thinks* a URL is, but it turns out that's wrong. Who would have thought that Gopher's clunky and archaic notation of: path<TAB>hostname<TAB>port<TAB> literally has not been improved on in ~30 years? At this point I am honestly considering speccing that => lines may
> On Jun 2, 2020, at 22:00, solderpunk <solderpunk at SDF.ORG> wrote: > > Permitting *any* RFC-compliant URL is just way, way too open-ended and > defeats the point of so much careful efforts elsewhere in the protocol. I suspect you are overthinking it :) URIs are a good thing. Thinks of them as structured tags. Nothing more, nothing less. They do not imply any behavior, but rather convey information. Structured information. When writing my next great novel, I *do* want to stick a recognizable ISBN to it: URN:ISBN:978-0061148521 Uniform Resource Names (URN) Namespaces https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml https://tools.ietf.org/html/rfc2141
> At this point I am honestly considering speccing that => lines may
It was thus said that the Great solderpunk once stated: > > In short, there was supposed to be a single, concrete "unit of > interface" with narrow scope that a client author has to decide how to > implement. Variation between clients in how that was done would not > substantially change the overall user experience. > > With stuff like data:, feed:, tag:, geo:, and the myriad other > "non-locational schemes", all of this goes out the window. What is a > client supposed to do with all these? Web and gopher clients already face this issue. Web browsers have solved this issue by allowing the user to configure a program to handle an unknown URI scheme. I've registered the "gopher" with Firefox to go through a gopher proxy, so I can't see why this can't be an option for Gemini clients. I'm not aware of a scheme like mailcap (for handing of MIME types) for URI schemes, but even a simple: gopher: my-gopher-client http: firefox https: firefox geo: missile-launcher will be good enough (and not even mandatory---I'm just throwing out an idea here). > If I want to write a minimal > client that just knows how to follow gemini:// links and nothing else, > what the heck do I do with a tag: link? Display it to the user, or > hide it? As a quick solution, how about just display a page with: I don't know how to handle tag:conman.org,1998-10-16:site Sorry about that. Done! Ship it! > If I choose to display it using exactly the same code path I > would use to to display a gemini:// link, I need to go out of my way > to make that code path robust against stuff that doesn't make sense for > "proper" links, like there not being a "netloc" component (AV-98 > currently silently drops tag: links, for example, because they cause an > Exception when I try to handle them as if they were a "proper" link). There exists code to parse a URI, whether homegrown or a library. At the very least, the client can check the scheme portion for "gemini". I've already seen URIs for http:, https:, mailto: and data: [1]. > If I *do* successfully display them as if they were a proper link and > the user tries to follow one, what is supposed to happen? Assuming I > fix the aforementioned problem, AV-98 will say "Sorry, no support for > tag", because it fills out a template that I designed thinking of cases > like "Sorry, no suport for ftp", which most users will understand. *I* > would be very confused by a "no support for tag" message, I'd think > "What, there *are* no tags in Gemini, what's going on here?". I've already mentioned Firefox, but Lynx gave me "Alert!: Unsupported URL scheme!" when I tried using a gemini: link on a webpage. Don't sweat it. > So, I'm not sure how to proceed here. People should feel free to > experiment with possibilities, because informed decisions are better > than uninformed ones. But I would advise people not to get fiercely > attached to any idea of how non-locational URLs might work in Gemini. > It's uncharted territory. I think your concern (or fear) is overblown here. Outside of http: https: mailto: I think other URI types on the web will fall deep into the 0.56% of links that aren't the above. -spc [1] The Gemini Client Torture Test
On Tue, 2 Jun 2020, colecmac at protonmail.com wrote: >> At this point I am honestly considering speccing that => lines may > *only* use URLs whose scheme corresponds to an application protocol. > Permitting *any* RFC-compliant URL is just way, way too open-ended and > defeats the point of so much careful efforts elsewhere in the protocol. > > I would be in favour of this, I don't want to start seeing pages that > have tags on them. I believe I earlier proposed something along the lines of whitelisting or blacklisting of URL schemes, but I don't really have a coherent proposal. Ultimately there is a tradeoff which must be made between the benefits of the IETF-derived approach (existing, documented standards; existing, debugged implementations; conceptual familiarity) and the drawbacks (the assumptions with which these come freighted; the "robustness principle" rhetoric; the capture of IETF standards-making by particular interests and philosophies). I don't think the existing standards-making systems can be relied upon to produce something clean and module like a resource locator that couldn't be extended into a Turing-complete language. Therefore, if we want to have a minimalist alternative, we may need to depart somewhat from re-using IETF / W3C standards, which I would support. The WWW already exists for people who want the more complicated/ornate systems. Mk
On Tue, Jun 02, 2020 at 10:21:43PM +0200, Petite Abeille wrote: > > > On Jun 2, 2020, at 22:00, solderpunk <solderpunk at SDF.ORG> wrote: > > > > Permitting *any* RFC-compliant URL is just way, way too open-ended and > > defeats the point of so much careful efforts elsewhere in the protocol. > > I suspect you are overthinking it :) > > URIs are a good thing. > > Thinks of them as structured tags. > > Nothing more, nothing less. That's something more than I want! :) > They do not imply any behavior, but rather convey information. Structured information. This is the problem. They are way too general purpose. They can convey just about any kind of information. Surely, there are contexts where that's useful. But sometimes you want to be able to convey information of limited scope. MIME media types are structured information (with a main type, sub type, parameters), but structured information of a certain type with a clear scope. That's a good thing, from a protocol design perspective. It lets you reason about the consequences of what you're specifying. Arbitrary structured information does not. Cheers, Solderpunk
> On Jun 2, 2020, at 23:40, solderpunk <solderpunk at SDF.ORG> wrote: > > Arbitrary structured information does not. Consider the following two URI: https://tools.ietf.org/html/rfc2648 vs. urn:ietf:rfc:2648 Which one actually refers to RFC2648 A URN Namespace for IETF Documents?
> Message: 1 > Date: Tue, 2 Jun 2020 20:00:42 +0000 > From: solderpunk <solderpunk at SDF.ORG> > To: Gemini application layer protocol <gemini at lists.orbitalfox.eu> > Subject: Re: approachabe & frugal & composable > Message-ID: <20200602200042.GC11961 at SDF.ORG> > Content-Type: text/plain; charset=us-ascii > > On Tue, Jun 02, 2020 at 09:09:47PM +0200, Petite Abeille wrote: > >> Either a client understands an URI scheme, say http/https, and knows what to do with it (e.g. turn it into an interactive hyperlink of sort, pretty print it somehow, etc), or it doesn't, in which case just display it 'as is'. >> >> In short, only decorate scheme you know, leave the rest alone, and render it as static text. >> >> Never hide anything. >> >> Put another way, text/gemini is fundamentally text. Nothing more, nothing less. And that's good enough for a minimal client. >> >> More advance clients could choose to render links to the best of their abilities, say gemini:// links are turned into navigational aids of sort. >> >> And that is that. > > This sounds "short and sweet" and simple, but this basically makes > Gemini infinitely extensible. Link lines stop having anything to do > with the concept of "links", and become vehicles for anything that > somebody wants to come up with a URI scheme for, which is a large and > totally open category which will grow over time and may come to include > very scary things (for the love of God, there was an IETF draft for a > javascript: scheme! [1]). Giving clients the power to recognise any old > scheme which comes along is guaranteed to induce a repeat of the > evolution of the web. Basically we can now think of the line: > > => scheme:restofuri Human friendly label > > as equivalent to something like: > > <scheme arg1="restofuri" arg2="Human friendly label"/> > > text/gemini would be fully as extensible as HTML where client authors > can just invent new tags like <blink> and <marquee>. It's exactly what > nobody here wants. > > I am *so angry* that there isn't a construct in the internet > architecture which is *nothing more* than a convenient way to concisely > specify an application protocol, a hostname or IP address, a port, and > a path. This is such an obviously useful thing to have. It's what > almost everybody *thinks* a URL is, but it turns out that's wrong. Who > would have thought that Gopher's clunky and archaic notation of: > > path<TAB>hostname<TAB>port<TAB> > > literally has not been improved on in ~30 years? > > At this point I am honestly considering speccing that => lines may > *only* use URLs whose scheme corresponds to an application protocol. > Permitting *any* RFC-compliant URL is just way, way too open-ended and > defeats the point of so much careful efforts elsewhere in the protocol. > > Cheers, > Solderpunk I feel like what's been revealed here is that you have little control of this the way it's designed. You could eschew URIs for your own format, but then it would be just harder than it is now to use off-the-shelf tools to "pervert" gemini, but still possible. It could also be that people fork into another protocol. In the end, the browser can be handed something by a server, and if the browser and server are both consenting programs, they'll do what they want. And if enough people think it's cool, there will be more of those servers, more of that content, and then more of those browsers. This is what happened to http://, isn't it? How Netscape defeated Mosaic? Some of the excitement around gemini feels like it's because it's a rebooting of http. I definitely feel it some myself. I like the aesthetic, though, and the idea behind it. The reality is, too, that if people extend gemini into another http, it will just be not-as-good http. But can you stop people from super-setting gemini? PS reading all this gemini stuff makes me want to create a "wiki://" scheme, like native super-wiki web
I think that because it's so easy to implement a client, it won't succumb to this sort of thing. Most people's homemade clients won't implement geminiscript or whatever, so people will be discouraged from using it On Tue, Jun 02, 2020 at 09:55:35PM +0000, Pete D. wrote: > > > Message: 1 > > Date: Tue, 2 Jun 2020 20:00:42 +0000 > > From: solderpunk <solderpunk at SDF.ORG> > > To: Gemini application layer protocol <gemini at lists.orbitalfox.eu> > > Subject: Re: approachabe & frugal & composable > > Message-ID: <20200602200042.GC11961 at SDF.ORG> > > Content-Type: text/plain; charset=us-ascii > > > > On Tue, Jun 02, 2020 at 09:09:47PM +0200, Petite Abeille wrote: > > > > > Either a client understands an URI scheme, say http/https, and knows what to do with it (e.g. turn it into an interactive hyperlink of sort, pretty print it somehow, etc), or it doesn't, in which case just display it 'as is'. > > > > > > In short, only decorate scheme you know, leave the rest alone, and render it as static text. > > > > > > Never hide anything. > > > > > > Put another way, text/gemini is fundamentally text. Nothing more, nothing less. And that's good enough for a minimal client. > > > > > > More advance clients could choose to render links to the best of their abilities, say gemini:// links are turned into navigational aids of sort. > > > > > > And that is that. > > > > This sounds "short and sweet" and simple, but this basically makes > > Gemini infinitely extensible. Link lines stop having anything to do > > with the concept of "links", and become vehicles for anything that > > somebody wants to come up with a URI scheme for, which is a large and > > totally open category which will grow over time and may come to include > > very scary things (for the love of God, there was an IETF draft for a > > javascript: scheme! [1]). Giving clients the power to recognise any old > > scheme which comes along is guaranteed to induce a repeat of the > > evolution of the web. Basically we can now think of the line: > > > > => scheme:restofuri Human friendly label > > > > as equivalent to something like: > > > > <scheme arg1="restofuri" arg2="Human friendly label"/> > > > > text/gemini would be fully as extensible as HTML where client authors > > can just invent new tags like <blink> and <marquee>. It's exactly what > > nobody here wants. > > > > I am *so angry* that there isn't a construct in the internet > > architecture which is *nothing more* than a convenient way to concisely > > specify an application protocol, a hostname or IP address, a port, and > > a path. This is such an obviously useful thing to have. It's what > > almost everybody *thinks* a URL is, but it turns out that's wrong. Who > > would have thought that Gopher's clunky and archaic notation of: > > > > path<TAB>hostname<TAB>port<TAB> > > > > literally has not been improved on in ~30 years? > > > > At this point I am honestly considering speccing that => lines may > > *only* use URLs whose scheme corresponds to an application protocol. > > Permitting *any* RFC-compliant URL is just way, way too open-ended and > > defeats the point of so much careful efforts elsewhere in the protocol. > > > > Cheers, > > Solderpunk > > > I feel like what's been revealed here is that you have little control of > this the way it's designed. You could eschew URIs for your own format, but > then it would be just harder than it is now to use off-the-shelf tools to > "pervert" gemini, but still possible. It could also be that people fork into > another protocol. In the end, the browser can be handed something by a > server, and if the browser and server are both consenting programs, they'll > do what they want. And if enough people think it's cool, there will be more > of those servers, more of that content, and then more of those browsers. > This is what happened to http://, isn't it? How Netscape defeated Mosaic? > > > Some of the excitement around gemini feels like it's because it's a > rebooting of http. I definitely feel it some myself. I like the aesthetic, > though, and the idea behind it. The reality is, too, that if people extend > gemini into another http, it will just be not-as-good http. > > But can you stop people from super-setting gemini? > > PS reading all this gemini stuff makes me want to create a "wiki://" scheme, > like native super-wiki web
It was thus said that the Great solderpunk once stated: > Basically we can now think of the line: > > => scheme:restofuri Human friendly label > > as equivalent to something like: > > <scheme arg1="restofuri" arg2="Human friendly label"/> > > text/gemini would be fully as extensible as HTML where client authors > can just invent new tags like <blink> and <marquee>. It's exactly what > nobody here wants. "The more you tighten your grip, Tarkin, the more star systems will slip thorugh your fingers." Here's the list of all registered URI schemes: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml I will bet you that 99 44/100% of all links on the Internet are: https: http: mailto: file: (and these are always a mistake on the part of the author) ftp: gopher: Honestly, I don't think you have to worry too much. -spc
It was thus said that the Great Martin Keegan once stated: > > I don't think the existing standards-making systems can be relied upon to > produce something clean and module like a resource locator that couldn't > be extended into a Turing-complete language. Therefore, if we want to > have a minimalist alternative, we may need to depart somewhat from > re-using IETF / W3C standards, which I would support. The WWW already > exists for people who want the more complicated/ornate systems. And if you think the bikeshedding on text/gemini is bad ... -spc (Just a gut feeling here about a long, dark, slog)
It was thus said that the Great Petite Abeille once stated: > > > > On Jun 2, 2020, at 23:40, solderpunk <solderpunk at SDF.ORG> wrote: > > > > Arbitrary structured information does not. > > Consider the following two URI: > > https://tools.ietf.org/html/rfc2648 > > vs. > > urn:ietf:rfc:2648 > > > Which one actually refers to RFC2648 A URN Namespace for IETF Documents? Shouldn't that be: <tag://tools.ieft.org,1995-03-11:rfc2648>? My bogging engine [1] is configured to recognize links in the form of rfc:2648 and generate a link to the RFC. Also, I have: asin:blahblahblah to link to my Amazon affilate store. But that's hidden behind the scenes and those shouldn't leak out. -spc (But I'm probably scaring solderpunk even more now ... ) [1] https://github.com/spc476/mod_blog
Martin Keegan writes: > I don't think the existing standards-making systems can be relied upon > to produce something clean and module like a resource locator that > couldn't be extended into a Turing-complete language. Reminds me of this protest article by one of the Chicken developers about the sad state of the URL spec: https://www.more-magic.net/posts/an-appeal-to-whatwg-uri-spec.html plugd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200603/78b4 4e95/attachment.sig>
I'm pleased to announce that gemini://cosmic.voyage is up and running finally. That makes it accessible over gopher, web, and gemini (the trifecta!). For those of you unfamiliar, cosmic voyage is a tilde community (free pubnix) geared toward writing sci-fi stories in a semi-shared universe. If you're interested in joining, visit the "join" page to sign up. For aggregators, we have a master log page that can be watched for changes at: gemini://cosmic.voyage/log/ There's also an RSS feed of the most recent 100 logs in full text at: gemini://cosmic.voyage/rss.xml The perm-links in this feed point to gopher currently, but I'll be tweaking that on the gemini side shortly. I hope this goes a long way to adding more non-gemini-focused content to the gemini environment. See you round the 'verse, tomasino
On Wed, Jun 03, 2020 at 08:17:46AM +0000, James Tomasino wrote: > I'm pleased to announce that gemini://cosmic.voyage is up and running > finally. That makes it accessible over gopher, web, and gemini (the > trifecta!). Very happy to see that this is official. :) I appreciate you throwing your support behind Gemini like this, and I'm sorry I ambandoned my ship so early. :p I've added you to the list of known hosts. cosmic.voyage is number 48! Only two places left before the hand-maintained list becomes deprecated... Cheers, Solderpunk
Could you add my server, makeworld.gq? I didn't realize you still had spots to fill. Thanks, makeworld ??????? Original Message ??????? On Wednesday, June 3, 2020 2:15 PM, solderpunk <solderpunk at SDF.ORG> wrote: > On Wed, Jun 03, 2020 at 08:17:46AM +0000, James Tomasino wrote: > > > I'm pleased to announce that gemini://cosmic.voyage is up and running > > finally. That makes it accessible over gopher, web, and gemini (the > > trifecta!). > > Very happy to see that this is official. :) I appreciate you throwing > your support behind Gemini like this, and I'm sorry I ambandoned my ship > so early. :p > > I've added you to the list of known hosts. cosmic.voyage is number 48! > Only two places left before the hand-maintained list becomes > deprecated... > > Cheers, > Solderpunk
> On Jun 3, 2020, at 03:28, Sean Conner <sean at conman.org> wrote: > > Shouldn't that be: <tag://tools.ieft.org,1995-03-11:rfc2648>? Not quite, no. Even though the IEFT could choose to use the tag uri for such purpose. There is a dedicated URN Namespace for IETF Documents instead: https://tools.ietf.org/html/rfc2648 So, urn:ietf:rfc:2648 is actually correct. The original purpose of the tag URI is to allow anyone to mint unique identifiers, without bothering with a central authority: https://en.wikipedia.org/wiki/Tag_URI_scheme https://tools.ietf.org/html/rfc4151 Used to be popular in the syndication world (RSS/Atom/etc).
---
Previous Thread: GUS database (was: Re: Ambiguity in unordered list item definition)