Thoughts on Gemtext
This document is a summary of Gemtext雜感.
Protocol and Markup Language
First, we should clarify that the Gemini protocol and the Gemtext markup language are not the same thing. Certainly, the Gemtext document is Gemini's native response format, closely related to the protocol and its users. However, users are not required to deliver Gemtext documents, and can publish documents in other formats (e.g., HTML).
On the other hand, since most of the content that can be consulted with the Gemini protocol is Gemtext documents, it is inevitable that the quality of the content will be affected. Therefore, the two evaluations are very easily confused.
I am not familiar with either protocol or markup language, but as an HTML document author, here are my intuitive impressions of the Gemtext language/document.
After viewing some Gemtext documents
- ASCII art too much
- Take up a lot of space
- Must skip to the text.
- It slows down the reading.
- Some fonts are corrupted and meaningless (environment-dependent expressions)
- Cannot be hidden
- No alternative text
- I don't deny the artistic expression of characters. However, it is bothersome (in some cases, it is a clear barrier) for users who simply want to read textual information. Even if visual representations are acceptable, they cannot be received reliably (depending on font, letter spacing, and line spacing). Images and style sheets are better, because they can be disabled (if the user agent supports them). In addition, there is an alternative text, or the text can be referenced as is.
- The specification only defines the type of font. Users may adjust letter spacing and line spacing (especially for reading code).
- From 5.4.4 Preformatted text lines in the Speculative specification:
Preformatted text lines should be presented to the user in a "neutral", monowidth font without any alteration to whitespace or stylistic enhancements.
- If the placed ASCII art is meaningless (in HTML, an empty
alt attribute value, that is, an expression whose absence does not interfere with referencing), then it is a decoration. Appearance control.
- When there is no visual information, it is difficult to judge whether the preformatted text is a code or an artistic/decorative expression (even if the context can be used to judge). The fatal problem is that important information is replaced by ASCII art. For example, if the author's name, contact information, and headline are only represented in ASCII art, it will be difficult for the user to find the information.
- Information that users need (such as document titles and headings) should simply be text.
- Authors should be aware that they run the risk of their ASCII art becoming a series of unintelligible symbols.
- Project Gemini stipulates that it is up to the client/user to decide how to render the document,
but makes no mention of accessibility or alternative representations for ASCII art or preformatted text.
- Alternative representations for preformatted text: Authors are not required to use alternate text. Clients are also not required to render alternative text. From 5.4.3 Preformatting toggle lines in the Speculative specification:
Any text following the leading "```" of a preformat toggle line which toggles preformatted mode on MAY be interpreted by the client as "alt text" pertaining to the preformatted text lines which follow the toggle line. Use of alt text is at the client's discretion, and simple clients may ignore it. Alt text is recommended for ASCII art or similar non-textual content which, for example, cannot be meaningfully understood when rendered through a screen reader or usefully indexed by a search engine. Alt text may also be used for computer source code to identify the programming language which advanced clients may use for syntax highlighting.
- Even if it were mandated, it would not be possible to enforce the setting of alternate text (unless it is treated as an error) as long as there are people who mark up the text manually.
- Why should I see ASCII art instead of images?
- Japanese ASCII art is not always represented in monospace fonts. It is quite possible that it may appear on a text line. In this case, there is no workaround.
- If an image is an appropriate complement to the document, then an image should be chosen. Just link to them.
- Emoji
- Emoticon
- Decorative symbols
- Navigation (back to home page link, etc.), signature, license missing/existing
- Like HTML, needs to be added manually
- Cannot add meta information to content. I want to use at least the following information:
- Title
- Release Date
- Revision Date
- Signature (creator, copyright holder)
- Publisher's contact information
- License
- In HTML,
title element, meta element, address element
- Cannot provide the relationship between contents. (In HTML,
link element, rel attribute)
- With only 3 heading levels, the Gemtext language is intended for simple, short documents.
- No matter how simplified the standards and specifications are, if the authors do not have the awareness of separating the document from the decoration, an accessible document cannot be created. How many authors have considered access from screen readers?
- The author cannot have a style sheet - that's the expectation, there is no decoration at all in the document. Therefore, authors need to be careful not to destroy the information (although it is fine to just write the document as usual).
- The specification contains no warnings or guidelines for accessibility.
- No solutions, alternatives, or directions are provided for expressions that reduce accessibility.
- It can be compared to the HTML 4.01 specification. HTML can easily break accessibility because of the author's freedom, but it can also be structured with care, and the notes in each chapter include practical advice.
- From the author's point of view: what content is there to distribute that gives up meta-information, clarification of relationships, and accessibility?
- Simplifying the markup language weakens the document (less information, lower accessibility/usability).
- Why specifications do not operate as targeted: human error
- Even if there is a specification for structuring documents, the problem is that humans cannot write structured documents. Therefore, the only way is to educate them or force them to do so. The specification undertakes the latter. The former is a human (social) problem, and is the part that humans are least willing to take on.
- For example, the HTML specification gives authors a certain amount of attention by explaining which elements and attributes are (un)recommended and why and in what situations.
- It is irresponsible to rely on the authors' (users') autonomy. Humans are always smarter or dumber than the specification. The specification designer should indicate the desired behavior to the user.
- The designer's responsibility is even greater if it is a native response format. This affects the quality of the distributed content. Therefore, Gemtext tends to be equated with the evaluation of the protocol itself. Also, those who are dissatisfied with the distributed content will try to control the quality of the content by revising the Gemtext specification.
- The FAQ begins like this:
Gemini is a new application-level internet protocol for the distribution of arbitrary files, with some special consideration for serving a lightweight hypertext format which facilitates linking between files.
Gemini exists to deliver documents that are formatted plain text, or, to put it crudely, something better than plain text. If you want to make your documents accessible, you should use HTML.
- Given the low accessibility of Gemtext, it is not surprising that useful resources are not moving into Gemini!
- Simply put, the Gemtext language is inferior to HTML in the amount of information it can accommodate.
- Authors who want to give screen reader users the same information as visual representations will choose HTML (for example, emphasis at the inline level will be read with a strong accent).
- Authors who want to provide meta-information (such as contact information, licenses, etc.) in their documents will also choose HTML (the Gemtext language includes links, but does not imply a relationship with the document).
- Distribution in a lightweight hypertext language is not futile, but it is too functionally poor. I would like to see the document provided in HTML if it is of universal value. Because inline marks, meta-information, and so on can be used in many environments. If the HTML Living Standard is bloated, then HTML 4.01 or ISO-HTML is fine. If you want to advertise in Gemini, just link to it. Perhaps the coexistence of HTTP and Gemini will work that way. People will get local (subject-specific) information in a safe place and find meaningful HTTP content.
- If I were to join the Geminispace, I would provide HTML documents. This is because the documents I write are suitable for HTML (emphasis at the inline level, aiming for universal access, desire to provide meta-information, etc.).
- Balance. Specification Summary: Clients who can write in a weekend's time can only handle simple text. As a result, I would not choose Geminispace if I had to endure continuous blank lines, ASCII art, symbol-decorated headings, and other document forms that are not suitable for Gemtext. It goes without saying that a well-structured document is easier to read. Even in Geminispace, I need a content fitter.
- The difference between Gemtext and HTML is mainly semantics - as mentioned above, the amount of information that can be accommodated. Such as the
rel attribute to indicate the relationship between documents, the cite attribute to indicate the URI of the quotation source, etc. Gemtext does not allow for the association of information to each line (it does not provide semantics).
- Therefore, the automatic conversion to HTML that hosting services sometimes provide is significant in that it can be browsed from the Web, but it does not increase the amount of information in the document itself.
- It may be less burdensome to parse a single line with a single function, but only humans have that (semantic) readability.
- The client can recognize the quotation, but cannot detect or get the source of the quotation.
- Even the writing of signatures and licenses is not standardized - it depends on the author's style. If we have a standardized format, both humans and machines can easily see where things are. This will improve accessibility/usability.
- Aggregators and search engines will also find it easier to process. For example, a uniform license format would make it easier to search for content under a particular license.
- Others found Gemtext unsightly:
- Stepping away from Gemini - Drew DeVault's geminispace:
I like to read medium- to long-form technical content. All of my favorite authors for this post only on HTTP
- Clearly, medium- to long-form technical documents are not suitable for Gemtext.
- 2022-05-02: The specification designer cannot guarantee the quality of distributed content. They can only guarantee the distribution of content.
- Quality is a human (social) issue. Just as good content exists on the Web, bad content exists in Gemini. Quality is the responsibility of each person involved with the content.
- Therefore, what I can expect is a well-organized document written by me. Provide content that is suitable for the format.
- Selecting the right format for the content.
Halfway separation of document and appearance
- My concern stems from what happened in the early days of the Web, and what still happens on bulletin boards (in the form of plain text postings). Consecutive line breaks, letter spacing via whitespace, symbol rulings, and ASCII art. These cannot be eliminated even with style sheets (if the line break is caused by the
br element, it can be fixed).
- This indeed happens with HTML, but most website authors know HTML and CSS (a means of controlling appearance) and manage to separate documentation and decoration. The only sites that still use symbols and ASCII art are those that only allow plain text posting (bulletin boards and social networking sites), or authors with limited knowledge of CSS. In short, proper (text-only) information is achieved by having a place for authors to vent their egos. Readers can disable the author's style sheet and avoid the ego.
- Gemtext has no means of decoration. This is because it practices separation of document and appearance. The problem is that some authors either do not understand that principle or resist it. They try to improve accessibility/usability for the author/reader by decorating the document themselves. We can say we'll trust the client to do this. But until clients with a high degree of control over appearance come into vogue, authors will not change their tune. Just as the Web once was.
- The author doing the decorating may have accessibility/usability barriers (difficulty reading) in referring to the Gemtext document. Considering that the author is the assured reader of the document, it is natural to try to alleviate the barrier.
- ASCII art is not acceptable. This is because, unlike images, it is not a data format that machines can process. It cannot be reliably ignored (extracted), replaced with an alternative representation, or linked.
- ASCII art is not a logical presentation. Unless the purpose of ASCII art is to showcase ASCII art, all ASCII art can be missing and not interfere with document reference. If not, it is because it is being used as a substitute for some data format (especially text and images).
- Why should the title of a document be represented by ASCII art? There is no necessity. Unless it can be processed as data, ASCII art is a definite barrier to the user.
- Since it is not a data format, it cannot be eliminated by the specification. Existence depends on the author's judgment.
Blank Lines
Paragraph, section, and topic separators are logical document structures, but text lines and blank lines have no such meaning in the specification.
- A blank line is an ornamental expression when taken to an excessive degree. I hope you understand how inconvenient a meaningless blank line (space) is.
- I do not know how it is in English-speaking countries, but in Japan, there are a certain number of authors who use excessive line breaks to express pauses. This is a form of procrastination of reference, as mentioned in 變らない人々、變らないWeb, and it prevents the user from accessing information. Scene changes and chapter breaks should be indicated as part of the structure of the document, and authors should not control headings and chapter margins.
- Headings and body text indicate document structure (sections), and authors do not need blank lines.
- In HTML, blank lines in the source do not affect the appearance, but they do in Gemtext.
- If document structure and appearance are separated, what is consecutive blank lines? Does document structure exist there? Why shouldn't the client collapse consecutive meaningless blank lines? The specification doesn't explain why; are you saying that authors who break 10 or 50 lines don't exist (there is a precedent in HTTP/HTML, and I'm afraid it's possible in Gemtext documents!).
- From 5.4.1 Text lines in the Speculative specification:
Consecutive blank lines should NOT be collapsed into fewer blank lines.
- No limit on the number of lines. A compliant client will render blank lines whether 100 or 1,000 lines. No consideration of author or editor errors.
- Why can authors control line spacing?
Whitespace characters
The specification does not say anything about the handling of whitespace characters on lines other than preformatted text.
- What is the justification for rendering consecutive whitespace characters, other than to reproduce the grammar of the language?
- If the grammar consists of only a single whitespace character, then two or more whitespace characters should be combined into one.
- If document structure and appearance are separated, what is consecutive whitespace characters?
- If the rendering of consecutive whitespace characters is tolerated, the author may use whitespace characters to adjust margins and letter spacing.
- How are tab characters handled?
- If the client renders consecutive whitespace characters, the entire document can be said to be preformatted text. Similar to blank lines, appearance control using consecutive whitespace characters occurs in HTTP/HTML and is also possible in Gemtext documents.
- In HTML, single-byte whitespace characters do not affect the appearance, but they do in Gemtext.
- In HTML, double-byte whitespace characters affect appearance, and some authors in Japan use this to control appearance.
- No limit on the number of characters. A compliant client will render whitespace whether it is 100 or 1,000 characters. No consideration of author or editor errors.
Significance of In-Line Marks
- Gemtext does not have any inline level marks.
- From 2.10 Why doesn't text/gemini have support for in-line links? in the Project Gemini FAQ:
Because text/gemini is an entirely new format defined from scratch for Gemini, client authors will typically need to write their own code to parse and render the format from scratch, without being able to rely on a pre-existing, well-tested library implementation. Therefore, it is important that the format is extremely simple to handle correctly. The line-based format where text lines and link lines are separate concepts achieves this. There is no need for clients to scan each line character-by-character, testing for the presence of some special link syntax. Even the simplest special link syntax introduces the possibility of malformed syntax which clients would need to be robust against, and has edge cases whose handling would either need to be explicitly addressed in the protocol specification (leading to a longer, more tedious specification which was less fun to read and harder to hold in your head), or left undefined (leading to inconsistent behaviour across different clients). Even though in-line links may be a more natural fit for some kinds of content, they're just not worth the increased complexity and fragility they would inevitably introduce to the protocol.
- From 5.1 Overview in the Speculative specification:
The format permits richer typographic possibilities than the plain text of Gopher, but remains extremely easy to parse. The format is line-oriented, and a satisfactory rendering can be achieved with a single pass of a document, processing each line independently.
- The value of the inline mark is to improve accessibility.
- Authors cannot make their warning notice stand out. Search engines (e.g., geminispace.info) cannot even highlight search terms. Therefore, people use spaces, symbols, and emoji to attract the reader's attention. As already mentioned, decorative expressions affect accessibility. This ad hoc substitution can occur, in part, through carelessness on the part of the author, but also because the markup language lacks the necessary markings.
- The significance of the mark is not only that it gives meaning, but also that the format (means of providing information) can be standardized.
- Information can be provided regardless of language, culture, writing style, or access environment. (Universal access!)
- What is the rationale for providing block-level quotations but not inline-level quotations?
- The absence of inline markings makes parsing easier for the client (and development easier itself). In other words, the client developer's convenience takes precedence. While developer/user autonomy is respected, is the impact on the quality of distributed content justified?
- Is being able to create a client in a weekend's time a benefit worth the low amount of information/accessibility?
- Text surrounded by asterisks is not always emphasis. Text enclosed in quotation marks is not always a quote. Markup language serves as a common marker to communicate information to people. The marks that Gemtext leaves out are too everyday, too substantial, too utilitarian.
Appendix: Notes on Protocol
- Opinion that Gemini has no commercial value and can be community-driven (by keeping the implementation simple): Gemini is Useless - Alex's space
- It is possible to insert advertisements (text, links, ASCII art).
- Opinion that TLS mandates do not consider hidden services: kill-9 - harmful - software - gemini
- The significance of implementing a protocol rather than a service or markup language is to ensure that the content is secure and simple.
- From 2.5 Why not just use a subset of HTTP and HTML? in the Project Gemini FAQ:
The problem is that deciding upon a strictly limited subset of HTTP and HTML, slapping a label on it and calling it a day would do almost nothing to create a clearly demarcated space where people can go to consume *only* that kind of content in *only* that kind of way. It's impossible to know in advance whether what's on the other side of a https:// URL will be within the subset or outside it. It's very tedious to verify that a website claiming to use only the subset actually does, as many of the features we want to avoid are invisible (but not harmless!) to the user. It's difficult or even impossible to deactivate support for all the unwanted features in mainstream browsers, so if somebody breaks the rules you'll pay the consequences. Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch. Even if you did it, you'd have a very difficult time discovering the minuscule fraction of websites it could render.
- 2022-05-01: This is only to say that the referenced document is secure, because the reader cannot know (or limit) whether the hyperlinks in the document are HTTP(S) (non-Gemini protocol) or Gemini. Since the Web has far more resources, it is highly likely that HTTP will be cited as a complement to the document, and indeed, if it contains useful information, the reader will have no choice but to use an external protocol.
- There is a contradiction, or perhaps an unconscious expectation, that makes me feel uncomfortable. People who are oriented toward the benefits of Gemini (non-complex space, lightweight text) expect interlinking of Gemtext documents via the Gemini protocol, even though the URI of the hyperlink and the format in which it is sent and received are free.
- HTTP expects HTML over HTTP, but most readers don't really care what protocol/format as long as the content is formatted for readability (i.e., the user agent can handle the protocol and the content is in a human-friendly format).
- Authors need (desire) to supplement their documents appropriately. Restricting (pressuring) protocols and formats, even though the specification allows for it, can lead to censorship.
- For example, I think that links to PDFs and compressed formats require consideration, but I don't want to put that kind of consideration into the document. In short, I am worried that the client's process will stumble.
- It is desirable for the client to detect and control external protocols. Some clients have already implemented such functionality, but according to the specification, this behavior is not mandatory. Cross-protocol handling is only mentioned in a separate document (the specification does not mention it, nor link to it).
- From Cross-protocol redirects in the Best practices for Gemini implementations:
Cross-protocol redirects (i.e. redirects from Gemini to something else, like Gopher) are possible within Gemini, but are very heavily discouraged. However, misconfigured or malicious servers will always be able to serve such redirects, so well-written clients should be ready to detect them and respond accordingly.
- Because of the specific aim of the technology, readers are frustrated that they cannot limit hyperlinks to internal ones. As well as the darknet.
- Content does not return blank pages, replace content, or test whether the user is a human (e.g., Captcha).
- 2022-05-01: Low Power Computing
- Markup documents with poor content (in terms of information content and accessibility) in widespread use
- HTML documents can also be distributed, but the client may not support it.
- Although the darknet is highly anonymous, it does not change the fact that most websites are composed with HTML and CSS and require a user agent that complies to complex specifications.
- As noted in 變らない人々、變らないWeb, site creators on the darknet (who even respect privacy) are not always familiar with and sensitive to accessibility/usability and HTML.
Appendix: Services already in existence (as of 2022-05-14)
- HTTP/Gemini Proxy
- Hosting
- Submission Platform
- Search engines (link collection)
- Aggregators (feed delivery)
- Comments
- Like button
- Bulletin boards
- SNS
- Micro-logging
- Ring (link system)
Afterword
- I can only think of a (very local) light-weight diary as a use. But I prefer a micro web diary (a diary of thoughts in an ordered list):
- Is it suitable for people who are not familiar with markup languages or who have hassle with markup?
- I can't say for sure until there are more Japanese-language documents. I wonder if there are people who write regularly.
- I could relate to the idea, but I didn't have the necessary marks. I can't write a sentence without emphasis. Even novels have emphasis.
- My reasonable answer is to write in HTML. Rather than imitating HTML badly, mature, proven, universal-access oriented HTML itself is a safer way to provide documents.
- If everyone involved in the Geminispace does not think about accessibility, the quality of the distributed content will not be maintained. Especially since ASCII art used as a substitute for images is a detriment and will cause hell for those who have come for purely text. Project Gemini is sidelined by the current situation and feels very experimental and merciless. The reader is as helpless as ever. We have to wait for the specification or the client to get smarter (humans don't get smarter). A certain level of complexity is an investment in the user. At some point, the client will have to become complex for the sake of comfort (e.g., ignoring ASCII art, emojis, symbols in headings, etc.).
- From 2.5 Why not just use a subset of HTTP and HTML? in the Project Gemini FAQ:
Alternative, simple-by-design protocols like Gopher and Gemini create alternative, simple-by-design spaces with obvious boundaries and hard restrictions. You know for sure when you enter Geminispace, and you can know for sure and in advance when following a certain link will cause you leave it. While you're there, you know for sure and in advance that everybody else there is playing by the same rules. You can relax and get on with your browsing, and follow links to sites you've never heard of before, which just popped up yesterday, and be confident that they won't try to track you or serve you garbage because they *can't*. You can do all this with a client you wrote yourself, so you *know* you can trust it. It's a very different, much more liberating and much more empowering experience than trying to carve out a tiny, invisible sub-sub-sub-sub-space of the web.
- No, I'm protesting because I'm having to look at garbage. HTML/CSS can accommodate and isolate garbage somewhat more easily. That's why I still use HTTP.
- Gemtext language is vulnerable to human complexity.
- The quality of content also affects the motivation of client developers. Developers develop clients because they want to access the content, and if the desired content is not available, they will not develop. The question is whether the complexity of the design is worth the effort (return). If the complexity is deemed reasonable, the developer will begin work.
- In other words, Project Gemini has decided that meta information and inline marks, in addition to scripts and trackers, are not worth the effort.
- However, it did recognize the value of unlimited blank lines, emojis, and ASCII art.
- The low Gemini population is also probably related to differences in document structure. Like other markup languages, Gemtext has its own writing style and associated reading style. For those familiar with website conventions, Gemtext documents may be difficult to read.
- More than the specification itself, I am dissatisfied with the lack of guidelines for accessibility. Not to say that it should be as sophisticated as HTML. There is no all-purpose markup language. However, accessibility is a very ethical issue (because it creates information gaps), and a specification has a social responsibility. Society needs precepts.
- On the whole, Gemtext is tolerant, and in view of the prevalence of ASCII art, it will quickly become a mess as the population grows. I feel that it is a specification that relies heavily on human decency. Certainly that is a common fact of markup languages. But we dare not be vulnerable (handling of blank lines, whitespace characters).
- Sites can be created in plain text. How could it not be popular? I wanted to give everyone a warning before Gemini becomes popular.
- Writing never stops. Just edit and upload the file as is. Suitable for notes and diaries.
- Someone will certainly need Gemini. The challenge is to attract authors (resources). Spreading clients is also important. We need information.
- 2022-05-01:
- My attraction to Gemini is its democratic nature. Also attracted by low-power computing.
- It's frustrating to not have the freedom of a certain style. Can't the appearance of the footer be changed? There is a limit to the improvement of recognition.
- It would be nice if the formatting could be standardized (like a single site) and the client could choose the position of the meta information (in the reading order for screen readers) from the top, bottom, and heading list. In addition, the footer section color scheme could be set, which would make the document cleaner and easier to read.
- In HTML, the
footer element and the address element.
- Humans use protocols for reading.
- Information that can be reliably extracted by the user - the section (outline) - can only be made explicit in headings. Therefore, notices and meta-information should have headings.
- Essentially, Gemini is only concerned with sending and receiving plain text. That's why there are no inline markings (the first three characters of a line are used to identify the line type). I may have missed the point. But I really don't like the idea of line-by-line vertical margins, and the omission of ASCII art (placement within a preformatted text line) is not required. In Japan, there will always be authors who will put ASCII art in a text line.
- Easy-to-read structure. Keep the content concise. I consider long-form text better suited to HTML, because the detailed document structure makes it easier to get an outline. Above all, I like the reader's ability to control the style. I use CSS to make myself easier to read.
- When the amount of text is too large, it is better to break it up into chapters.
- Consider chapter breaks instead of consecutive line breaks (why break lines?).
- 2022-05-07:
- Gemtext has high machine accessibility but low human accessibility. Some authors try to solve readability problems with text that cannot be referenced as a sentence, which is easily harmful to screen reader users. If that is a limitation of simple text, then so be it. However, authors should consider the nature of the document they are creating and choose the format accordingly.
- I created a capsule (site). I said that
If I were to join the Geminispace, I would provide HTML documents
, but I have made it available as a Gemtext document as an experiment.
- Gemtext differs from plain text in that it has to be written as if it were a site (for the placement of hyperlinks).
- The writing style of the website and the Gemini capsule should be changed. It is easier to read if it is more concise and formal (due to the lack of freedom in the use of information). No need to imitate a website.
- Comparison of HTML and Gemtext
- Gemtextの書き方 (How to write Gemtext)
- 2022-05-14:
- Most people do not have anything to publish with the Gemini protocol. Even if I look around at the user pages of hosting services, I notice that many of them have only a single line of greeting or an HTTP(S) link.
- A page with only HTTP(S) links is acceptable, but to trust the author, there must be solid information. Is there a need to access it?
- If I have to read monochromatic text, I read paper books. What I expect from a display is a well-formatted document (with margins, color schemes, borders, etc.) that is easy to read. People with such expectations are not suited for Gemini. I learned a lot from the Gemini articles that there are people who can't read a well-decorated text. Gemini is suited to specific cases because of its many limitations.
- SNS, micro-logging:
- Gemrings, not webrings:
- How We Should Grow
- Few communities explicitly mention how they will grow. If people are growing and the population is increasing, existing methods are not going to work. Soviet's approach is rigorous, simple, and safe, and it explicitly states and considers the limitations that a community made up of people will naturally have. Yes, limits. While we dream of infinity, we live in a world of limits. Many communities fail to mention that footing, which I find somewhat phony. We encourage growth, we create our own world. People change. It is truly valuable and appreciated to be given the opportunity to contribute.
- The reason Gemini is special to those who don't know Gemini is that web browsers don't support the protocol. When it does, many people will treat Gemini much the same as the Web, as a simple one-column site. If the crossing is smooth, who cares about differences in protocol? Who will notice the differences in content? If an amateur developer can develop a client in a weekend, it is easy for a large group to implement it on the side of their day job. In such a case, the client share will naturally lean toward web browsers. The reason is that they are HTTP(S) compliant (perfectly compatible with the content deployed in that space) and convenient. Advanced tab management, mouse gestures, key assignments, UI settings, bookmark and history management, find function (highlighting), image preview, and extensions. Without these features, there is little reason to use an inconvenient exclusive client.
- What will happen is that more authors will write documents in HTML, if access is almost certain on HTML-enabled clients (a decision that requires statistics, but at least client developers who receive usage data from users can make statistics).
- I do not know the specification of the Gemini protocol itself, but even if it forbids calling external resources, users can use user stylesheets, and advanced clients may render Gemini protocol HTML differently than HTTP. Authors have the advantage of not having to change their presentation from the web, and can emphasize within lines, including inline links. It also has the advantages I mentioned (application of information, such as explicit meta information).
- The more users who are using both the Web and Gemini, i.e., the more links to Gemini on the Web, the more Web search engines will consider responding. The more important Gemini becomes to people, and the more information it contains, the more search engines will want to be in it and index it. If search engines can extract information, readers must use user agents that support the protocol/format. The search engines and Web browsers may be ready at about the same time, but providers who can implement both will certainly have an advantage over the competition.
- Authors who consider the Gopher/Gemini space private will delete documents as clients and search engines become better equipped.
- Small Internet:
- Spring's gopherspace
- More strictly speaking, it is self-help by individuals, an organization that can be handled by one or two people. The larger the organization, the larger the minimum. Depending on the number of members, even 200 may be the minimum. Most people who advocate a Small Internet do not envision such a large (even democratic) organization.
- Commercialization:
- Hosting services. if 1,000 or 10,000 people want hosting and no one can provide it, it is a business. Nowadays, it is easy for individuals to receive money. Whether it is an individual or a small business, if there is a certain demand, someone will make a business out of it. People are not afraid to settle their desires with money. And once it gets going, a large company will make a plan. How about Gopher/Gemini, which is all the rage right now? Let's provide a safe Geminispace for your readers! Just like installing a CMS.
- Web interfaces attract users with limited knowledge, as providers such as gemlog.blue and Flounder already practice.
- It is possible to provide interface and hosting services in Geminispace. Reference: Making Gemini Easy - tomasino@tilde.team
- In contrast, others say that we should protect the community by leaving obstacles in the way of people's entry. But Gemini does not have target users. It is unhealthy to try to exclude someone by being inconvenient (unfriendly). If Gemini were a community, that would be fine, but Gemini is a protocol. Gemini is a specification, an infrastructure. Infrastructures should not be subject to political will (which is what those who dislike commercialization claim for Web/HTML).
- Proprietary clients. As mentioned above, developers who already have a good Web browser need only implement the protocol.
- Search engines. Whether on the Web or in the Geminispace, this service is in high demand. Without links, it is impossible to find the desired content. And the act of searching for quality documents requires an enormous amount of time and effort.
- Advertising. Tracking is not possible, so there may not be many vendors entering the Geminispace. My concern is with newsletter-like content (bland, ornate, line breaks). Authors who care about donations and subscriber numbers will include links that have nothing to do with the document.
- Services via the Web. Providers can obtain information about users.
- cinni's corner: A site like the one I'm concerned about. Emoji and ASCII art decorations, consecutive blank lines (e.g., whisper into the void - cinni's gemlog).
- Search engine usability is catastrophically low. No document titles, no highlighting of search terms. Seriously? This is not a slow or small (ideological) problem, but a fatal inconvenience that forces people to work hard.
- Authors who expect information to be applied should write on the Web (total opinion). Geminispace/Gemtext documents should only be adopted as an alternative to the main format.
- Gemtext should be considered as a language for formatting plain text to make it easier to read, rather than for indicating the document structure as in HTML.
- Changing protocols and formats alone will not solve human problems.
- I don't want to see the old web.
- I have difficulty seeing monochromatic strings or sections.
- Plain text and Gemtext cannot be used horizontally for text. (e.g., columnar display)
- The Small Internet - Spring's gopherspace
- Gopher and Gemini may be small in specifications, but the problem is that many people have become accustomed to ease and convenience and are not interested in doing things themselves. Many people - myself included - see Gemini as a pseudo (text-only) Web.
- Web run by ordinary people.
- If HTTP/Gopher/Gemini coexist, how should they be used and what should be expected?
- I was angry and perplexed as to why I was writing a document that was neither intimate nor legible to me. If it hurts, don't write it, that simple. I don't write. I only convert.
- It is natural that my own writing is easy to read. No one else's plain text is easy to read. (Structure is dependent on the author.)
- We cannot stop the madness that humanity has built. We can only share intimacy by finding friendly individuals.