Skip to main content

in reply to daniel:// stenberg://

> Its quite similar to going back to GOPHER.
It should be noted that Gemini was literally intended as “Gopher but with TLS and more palatable markup” rather than anything related to modern HTTP.

However your other points not related to the markup/visual style are perfectly accurate IMHO

This entry was edited (11 months ago)
in reply to nytpu

Hmm, and regarding the UTF-8 URLs, IIRC there was a big debate in the mailing list about whether or not clients should punycode IDNs, or transcode them to a different encoding, or just verbatim pass all URLs; and Solderpunk decided to just UTF-8 encode all URLs over the wire which is IMO not any better and possibly worse. Introduces lots of complexity: should clients normalize the Unicode (IME more complex and difficult than punycoding), and if so with what strategy? Should you still percent-encode the path or can you now leave that unencoded too? Lots of issues.
This entry was edited (11 months ago)
in reply to nytpu

@nytpu yeah, it seems totally crazy to me and seriously under-documented what exactly it means
in reply to daniel:// stenberg://

@nytpu agreed. that was one of the most frustrating bikeshedding decisions. Nobody chiming in really understood the complexity of the URI spec or the implications of what they were proposing, and it went totally against the other goals of the project.

Using TLS, for instance, was chosen because library support was so common and accessible it lowered the barrier to server and client creation. Tweaking URL parsing made things harder without any tangible benefit.

I hope that gets scrapped, personally. And yes, carving the spec into 2 (protocol and document format) has been discussed already and piloted. It just hasn't made its way back to the official living document. That would help as well.

Where I think we'll probably see more pushback is on TOFU (I fully support DANE, but DNSSEC is still such a barrier), and chunking. There's a major philosophy of 1-request-per-document which seems antithetical to chunking.

Regardless, all 100% valid criticism and from one of the most reputable sources. I'm sure the whole community will be discussing this for weeks to come. Cheers!

in reply to tomasino

@tomasino @nytpu in fact, using plain old CA is the *least* complex and most established system and way more secure than TOFU...

Thanks for the comment. I fully understand that my views and opinions may not align very well with many of the people in and fans of the Gemini project.

in reply to daniel:// stenberg://

@tomasino @nytpu Wasn't TOFU chosen because you largely can't be sure the remote hasn't been pwn'd nor its cert faked by a malicious CA, thus having little benefit beyond just making third-party eavesdropping harder?
in reply to daniel:// stenberg://

I love Gemini to bits, and I host my own server and everything, but the fact TLS is a REQUIREMENT from Day 1 has kinda bugged me to be honest.

If I were to write my own Gemini client (which is supposed to be 'easy') then I'd have to have all the crypto bits in place before I can ensure my code is on the right track to verify I can even make a proper connection at all. I guess I owe it to myself to be better acquainted with TLS in practice, but, meh, I wish I didn't NEED to.

Also, Gemini feels like a PERFECT FIT for retro computers to disseminate and consume information over the internet... except the TLS bits make it out of reach! I would love to be able to surf across Gemini on my old Atari ST, but with only 1 MB of RAM and a 8MHz CPU I'm not sure how feasible that is without some kind of proxy -- which you correctly state in your article has problems in itself.

in reply to daniel:// stenberg://

100% of web boomers agree...
Gemini is useless.
Just like they said Linux was in 1995.
"It doesnt follow the correct standards. It doesnt cow tow to the approproate bureacratic organizations."

Youre totally right. You should ignore it, and GTFO.

in reply to artyr3

@artyr3 sure, or you could actually READ my post to learn that it was not about that...
in reply to daniel:// stenberg://

you know, not everyone who thinks youre an ass has misunderstood you.
in reply to daniel:// stenberg://

I do not get your point about utf8 in URI. There was a big debate on utf8 in domain part and wether to punycode, which I kind of lost I think, but for the path part I do not see the ambiguity, you encode as utf8. and percent escaping is also allowed.
But you take an example where you have data and you do not know its encoding, then it's useless data, no? If you have to guess encoding it means a non-utf8 uri would not have helped, the guessing would have happenned on server side?
in reply to MCMic

@come yes, but a URL has no charset, it literally is just data. A server can't figure that out either.
in reply to daniel:// stenberg://

I do not see how it can be used then. If you have data without knowing the charset you cannot use it. I find it quite sane that Gemini makes it clear it's always utf-8.
in reply to MCMic

@come as clear as mud!
This entry was edited (11 months ago)
in reply to daniel:// stenberg://

It reads like you spent more time critiquing the spec than the developers spent implementing it. It rings of “but my protocol will be cooler and more exclusive” while ignoring why we have the current state. Gemini would be better off as a subset of the current web (http+tls+their silly media format). I have similar concerns around IPFS, where the p2p and content-addressed URIs encourage vs avoid censorship and surveillance (also the p2p base protocol is a free ddos net, wee).
in reply to HD Moore

@hdm someone proposes we should support Gemini in curl. I take the time to read and understand the protocol (to understand that task better). As a consequence, I find flaws and errors in the spec and write them down in a blog post.

I read specs and write network code all day, every day.

in reply to daniel:// stenberg://

I really appreciate your review of the protocol (and all your work on cURL and c-ares), thanks again!