-- Leo's gemini proxy
-- Connecting to dece.space:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini;lang=en
The only place on this capsule where I engage in meta-talk about Gemini and Gemtext. Hey, it's my reward for being here for more than a year now without engaging in flame wars! Please don't take anything personally. ♥
No. In this post, Sean Conman writes about the two groups of people wanting to remove TLS from Gemini:
Next sections dive in the specifics of why TLS would be undesirable, but I would first add that posts advocating for a Gemini without TLS are oblivious to what I'd call community dynamics. People got on Gemini mostly because they felt that ~solderpunk had an interesting and clever vision about a protocol that would sit between Gopher and the Web. The merits of his vision go beyond technical qualities: Gemini resonated with people because it was a product of various reflections such as offline computing, permacomputing, “solarpunk” and more. Maybe some of us are here mostly because the spec is of technical interest, but many geminauts simply don't care that much.
Why is that important? I'm under the impression that people pushing for a Gemini without TLS (or other slight variations of Gemini) think that others would join the new protocol naturally, by virtue of a technically superior spec. This simply did not happen with the implemented alternatives. Many people not caring too much about TLS on Gopher stayed on Gopher because a community exists there; others even started using Gopher after discovering Gemini because they felt like Gopher was a nice place for unencrypted communication. The Gemini protocol brought enough new value between Gopher and the Web to actually push people to join it and make it flourish.
I like Spartan though, for some reason.
No. To be precise:
Some languages have TLS support included, relying on system libraries.
Some projects include external TLS libraries that are usually some thin layers on top of the system libraries.
Some projects actually pull external independent TLS libraries.
OK, if you start looking hard, ancient systems do not easily support the lowest requirement for Gemini cryptography (TLS v1.2), but solutions exist if you want to make the effort.
If you don't want to trust the TLS libraries installed on your system, you have much bigger issues than Gemini, but it's otherwise valid skepticism I guess, beside the fact that OpenSSL is one of the most audited software in the entire world (now), but whatever. I agree that it would be nice for projects to not pull big scary libraries sitting on top of your existing system TLS capabilities. My clunky browser Bebop is written in Python and does not use any external libraries, only the standard library `ssl` module which relies on the system's TLS library. It requires a bit more code but it can be done!
There is nothing wrong with diverse TLS implementations. Does it make it harder to compile some Gemini software? Probably but that's entirely unrelated to Gemini. Projects such as LibreSSL have been key actors in pushing OpenSSL to much higher quality levels.
No. YOU are too complicated and against Gemini's principles!
JBanana talks about their struggle to use TLS when writing a client:
> I had to ask on StackOverflow how to open a secure socket with an un-trusted server because the API I was using didn't make that easy. It was pointed out to me on there how insecure this is.
That's valid criticism. TOFU is probably the hardest part to get right in a Gemini client. Why? Because a gigantic part of the TLS ecosystem works with CAs in mind and TOFU is an uncommon beast. Take Android for example. If you want to do network sockets, most of the documentation focuses on using the OkHttp API. What about not using HTTP but simply having a TLS over TCP socket? There is less documentation about it because most people simply do HTTPS. Once you do your research and get it right, next thing is to make your TLS handshake accept self-signed certs and implement TOFU instead. Now you're almost completely on your own, because there aren't many people with this use case. You have to go read Java documentation, painful! Same thing for client certificates, not many people do that on Android.
But once you get it working, you realise that it is not that complicated. Seriously. Also the protocol is young so everyone wants to develop their own clients (myself included) so we all encounter these pain points in our own projects, which kinda amplifies the noise around those difficulties. Even then, the Gemini space has been running for a few years now and there are a lot of already stable clients in many different languages. It means that you have plenty of implementations of open source clients, servers and libraries to take code from. No need to reinvent the wheel!
No. ~pen wrote a great post, bringing most elements of the discussion, and saying mostly what I want to say so I won't repeat it:
Not throwing shade but… on most posts advocating in favor of emphasis support in Gemtext, their own usage of emphasis is completely superfluous and serves no purpose. Or they refrain from using emphasis and it turns out that their post reads just fine without it. It sounds to me like they are merely placing emphasis on words they hear themselves pronouncing slightly louder when reading aloud their text. Their complaint is an inability to break the mechanical habit of using them, rather than a request for an actually missing piece of Gemtext. Sometimes I want to put some emphasis on a word, but quickly I realise it is useless.
Reading large paragraphs without emphasis is a serene experience. If you want to make words and concepts stand out, write an abstract or a tl;dr! Let your visitors do their own reading.
No, it's not a trivial change. Whether or not you want emphasis to be part of the text/gemini spec or done liberally by clients, this implies that clients should start implementing parsers for markers inside a line and it definitely is not easy to get right, whatever you think about it. Parsers have incompatibilities; even CommonMark which is supposed to be a standard Markdown syntax does not solve every incompatibilities between all its implementations. You can see examples of broken Markdown-like emphasis rendering all over the Web — readmes on Github, comments on HackerNews, etc — mostly due to stray asterisks. See nytpu's post for an analysis of its issues, which are problems I definitely do not want to encounter while developing a client:
Formally specified? Gemtext is simple enough to render without weird corner cases. Like Gemini, it's all about the power to weight ratio, and it's unclear whether inline markups are needed enough to bear the complexity of their support. It is often said that it technically is not hard to get right at least 99% of the time, but I don't want to hear about that last percent and I want to see actual merge requests to prove it. The current simplicity of Gemtext makes it hard to generate different levels of rendering support that would create a hierarchy of browsers or rendering engines (“capsule best viewed with XXX!”). Let's keep it that way!
Liberally implemented? This will make some users, new or not as technically inclined as others, think that italics — or bold text, small caps, inline monospaced text, you name it — are part of the Gemini experience and rightfully wonder why it does not work (at all, or differently due to parser inconsistencies) on other browsers. At the very least, it should be an option disabled by default, warning users that it is not part of the Gemtext spec.
Markdown is a fantastic tool and I've been using it almost every day for ~10 years now, but Gemtext is not Markdown. It is not even a stripped-down Markdown, it is a line-based text format with parsing code that can fit inside a single screen, even in low-level languages.
It is currently unclear whether or not supporting streaming responses, i.e. clients rendering a server response as it arrives and not waiting for everything to have been received, should be an important consideration for client (and server!) authors. Streaming responses allow developers to create different kind of applications where a connection can be left open and content received at regular intervals, or even chat rooms. Streaming allows for fun applications, but unless you've been lucky/clever in your code organisation, it is something to consider early in the development process and can be hard to add later. Streaming also allows clients to work properly on extremely slow connections.
I don't mind too much that it is unclear, but it creates two distinct classes of clients somehow, those that support streaming and those that don't. Maybe it's OK though. There is not much demand for streaming anyway, apart from ~tomasino! :D
-- Response ended
-- Page fetched on Thu May 9 08:30:34 2024