A drum I like to beat is that, as the harmful behavior of AdTech companies continues to become public and explicit, there is an explicit opportunity for software practitioners to build less harmful software and organizational patterns around this software. This doesn’t however preclude the idea that software should empower and delight the user who can in many circumstances be non-technical. What ideas like Gemini do by merging these concepts is to frame the idea that user-centric software is harmful and developer-centric software is not, which I want to push back on. Being developer or user-centric is one axis; harmfully mining your information is a tangentially related concern.
I have a different take on the long lines (but with the same conclusion). One line per paragraph essentially means that diffs, and therefore revision control, is unusable. One line per sentence (or perhaps clause, it doesn’t need to be strict) is a convention in areas where people work on text together (such as writing papers in LaTeX) for good reason.
If that’s not a concern, sure, wrapping things to look nice in a text editor as the author wants to do here is reasonable. Which of these two makes the most sense depends on the context. Gemini’s approach is the worst of both worlds and does not make sense in any context. It’s just wrong.
Sounds like our diffing and merge tools are too basic. There is no great reason for line based merge other than it seems to work well enough for code and reduces the computational complexity (mostly in pathological cases).
I much prefer soft wraping because it looks nice whatever the current size of my editor or browser window happens to be.
Fair enough, but what nearly all actually existing tools do seems like a pretty significant consideration for a platform that exists for the sole purpose of being simple…
And of course very few tools support rendering hard-wrapped lines nicely. The options are basically either having a screen that is larger than what the author wrapped to or render as markdown or html.
So it seems like you need to pick between nice viewing and nice merging with the current tools. For me viewing has generally been more important.
Markdown has the same wrapping behavior. And systems that handle text not written by programmers (wikis, blogs, CMSs) tend to assume there will be lines of any length, because nobody but programmers uses hard line breaks anymore.
I’ve seen many tools that display reasonable diffs of single-line paragraphs, for example GitHub. Usually they use color or strike through to indicate the diffs within one paragraph.
Well, it makes git diffs which are output in the default style a nightmare to read and it seems a little unfair to hold Gemini responsible for that. I’m curious, in what sort of workflow would you be reading diffs of gemtext?
It also seems a little unfair to hold HTTP/HTML responsible for advertising or whatever, but here we are :)
I’m curious, in what sort of workflow would you be reading diffs of gemtext?
Software documentation seems the most likely, but indeed: probably not many. My point is really that Gemini’s approach is bad for this and for wrapped text (e.g. at 80 columns). It’s just plain bad.
I was against the use of long lines for paragraphs in the original discussions of it on the Gemini mailing list. The problem is that there were basically two different approaches to handling running text containing newlines on offer, which I will call the Markdown approach and the Gopher approach. The Markdown approach means separating paragraphs by blank lines, and then on the client un-wrapping and re-wrapping paragraphs to the available display area. This is good, but it means more client complexity (more about this in a minute). The Gopher approach is to hard-break lines, and separate paragraphs by blank lines, but then never re-format, which means that if the client is too narrow for 80 character lines, you’ll get even worse ragged edges than the other way around.
Now, it’s not hard at all to unwrap and re-wrap paragraphs, but you need to keep track of the beginning and end of a paragraph and do the wrapping before you display, which means that you can’t parse line-by-line. One easy thing about the gemtext format is that you can always tell how to display a line by looking only at the first three characters. The only state you ever need to keep in your parser is whether you’re inside a literal block or not, but even within a literal block, you can display line-by-line.
Early Gemini sites took the Gopher approach, which meant they were broken on phones. The consensus of the group was that long lines and soft wrapping solved that problem without the complexity of the Markdown approach. I don’t know if this was the right decision or not, but it’s the one that stuck.
One thing I’ll note is that this post deals primarily with “gemtext”, the document format used by most Gemini sites, and expected to be understood by all user-facing Gemini clients; it doesn’t really address the network protocol itself.
The protocol was mostly complete before anyone had decided what kind of documents they were planning on serving with it. I originally argued for a large but strict subset of CommonMark (no inline HTML, inline images only get loaded on user interaction). That probably would have addressed all of gerikson’s issues here. The reason gemtext got spec’ed out, instead, is that almost all existing libraries for handling Markdown were oriented towards generating HTML, not providing a parse tree for displaying yourself, and for basic clients, it was preferred to be able to implement the document format either without a library or with a ubiquitous one.
A lot of the criticism of Gemini (not all of it; I have my own criticisms) comes from people who only see Gemini as in a relationship with the WWW, and a reaction to the excesses of the Web. That’s not really true, though; Gemini also exists in a relationship with Gopher. Almost all of the network protocol design was, for example, based on noting the pain points people in the Gopher community complain about in the Gopher protocol (no TLS, no error signaling).
Gopher has no document/markup format as such. It just sends existing document formats, mostly plain text. There is a plain text format for defining Gopher menus, but it’s not really suitable for documents. It’s line-oriented, and every line is a link type specifying the content type and location of the linked-to document in a tab-separated format, except for the nonstandard ‘i’ type, which represents inline text, or an “info” line. When Gemini was being hashed out, lots of people were abusing the “i” link type in Gophermaps to make a kind of hypertext. The gemtext design simplified and formalized this pattern, basically; it owes as much to the Gophermap format as it does to Markdown. But if you see it only in relation to Markdown, rather in relation to Gophermaps, the choices made in it make a lot less sense.
I remember learning about Gopher before the Web - it was part of our course in “information retrieval” or similar in uni. I’ve written before that I believe what hobbled Gopher was the lack of a ~/public_html feature for random users, and possibly licensing issues. There was never the same feeling of “anyone can publish” with Gopher.
Now of course, domains and VPS’ are cheap as chips, and serving HTML is old hat. I must confess a certain frisson of excitement at seeing my work pop up in a client, similar to when I was writing my first HTML and doing “refresh” in NCSA Mosaic to see the changes.
In any normal project, this would have been seen as a cool feature, but in Gemini it is seen as a harbinger of the adtech apocalypse. The protocol is fixed in stone - for the stated reason that it should be easy for a normally talented developer to code a client over a weekend.
One of the biggest problems with the web as a platform is that it’s intractable for a single developer to build a full-featured novel client for it at all. Web browsers are among the most complicated pieces of software in common use, and this makes it very difficult to fork them even if the code for them is free software. So I am sympathetic to a project making developer friendliness an explicit goal.
But I am inclined to agree with @gerikson that if this emphasis on developer friendliness means that creating a text file for a gemini version of a favicon is controversial, then this principle has gone too far in the direction of denying useful features. I haven’t used gemini very much myself, and that’s in large part because I have the same impression from what I have learned about the protocol that @gerikson does: “ the ecosystem denies them room to grow, to identify the pain points that have been overlooked by the original designers, or to take the project in a new direction.”. The gemini documents linked in this blog post, I read in my web browser via some kind of translation layer.
Of course, in 1993 web browsers were probably simple enough that a developer of average skill could implement one in a short amount of time. The complexity of the modern web evolved in an organic way over more than two decades. I don’t know how to create founding principles for a software project that allows developers to reasonably fix pain points, while preventing something like the intractable complexity of the browser from happening again.
One of the biggest problems with the web as a platform is that it’s intractable for a single developer to build a full-featured novel client for it at all. Web browsers are among the most complicated pieces of software in common use, and this makes it very difficult to fork them even if the code for them is free software. So I am sympathetic to a project making developer friendliness an explicit goal.
Here I think it’s important to decompose the idea of the “web”. The web went through many stages of growth, but initially the Web was a document-distribution platform which used HTTP, an L7 protocol for sending and receiving information, and HTML, markup code for documents on the web. CSS came in shortly after to add styling. Then Javascript was added by Mosaic for page-dynamic content. The early web really wanted to be a web of documents and supported linking to other documents, and the web was meant to be a World Wide Web of interconnected information. Tim Berners-Lee, the creator of the web, had wanted to make it easy to author documents on the web, but for various reasons, this went by the wayside. A lot of the complications of the modern web come from its eventual evolution into an application platform.
One of the benefits of this messy evolution and tall pile of resultant complexity is that older forms of the Web still work flawlessly on browsers today. Had Gemini just decided to distribute a less complex format atop HTTP, a wealth of libraries in millions of devices would have been able to at least fetch its pages. Had Gemini decided to go with a subset of JS, a subset of CSS, and just basic HTML (or more/less restrictive subsets thereof), even current web browsers would be able to display the output, while new browsers could be created to take advantage of Gemini norms. Gemini threw all of this away and implemented a new protocol and a new markup format. While in theory you can distribute anything over the Gemini protocol, most documents are Gemtext with a minority in plain text.
and that’s in large part because I have the same impression from what I have learned about the protocol that @gerikson does: “ the ecosystem denies them room to grow, to identify the pain points that have been overlooked by the original designers, or to take the project in a new direction.”.
I was very excited by Gemini in the beginning and wrote a bunch of stuff on it. But after the fun of writing 3 servers and 3 client libraries wore off, I realized… there wasn’t much to do. As a developer I was done. As a user… I rolled my own static blog site, which I could do trivially on the web. There were some experiments with games and guestbooks but a lot of it was frowned upon. The favicon.txt controversy that @gerikson talked about is another example of the community rejecting extensibility. In other words, the platform just ended up being a static blogging platform with a lot of ceremony around it. I could probably distribute epub files over FTP and get the same effect, and have to write an order of magnitude less code around it, with mature software to fetch files and display my content.
Of course, in 1993 web browsers were probably simple enough that a developer of average skill could implement one in a short amount of time. The complexity of the modern web evolved in an organic way over more than two decades. I don’t know how to create founding principles for a software project that allows developers to reasonably fix pain points, while preventing something like the intractable complexity of the browser from happening again.
If I had to choose, I would bootstrap it atop HTTP at the very least, and possibly over HTML. I think there’s a lot of room to explore here given the messy evolution of the web and I’d hate to have Gemini be the end of this experimentation of finding a sane, developable subset of the web that empowers developers and users.
Had Gemini just decided to distribute a less complex format atop HTTP, a wealth of libraries in millions of devices would have been able to at least fetch its pages. Had Gemini decided to go with a subset of JS, a subset of CSS, and just basic HTML (or more/less restrictive subsets thereof), even current web browsers would be able to display the output, while new browsers could be created to take advantage of Gemini norms. Gemini threw all of this away and implemented a new protocol and a new markup format.
You might be interested to learn that Solderpunk, the founder of the Gemini project, had previously written “Shizaru”, an “opinionated HTTP server” that served a configurable subset of HTML, blacklisted or whitelisted MIME types, and several other configurable restrictions.
Gemini is a community and an experiment. It doesn’t close off the possibility of other experimentation.
I was there in the beginning so I’m aware of “Shizaru” the opinionated server. I’m not completely satisfied with why Shizaru was rejected.
Gemini is a community and an experiment. It doesn’t close off the possibility of other experimentation.
The messaging of Gemini really frustrates me. The main Gemlog page (apologies for linking to the web here) cites Gemini as “a new internet protocol”. None of the founding documents say that Gemini is a community. Is FTP a community? Is SMTP a community? SCTP? There’s a mismatch between the messaging of the Gemini protocol itself and the thoughts of Gemini users as a whole. I don’t send emails over SMTP in order to join the “SMTP club”, so I think it’s a bit disingenuous for Gemini to be a community and a protocol. Protocols are about allowing disparate agents to communicate over the protocol; protocols are a common language between otherwise non-aligned agents. I can send and receive SMTP and use it for sending status reports about cron jobs, communicating with friends, or reaching out to a business I am buying something from. I can do the same with FTP or SCTP. Gemini users seem to be saying that Gemini isn’t like this, in which case Gemini isn’t really a protocol. Reddit and Lobsters don’t call themselves protocols either.
This is important because protocols are all about bringing disparate agents together. This can be machine agents, this can be human agents, this can be people who are using dramatically different platforms on dramatically different devices. Protocols bridge agents with very different outlooks on the world. Importantly, protocols encourage different ways to use them, as long as the specification of the protocol is adhered to, at times leading to evolution and experimentation. A community, like a subreddit, is a very different concept, and much more narrowly scoped. My D&D group is a community of sorts, but it certainly isn’t a protocol. Gemini advertises itself as a protocol, which makes it seem more inclusive and free-form than in practice it ends up being, and is a form of “slippery messaging” that I’m not a fan of.
You’re probably right and I should go back to other things. FWIW I don’t mean to direct these questions/criticisms to you as much as to explain my thought process, so apologies if I made it seem that way.
I have only recently found out about Gemini from postings here and a few other sites. I’ve been around the internet long enough to remember gopher so the nostalgia is definitely there for me. After reading this article though the developer/geek in me wants to learn more, but the end user in me leaves me questioning as to why?
I’ll undoubtedly deploy a gemini site at some point, but beyond privacy benefits and a seemingly more lightweight protocol I haven’t come to the conclusion of why yet.
I wonder if it would not have made sense to go after these goals by kind of creating a standard that is a subset of HTTP (1 or 1.1), maybe do some signaling using a header or some MIME type telling browsers or extensions of browsers to apply strict rules, maybe change how and what things are rendered. That way it would still remain compatible with a lot of software already built to interact with HTTP, and switching back and forth between protocols might be easier from a users perspective.
You don’t even have to make anything up. HTML 2.0 is an already existing spec that solves all the problems of Gemini in a much more useful way and still includes stuff like unicode support. The entire purpose of Gemini is to be exclusive and cliquish; if you read the original rationale post I think this is pretty clear.
Well, it depends on what you mean by “soft-wrapping”.
Markdown, like HTML and LaTeX, treats paragraphs as a logical unit.
I use Emacs, and in my setup, lines are wrapped at the edge of the frame (regardless of whether it’s a word boundary):
Here's a long li\
ne that is wrapp\
ed.
I find that quite distracting to read, so I habitually hit M-q to justify paragraphs. When the source is translated to HTML, it’s all wrapped in a <p> tag anyway.
When I looked at this I found that Emacs can soft-wrap at word boundaries, so that’s one possible solution. The problem is to deal with the 782 blog entries I’ve already written, mostly in Markdown, were I to move them to gemtext.
Of course there’s a technical solution, as mentioned in the post, which can take Markdown and produce gemtext. But it’s not really to my liking, because it treats links in a way I don’t agree with.
I should probably not have given so much weight to the line-length issue, it’s by far the least objectionable quirk of gemtext. But I was struck on how much extra work I had to do to transfer my first relative long-form blog post to Gemini, and it stuck with me.
A drum I like to beat is that, as the harmful behavior of AdTech companies continues to become public and explicit, there is an explicit opportunity for software practitioners to build less harmful software and organizational patterns around this software. This doesn’t however preclude the idea that software should empower and delight the user who can in many circumstances be non-technical. What ideas like Gemini do by merging these concepts is to frame the idea that user-centric software is harmful and developer-centric software is not, which I want to push back on. Being developer or user-centric is one axis; harmfully mining your information is a tangentially related concern.
I have a different take on the long lines (but with the same conclusion). One line per paragraph essentially means that diffs, and therefore revision control, is unusable. One line per sentence (or perhaps clause, it doesn’t need to be strict) is a convention in areas where people work on text together (such as writing papers in LaTeX) for good reason.
If that’s not a concern, sure, wrapping things to look nice in a text editor as the author wants to do here is reasonable. Which of these two makes the most sense depends on the context. Gemini’s approach is the worst of both worlds and does not make sense in any context. It’s just wrong.
Sounds like our diffing and merge tools are too basic. There is no great reason for line based merge other than it seems to work well enough for code and reduces the computational complexity (mostly in pathological cases).
I much prefer soft wraping because it looks nice whatever the current size of my editor or browser window happens to be.
Fair enough, but what nearly all actually existing tools do seems like a pretty significant consideration for a platform that exists for the sole purpose of being simple…
Well git diff supports word diffs by default.
And of course very few tools support rendering hard-wrapped lines nicely. The options are basically either having a screen that is larger than what the author wrapped to or render as markdown or html.
So it seems like you need to pick between nice viewing and nice merging with the current tools. For me viewing has generally been more important.
Is your issue that two people editing one paragraph will always be a merge conflict, specifically?
Yeah, that’s the big one. Although it also makes diffs a nightmare to read in general.
Markdown has the same wrapping behavior. And systems that handle text not written by programmers (wikis, blogs, CMSs) tend to assume there will be lines of any length, because nobody but programmers uses hard line breaks anymore.
I’ve seen many tools that display reasonable diffs of single-line paragraphs, for example GitHub. Usually they use color or strike through to indicate the diffs within one paragraph.
Well, it makes git diffs which are output in the default style a nightmare to read and it seems a little unfair to hold Gemini responsible for that. I’m curious, in what sort of workflow would you be reading diffs of gemtext?
It also seems a little unfair to hold HTTP/HTML responsible for advertising or whatever, but here we are :)
Software documentation seems the most likely, but indeed: probably not many. My point is really that Gemini’s approach is bad for this and for wrapped text (e.g. at 80 columns). It’s just plain bad.
I was against the use of long lines for paragraphs in the original discussions of it on the Gemini mailing list. The problem is that there were basically two different approaches to handling running text containing newlines on offer, which I will call the Markdown approach and the Gopher approach. The Markdown approach means separating paragraphs by blank lines, and then on the client un-wrapping and re-wrapping paragraphs to the available display area. This is good, but it means more client complexity (more about this in a minute). The Gopher approach is to hard-break lines, and separate paragraphs by blank lines, but then never re-format, which means that if the client is too narrow for 80 character lines, you’ll get even worse ragged edges than the other way around.
Now, it’s not hard at all to unwrap and re-wrap paragraphs, but you need to keep track of the beginning and end of a paragraph and do the wrapping before you display, which means that you can’t parse line-by-line. One easy thing about the gemtext format is that you can always tell how to display a line by looking only at the first three characters. The only state you ever need to keep in your parser is whether you’re inside a literal block or not, but even within a literal block, you can display line-by-line.
Early Gemini sites took the Gopher approach, which meant they were broken on phones. The consensus of the group was that long lines and soft wrapping solved that problem without the complexity of the Markdown approach. I don’t know if this was the right decision or not, but it’s the one that stuck.
One thing I’ll note is that this post deals primarily with “gemtext”, the document format used by most Gemini sites, and expected to be understood by all user-facing Gemini clients; it doesn’t really address the network protocol itself.
The protocol was mostly complete before anyone had decided what kind of documents they were planning on serving with it. I originally argued for a large but strict subset of CommonMark (no inline HTML, inline images only get loaded on user interaction). That probably would have addressed all of gerikson’s issues here. The reason gemtext got spec’ed out, instead, is that almost all existing libraries for handling Markdown were oriented towards generating HTML, not providing a parse tree for displaying yourself, and for basic clients, it was preferred to be able to implement the document format either without a library or with a ubiquitous one.
A lot of the criticism of Gemini (not all of it; I have my own criticisms) comes from people who only see Gemini as in a relationship with the WWW, and a reaction to the excesses of the Web. That’s not really true, though; Gemini also exists in a relationship with Gopher. Almost all of the network protocol design was, for example, based on noting the pain points people in the Gopher community complain about in the Gopher protocol (no TLS, no error signaling).
Gopher has no document/markup format as such. It just sends existing document formats, mostly plain text. There is a plain text format for defining Gopher menus, but it’s not really suitable for documents. It’s line-oriented, and every line is a link type specifying the content type and location of the linked-to document in a tab-separated format, except for the nonstandard ‘i’ type, which represents inline text, or an “info” line. When Gemini was being hashed out, lots of people were abusing the “i” link type in Gophermaps to make a kind of hypertext. The gemtext design simplified and formalized this pattern, basically; it owes as much to the Gophermap format as it does to Markdown. But if you see it only in relation to Markdown, rather in relation to Gophermaps, the choices made in it make a lot less sense.
Thanks a lot for this thoughtful reply.
I remember learning about Gopher before the Web - it was part of our course in “information retrieval” or similar in uni. I’ve written before that I believe what hobbled Gopher was the lack of a
~/public_htmlfeature for random users, and possibly licensing issues. There was never the same feeling of “anyone can publish” with Gopher.Now of course, domains and VPS’ are cheap as chips, and serving HTML is old hat. I must confess a certain frisson of excitement at seeing my work pop up in a client, similar to when I was writing my first HTML and doing “refresh” in NCSA Mosaic to see the changes.
One of the biggest problems with the web as a platform is that it’s intractable for a single developer to build a full-featured novel client for it at all. Web browsers are among the most complicated pieces of software in common use, and this makes it very difficult to fork them even if the code for them is free software. So I am sympathetic to a project making developer friendliness an explicit goal.
But I am inclined to agree with @gerikson that if this emphasis on developer friendliness means that creating a text file for a gemini version of a favicon is controversial, then this principle has gone too far in the direction of denying useful features. I haven’t used gemini very much myself, and that’s in large part because I have the same impression from what I have learned about the protocol that @gerikson does: “ the ecosystem denies them room to grow, to identify the pain points that have been overlooked by the original designers, or to take the project in a new direction.”. The gemini documents linked in this blog post, I read in my web browser via some kind of translation layer.
Of course, in 1993 web browsers were probably simple enough that a developer of average skill could implement one in a short amount of time. The complexity of the modern web evolved in an organic way over more than two decades. I don’t know how to create founding principles for a software project that allows developers to reasonably fix pain points, while preventing something like the intractable complexity of the browser from happening again.
Here I think it’s important to decompose the idea of the “web”. The web went through many stages of growth, but initially the Web was a document-distribution platform which used HTTP, an L7 protocol for sending and receiving information, and HTML, markup code for documents on the web. CSS came in shortly after to add styling. Then Javascript was added by Mosaic for page-dynamic content. The early web really wanted to be a web of documents and supported linking to other documents, and the web was meant to be a World Wide Web of interconnected information. Tim Berners-Lee, the creator of the web, had wanted to make it easy to author documents on the web, but for various reasons, this went by the wayside. A lot of the complications of the modern web come from its eventual evolution into an application platform.
One of the benefits of this messy evolution and tall pile of resultant complexity is that older forms of the Web still work flawlessly on browsers today. Had Gemini just decided to distribute a less complex format atop HTTP, a wealth of libraries in millions of devices would have been able to at least fetch its pages. Had Gemini decided to go with a subset of JS, a subset of CSS, and just basic HTML (or more/less restrictive subsets thereof), even current web browsers would be able to display the output, while new browsers could be created to take advantage of Gemini norms. Gemini threw all of this away and implemented a new protocol and a new markup format. While in theory you can distribute anything over the Gemini protocol, most documents are Gemtext with a minority in plain text.
I was very excited by Gemini in the beginning and wrote a bunch of stuff on it. But after the fun of writing 3 servers and 3 client libraries wore off, I realized… there wasn’t much to do. As a developer I was done. As a user… I rolled my own static blog site, which I could do trivially on the web. There were some experiments with games and guestbooks but a lot of it was frowned upon. The favicon.txt controversy that @gerikson talked about is another example of the community rejecting extensibility. In other words, the platform just ended up being a static blogging platform with a lot of ceremony around it. I could probably distribute epub files over FTP and get the same effect, and have to write an order of magnitude less code around it, with mature software to fetch files and display my content.
If I had to choose, I would bootstrap it atop HTTP at the very least, and possibly over HTML. I think there’s a lot of room to explore here given the messy evolution of the web and I’d hate to have Gemini be the end of this experimentation of finding a sane, developable subset of the web that empowers developers and users.
You might be interested to learn that Solderpunk, the founder of the Gemini project, had previously written “Shizaru”, an “opinionated HTTP server” that served a configurable subset of HTML, blacklisted or whitelisted MIME types, and several other configurable restrictions.
Gemini is a community and an experiment. It doesn’t close off the possibility of other experimentation.
I was there in the beginning so I’m aware of “Shizaru” the opinionated server. I’m not completely satisfied with why Shizaru was rejected.
The messaging of Gemini really frustrates me. The main Gemlog page (apologies for linking to the web here) cites Gemini as “a new internet protocol”. None of the founding documents say that Gemini is a community. Is FTP a community? Is SMTP a community? SCTP? There’s a mismatch between the messaging of the Gemini protocol itself and the thoughts of Gemini users as a whole. I don’t send emails over SMTP in order to join the “SMTP club”, so I think it’s a bit disingenuous for Gemini to be a community and a protocol. Protocols are about allowing disparate agents to communicate over the protocol; protocols are a common language between otherwise non-aligned agents. I can send and receive SMTP and use it for sending status reports about cron jobs, communicating with friends, or reaching out to a business I am buying something from. I can do the same with FTP or SCTP. Gemini users seem to be saying that Gemini isn’t like this, in which case Gemini isn’t really a protocol. Reddit and Lobsters don’t call themselves protocols either.
This is important because protocols are all about bringing disparate agents together. This can be machine agents, this can be human agents, this can be people who are using dramatically different platforms on dramatically different devices. Protocols bridge agents with very different outlooks on the world. Importantly, protocols encourage different ways to use them, as long as the specification of the protocol is adhered to, at times leading to evolution and experimentation. A community, like a subreddit, is a very different concept, and much more narrowly scoped. My D&D group is a community of sorts, but it certainly isn’t a protocol. Gemini advertises itself as a protocol, which makes it seem more inclusive and free-form than in practice it ends up being, and is a form of “slippery messaging” that I’m not a fan of.
I feel you are reading far too much into my offhand comment.
You’re probably right and I should go back to other things. FWIW I don’t mean to direct these questions/criticisms to you as much as to explain my thought process, so apologies if I made it seem that way.
I have only recently found out about Gemini from postings here and a few other sites. I’ve been around the internet long enough to remember gopher so the nostalgia is definitely there for me. After reading this article though the developer/geek in me wants to learn more, but the end user in me leaves me questioning as to why?
I’ll undoubtedly deploy a gemini site at some point, but beyond privacy benefits and a seemingly more lightweight protocol I haven’t come to the conclusion of why yet.
I wonder if it would not have made sense to go after these goals by kind of creating a standard that is a subset of HTTP (1 or 1.1), maybe do some signaling using a header or some MIME type telling browsers or extensions of browsers to apply strict rules, maybe change how and what things are rendered. That way it would still remain compatible with a lot of software already built to interact with HTTP, and switching back and forth between protocols might be easier from a users perspective.
You don’t even have to make anything up. HTML 2.0 is an already existing spec that solves all the problems of Gemini in a much more useful way and still includes stuff like unicode support. The entire purpose of Gemini is to be exclusive and cliquish; if you read the original rationale post I think this is pretty clear.
Just like Markdown, and every word processor ever.
I read this as “so if you’re still typing as though it’s 1980 and haven’t discovered soft-wrapping…”
Well, it depends on what you mean by “soft-wrapping”.
Markdown, like HTML and LaTeX, treats paragraphs as a logical unit.
I use Emacs, and in my setup, lines are wrapped at the edge of the frame (regardless of whether it’s a word boundary):
I find that quite distracting to read, so I habitually hit
M-qto justify paragraphs. When the source is translated to HTML, it’s all wrapped in a<p>tag anyway.When I looked at this I found that Emacs can soft-wrap at word boundaries, so that’s one possible solution. The problem is to deal with the 782 blog entries I’ve already written, mostly in Markdown, were I to move them to gemtext.
Of course there’s a technical solution, as mentioned in the post, which can take Markdown and produce gemtext. But it’s not really to my liking, because it treats links in a way I don’t agree with.
I should probably not have given so much weight to the line-length issue, it’s by far the least objectionable quirk of gemtext. But I was struck on how much extra work I had to do to transfer my first relative long-form blog post to Gemini, and it stuck with me.