💾 Archived View for gemi.dev › gemini-mailing-list › 000832.gmi captured on 2023-11-04 at 13:08:30. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Hello, I was wondering. Right now, Gemini uses a non-registered protocol schema (gemini://) and a non-registered MIME-type (text/gemini). The specification is a self-identified "pseudo-specification", and is often not specific enough, leading to a number of de facto standards, and the main website took a descriptive approach, and simply collected[1] these "standards". I understand that this is a very young protocol, but I wanted to post this question anyway. Do you think Gemini will ever become a standard? Even if not a standard published by a big organization like the ISO, ECMA, IETF or IEEE, will text/gemini and the gemini url scheme ever be registered with the IANA? Cheers, almaember [1]: https://gemini.circumlunar.space/docs/best-practices.gmi
Eh, I couldnt care less if it does or not. What would the big benefits be if it does? -------- Original Message -------- On Mar 24, 2021, 6:16 PM, almaember wrote: > Hello, > > I was wondering. Right now, Gemini uses a non-registered protocol > schema (gemini://) and a non-registered MIME-type (text/gemini). > > The specification is a self-identified "pseudo-specification", and is > often not specific enough, leading to a number of de facto standards, > and the main website took a descriptive approach, and simply > collected[1] these "standards". > > I understand that this is a very young protocol, but I wanted to post > this question anyway. Do you think Gemini will ever become a standard? > Even if not a standard published by a big organization like the ISO, > ECMA, IETF or IEEE, will text/gemini and the gemini url scheme ever be > registered with the IANA? > > Cheers, > almaember > > [1]: https://gemini.circumlunar.space/docs/best-practices.gmi
On Thu, 25 Mar 2021 02:13:02 +0000 Jordan <jordan at crowesnest.io> wrote: > Eh, I couldnt care less if it does or not. What would the big > benefits be if it does? > > -------- Original Message -------- > On Mar 24, 2021, 6:16 PM, almaember wrote: > > > Hello, > > > > I was wondering. Right now, Gemini uses a non-registered protocol > > schema (gemini://) and a non-registered MIME-type (text/gemini). > > > > The specification is a self-identified "pseudo-specification", and > > is often not specific enough, leading to a number of de facto > > standards, and the main website took a descriptive approach, and > > simply collected[1] these "standards". > > > > I understand that this is a very young protocol, but I wanted to > > post this question anyway. Do you think Gemini will ever become a > > standard? Even if not a standard published by a big organization > > like the ISO, ECMA, IETF or IEEE, will text/gemini and the gemini > > url scheme ever be registered with the IANA? > > > > Cheers, > > almaember > > > > [1]: https://gemini.circumlunar.space/docs/best-practices.gm One benefit would be a more definitive standard. We could also register the port so no other software will use it. And Gemini might also get into projects like cURL.
almaember <almaember at disroot.org> writes: > And Gemini might also get into projects like cURL. Getting Gemini into cURL would make it easier to add Gemini to other projects that use cURL, such as edbrowse. A net win. -- Chris Brannon Founder: Blind and Low Vision Unix Users Group (https://blvuug.org/). Personal website: (https://the-brannons.com/) Chat: IRC: teiresias on freenode, XMPP: chris at chat.number89.net
On Thu, 25 Mar 2021 00:37:22 -0700 Chris Brannon <chris at the-brannons.com> wrote: > almaember <almaember at disroot.org> writes: > > > And Gemini might also get into projects like cURL. > > Getting Gemini into cURL would make it easier to add Gemini to other > projects that use cURL, such as edbrowse. A net win. > To be fair, they rejected it in the past. The devs didn't like that Gemini uses TOFU not CA certifications. Either way, even if we can't get in cURL right now, a C based Gemini library would be really important
almaember wrote on 2021-03-25 12:26 a.m.: > On Thu, 25 Mar 2021 02:13:02 +0000 > Jordan <jordan at crowesnest.io> wrote: > >> Eh, I couldnt care less if it does or not. What would the big >> benefits be if it does? >> >> -------- Original Message -------- >> On Mar 24, 2021, 6:16 PM, almaember wrote: >> >>> Hello, >>> >>> I was wondering. Right now, Gemini uses a non-registered protocol >>> schema (gemini://) and a non-registered MIME-type (text/gemini). >>> >>> The specification is a self-identified "pseudo-specification", and >>> is often not specific enough, leading to a number of de facto >>> standards, and the main website took a descriptive approach, and >>> simply collected[1] these "standards". >>> >>> I understand that this is a very young protocol, but I wanted to >>> post this question anyway. Do you think Gemini will ever become a >>> standard? Even if not a standard published by a big organization >>> like the ISO, ECMA, IETF or IEEE, will text/gemini and the gemini >>> url scheme ever be registered with the IANA? >>> >>> Cheers, >>> almaember >>> >>> [1]: https://gemini.circumlunar.space/docs/best-practices.gm > > One benefit would be a more definitive standard. We could also register > the port so no other software will use it. > > And Gemini might also get into projects like cURL. The port is already registered - to someone else. Port 1965 has been assigned for years to "qsm-gui." See https://www.iana.org/assignments/service-names-port-numbers/service-names-p ort-numbers.xhtml?&page=19
On Thu, 25 Mar 2021 01:25:53 -0700 Genro <gemini-lists.orbitalfox.eu at box559.com> wrote: > almaember wrote on 2021-03-25 12:26 a.m.: > > On Thu, 25 Mar 2021 02:13:02 +0000 > > Jordan <jordan at crowesnest.io> wrote: > > > >> Eh, I couldnt care less if it does or not. What would the big > >> benefits be if it does? > >> > >> -------- Original Message -------- > >> On Mar 24, 2021, 6:16 PM, almaember wrote: > >> > >>> Hello, > >>> > >>> I was wondering. Right now, Gemini uses a non-registered protocol > >>> schema (gemini://) and a non-registered MIME-type (text/gemini). > >>> > >>> The specification is a self-identified "pseudo-specification", and > >>> is often not specific enough, leading to a number of de facto > >>> standards, and the main website took a descriptive approach, and > >>> simply collected[1] these "standards". > >>> > >>> I understand that this is a very young protocol, but I wanted to > >>> post this question anyway. Do you think Gemini will ever become a > >>> standard? Even if not a standard published by a big organization > >>> like the ISO, ECMA, IETF or IEEE, will text/gemini and the gemini > >>> url scheme ever be registered with the IANA? > >>> > >>> Cheers, > >>> almaember > >>> > >>> [1]: https://gemini.circumlunar.space/docs/best-practices.gm > > > > One benefit would be a more definitive standard. We could also > > register the port so no other software will use it. > > > > And Gemini might also get into projects like cURL. > > > The port is already registered - to someone else. > > Port 1965 has been assigned for years to "qsm-gui." > > See > https://www.iana.org/assignments/service-names-port-numbers/service-names -port-numbers.xhtml?&page=19 So that's a lost battle for use, isn't it? At least we could get the MIME type. What is qsm-gui anyway? It's pretty unlikely we are gonna collide with it.
I think you mean tivoli-npm ;) https://www.iana.org/assignments/service-names-port-numbers/service-names- port-numbers.xhtml?&page=35 > > On Mar 25, 2021 at 4:26 AM, Genro <gemini-lists.orbitalfox.eu at box559.com> wrote: > > > almaember wrote on 2021-03-25 12:26 a.m.: > > On Thu, 25 Mar 2021 02:13:02 +0000 > > Jordan <jordan at crowesnest.io> wrote: > > > >> Eh, I couldnt care less if it does or not. What would the big > >> benefits be if it does? > >> > >> -------- Original Message -------- > >> On Mar 24, 2021, 6:16 PM, almaember wrote: > >> > >>> Hello, > >>> > >>> I was wondering. Right now, Gemini uses a non-registered protocol > >>> schema (gemini://) and a non-registered MIME-type (text/gemini). > >>> > >>> The specification is a self-identified "pseudo-specification", and > >>> is often not specific enough, leading to a number of de facto > >>> standards, and the main website took a descriptive approach, and > >>> simply collected[1] these "standards". > >>> > >>> I understand that this is a very young protocol, but I wanted to > >>> post this question anyway. Do you think Gemini will ever become a > >>> standard? Even if not a standard published by a big organization > >>> like the ISO, ECMA, IETF or IEEE, will text/gemini and the gemini > >>> url scheme ever be registered with the IANA? > >>> > >>> Cheers, > >>> almaember > >>> > >>> [1]: https://gemini.circumlunar.space/docs/best-practices.gm > > > > One benefit would be a more definitive standard. We could also register > > the port so no other software will use it. > > > > And Gemini might also get into projects like cURL. > > > The port is already registered - to someone else. > > Port 1965 has been assigned for years to "qsm-gui." > > See > https://www.iana.org/assignments/service-names-port-numbers/service-names -port-numbers.xhtml?&page=19 > >
On Wed, Mar 24, 2021 at 11:16:27PM +0100, almaember <almaember at disroot.org> wrote a message of 21 lines which said: > I was wondering. Right now, Gemini uses a non-registered protocol > schema (gemini://) It is a registered issue <https://gitlab.com/gemini-specification/protocol/-/issues/6>, unfortunately stalled, partly because it is waiting on the specification. There are proposals for this registration <gemini://gemini.bortzmeyer.org/gemini/scheme-registration.gmi> and even a text to send to IANA (not discussed yet) <gemini://gemini.bortzmeyer.org/gemini/scheme-registration-request.txt>. So, it could be done, it just requires decisions.
On Wed, Mar 24, 2021 at 11:16:27PM +0100, almaember <almaember at disroot.org> wrote a message of 21 lines which said: > Right now, Gemini uses |...] a non-registered MIME-type (text/gemini). It is a recently registered issue <https://gitlab.com/gemini-specification/protocol/-/issues/11>.
On Wed, Mar 24, 2021 at 11:16:27PM +0100, almaember <almaember at disroot.org> wrote a message of 21 lines which said: > I understand that this is a very young protocol, but I wanted to post > this question anyway. Do you think Gemini will ever become a > standard? There are vague plans to submit Gemini to the IETF and get a RFC. As of now, it seems a very distant project. In the mean time, there is work going on to get a proper specification, you can follow it at <https://gitlab.com/gemini-specification/>. > Even if not a standard published by a big organization like the ISO, > ECMA, IETF or IEEE, I certainly hope that closed organisations like ISO or IEEE won't be used.
On Thu, Mar 25, 2021 at 08:26:03AM +0100, almaember <almaember at disroot.org> wrote a message of 34 lines which said: > And Gemini might also get into projects like cURL. Indeed, many projects may hesitate to include Gemini patches if the scheme is not a registered one. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985259
On Thu, Mar 25, 2021 at 09:29:14AM +0100, almaember <almaember at disroot.org> wrote a message of 50 lines which said: > So that's a lost battle for use, isn't it? > At least we could get the MIME type. What is qsm-gui anyway? It's > pretty unlikely we are gonna collide with it. Port registration is followed here, with all the details <https://gitlab.com/gemini-specification/protocol/-/issues/16>
almaember wrote on 2021-03-25 1:29 a.m.: > On Thu, 25 Mar 2021 01:25:53 -0700 > Genro <gemini-lists.orbitalfox.eu at box559.com> wrote: > >> almaember wrote on 2021-03-25 12:26 a.m.: >>> On Thu, 25 Mar 2021 02:13:02 +0000 >>> Jordan <jordan at crowesnest.io> wrote: >>> >>>> Eh, I couldnt care less if it does or not. What would the big >>>> benefits be if it does? >>>> >>>> -------- Original Message -------- >>>> On Mar 24, 2021, 6:16 PM, almaember wrote: >>>> >>>>> Hello, >>>>> >>>>> I was wondering. Right now, Gemini uses a non-registered protocol >>>>> schema (gemini://) and a non-registered MIME-type (text/gemini). >>>>> >>>>> The specification is a self-identified "pseudo-specification", and >>>>> is often not specific enough, leading to a number of de facto >>>>> standards, and the main website took a descriptive approach, and >>>>> simply collected[1] these "standards". >>>>> >>>>> I understand that this is a very young protocol, but I wanted to >>>>> post this question anyway. Do you think Gemini will ever become a >>>>> standard? Even if not a standard published by a big organization >>>>> like the ISO, ECMA, IETF or IEEE, will text/gemini and the gemini >>>>> url scheme ever be registered with the IANA? >>>>> >>>>> Cheers, >>>>> almaember >>>>> >>>>> [1]: https://gemini.circumlunar.space/docs/best-practices.gm >>> >>> One benefit would be a more definitive standard. We could also >>> register the port so no other software will use it. >>> >>> And Gemini might also get into projects like cURL. >> >> >> The port is already registered - to someone else. >> >> Port 1965 has been assigned for years to "qsm-gui." >> >> See >> https://www.iana.org/assignments/service-names-port-numbers/service-name s-port-numbers.xhtml?&page=19 > > So that's a lost battle for use, isn't it? > At least we could get the MIME type. What is qsm-gui anyway? It's > pretty unlikely we are gonna collide with it. > Apparently port 1965 was registered to "qsm-gui" in 2004 but now is assigned to "tivoli npm", at least as listed here: https://www.iana.org/assignments/service-names-port-numbers/service-names-p ort-numbers.xhtml?search=1965 There's more discussion in this thread from last month: https://lists.orbitalfox.eu/archives/gemini/2021/005754.html and in following replies.
On Thu, 25 Mar 2021 09:56:05 +0100 Stephane Bortzmeyer <stephane at sources.org> wrote: > On Wed, Mar 24, 2021 at 11:16:27PM +0100, > almaember <almaember at disroot.org> wrote > a message of 21 lines which said: > There are vague plans to submit Gemini to the IETF and get a RFC. As > of now, it seems a very distant project. In the mean time, there is > work going on to get a proper specification, you can follow it at > <https://gitlab.com/gemini-specification/>. I've heard about the specs, that would be better than the current one. > I certainly hope that closed organisations like ISO or IEEE won't be > used. Can I ask why? I mean they can cause a problem with evolving standards but since Gemini will be frozen anyway I don't see the specific problem.
On Thu, Mar 25, 2021 at 10:08:34AM +0100, almaember <almaember at disroot.org> wrote a message of 18 lines which said: > > I certainly hope that closed organisations like ISO or IEEE won't > > be used. > > Can I ask why? For instance because their standards are not publically available.
On Thu, 25 Mar 2021 11:10:20 +0100 Stephane Bortzmeyer <stephane at sources.org> wrote: > On Thu, Mar 25, 2021 at 10:08:34AM +0100, > almaember <almaember at disroot.org> wrote > a message of 18 lines which said: > > > > I certainly hope that closed organisations like ISO or IEEE won't > > > be used. > > > > Can I ask why? > > For instance because their standards are not publically available. > Interesting, I didn't actually know that. I knew about ISO, but I didn't about IEEE. From what I saw at the ISO the only one I really cared about, the C standard, seems to be public[1], but I understand your concerns. THanks for explaining! [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
On Thu, Mar 25, 2021 at 08:41:16AM +0100, almaember wrote: >Either way, even if we can't get in cURL right now, a C based Gemini >library would be really important Good news: this exists! Building https://sr.ht/~sircmpwn/gmni will build the libgmni library, is linked into the gmni (cURL-like) and gmnlm clients. All three are in the same repo. I'm not aware of any other projects using this library besides cgmnlm, a friendly fork of gmnlm with additional features. -- /Seirdy
On Thu, 25 Mar 2021 11:47:36 -0700 Rohan Kumar <seirdy at seirdy.one> wrote: > On Thu, Mar 25, 2021 at 08:41:16AM +0100, almaember wrote: > >Either way, even if we can't get in cURL right now, a C based Gemini > >library would be really important > > Good news: this exists! Building https://sr.ht/~sircmpwn/gmni will > build the libgmni library, is linked into the gmni (cURL-like) and > gmnlm clients. All three are in the same repo. > > I'm not aware of any other projects using this library besides > cgmnlm, a friendly fork of gmnlm with additional features. > That is great news, at least for the protocol. It will definitely help it's adoption if we have a library we can FFI into any language that exists. It's bad news for me though, because I wanted to write my own library and I will now be just reinventing the wheel. ~almaember
On 3/25/2021 1:59 AM, Stephane Bortzmeyer wrote:
> On Thu, Mar 25, 2021 at 08:26:03AM +0100,
> almaember <almaember at disroot.org> wrote
> a message of 34 lines which said:
>
>> And Gemini might also get into projects like cURL.
>
> Indeed, many projects may hesitate to include Gemini patches if the
> scheme is not a registered one.
I think that's pretty much a non-issue, already, TLS support for gopher
is included in curl, so the notion that Gemini needs some special hat
tip from a large body is a weak argument IMO:
https://github.com/curl/curl/commit/a1f06f32b8603427535fc21183a84ce92a9b96f7
These "projects", weigh the intrinsic value of a protocol being included
on meritious points, rather than being favored by a kingship. Does it
add value to Unices? Does it merit support on its own... etc. And, of
course, do you have any friends with commit privleges or influence? That
always helps lol.
Critical mass, which Gemini is closely approaching, is a much stronger
use case anyway.
Even the IRC RFC's are decrepit and outdated, and IRCv3 is a standards
body unto itself, with nothing having been suffered. Other popular
communications protocols aren't bothering with approvals from
snail-paced bureaucracies either, because it's a generally considered by
many of them as a hindrance to innovation, although at some point this
is definitely something we should have on the roadmap - just not
something to fret over now.
And I think we're getting a little ahead of ourselves by looking at a
draft RFC at this point too. When the Spec is finalized, then it will be
a good time to address those issues, having worked in that area in the
past at length.
I should have said something sooner on the gitlab issue tracker but got
sidetracked. I'll get around to it in a few days.
The matter of Tivoli was raised here a few weeks back. It's basically a
dead horse, and the domain itself for the registration now belongs to
CSC - I don't think that's actually part of IBM's properties ("yet", he
says sardonically). I could be mistaken there, of course. I haven't
checked that far.
We're certainly not dealing with, or looking at having to contend with
WIPO on the whole port registration issue.
So yes, it's certainly a roadmap item, but at this juncture it's more
like putting the cart before the horse. We're building great things
here, and there's an invigorated community focused on that, which is the
most pertinent measure of success by any means.
--
Bradley D. Thornton
Manager Network Services
http://NorthTech.US
TEL: +1.310.421.8268
On Fri, Mar 26, 2021 at 05:30:43PM -0700, Bradley D. Thornton <Bradley at NorthTech.US> wrote a message of 63 lines which said: > > Indeed, many projects may hesitate to include Gemini patches if > > the scheme is not a registered one. > > I think that's pretty much a non-issue, already, TLS support for > gopher is included in curl, so the notion that Gemini needs some > special hat tip from a large body is a weak argument IMO: That's a very strange argument, since Gopher scheme *is* registered: https://www.iana.org/assignments/uri-schemes/uri-schemes.xml > These "projects", weigh the intrinsic value of a protocol being > included on meritious points, rather than being favored by a > kingship. Does it add value to Unices? Does it merit support on its > own... etc. And, of course, do you have any friends with commit > privleges or influence? That always helps lol. The curl maintainer told us he hesitated to merge Gemini patches since the scheme is not registered but, certainly, you know how curl works better than its maintainer.
On Thu, Mar 25, 2021 at 09:59:14AM +0100, Stephane Bortzmeyer <stephane at sources.org> wrote a message of 10 lines which said: > > And Gemini might also get into projects like cURL. > > Indeed, many projects may hesitate to include Gemini patches if the > scheme is not a registered one. Another example: Gitea just told me "Website is not a valid URL." when I was trying to use the URL of my capsule as home page.
On Thu, Mar 25, 2021, Rohan Kumar wrote: >On Thu, Mar 25, 2021 at 08:41:16AM +0100, almaember wrote: >>Either way, even if we can't get in cURL right now, a C based Gemini >>library would be really important > >Good news: this exists! Building https://sr.ht/~sircmpwn/gmni will build >the libgmni library, is linked into the gmni (cURL-like) and gmnlm >clients. All three are in the same repo. Note that gmni recently switched to BearSSL, which does not support TLS 1.3. I'll repeat what I wrote on the spec issue tracker: OpenSSL, LibreSSL, GnuTLS, wolfSSL and BoringSSL all support TLS 1.3. BearSSL is the only TLS library I know of which doesn't. TLS 1.3 is on its roadmap [1], but the last BearSSL release was in August 2018 and the project has been less and less active [2] since. [1] https://bearssl.org/tls13.html [2] https://bearssl.org/gitweb/?p=BearSSL;a=summary Phasing out TLS 1.2 is one of the Gemini project's aspirations, as stated in the spec: > TLS 1.2 is reluctantly permitted for now to avoid drastically reducing > the range of available implementation libraries. Hopefully TLS 1.3 or > higher can be specced in the near future. Clients who wish to be > "ahead of the curve MAY refuse to connect to servers using TLS version > 1.2 or lower. Client developers can use gemini://egsam13.glv.one/ to test TLS 1.3 compatibility.
The security implications of TLS 1.3 are not so grave as to demand an urgent migration. You'll notice that the rest of the internet is not in such a panic over it. BearSSL is compelling for many reasons, and though work is slow, it is definitely underway. We'll get there.
On Sat, Mar 27, 2021, Drew DeVault wrote: >BearSSL is compelling for many reasons I agree. >and though work is slow, it is definitely underway. We'll get there. Ah, so you've been in contact with the developer. Good to hear. Thanks!
On Sat, 2021-03-27, nervuri wrote: >On Sat, Mar 27, 2021, Drew DeVault wrote: >>BearSSL is compelling for many reasons > >I agree. > >>and though work is slow, it is definitely underway. We'll get there. > >Ah, so you've been in contact with the developer. Good to hear. >Thanks! I shouldn't have assumed this. So, just to check: how do you know that work on BearSSL "is definitely underway"? Judging by the commit log, development has just about ground to a halt. Since 2019 there have only been bug & typo fixes and commits have been getting rarer. Also, BearSSL has no external audits and doesn't seem to have many eyes on it. The author claims it's beta-quality software. It also lacks ed25519 support: https://lists.sr.ht/~sircmpwn/gmni-discuss/%3C20210316075714.091701CC0043%4 0dd49836.kasserver.com%3E I hope it picks up again, but would avoid it in its current state. For very low spec systems, Mbed TLS might be a better way to go: https://github.com/ARMmbed/mbedtls
---