I do not buy it. Just use gemini:// rather than https:// to refer to that specific subset of https + html. Maybe also add a header to the server response that says x-gemini: true or whatever.
> It's difficult or even impossible to deactivate support for all the unwanted features in mainstream browsers
Just do not use mainstream browsers then. Make your own like you do for gemini. They address it a bit later with:
> Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch
And I will disagree on this part, http 1.0 is actually easier to implement than the gemini protocol.
> Even if you did it, you'd have a very difficult time discovering the minuscule fraction of websites it could render.
Except gemini browsers render even less websites right now.
It seems to me that the gemini developers can't really think outside the box. This is further proven by their dependence on things like TCP, TLS, and DNS.
gemini isn't trying to reinvent the web, to make it P2P or serverless or whatever; it's just reusing the ideas of gopher and the web but going in another direction. It doesn't try to replace the web. From this point of view it makes total sense to reuse TCP, TLS and DNS, because they're not trying to replace them.
> Maybe also add a header to the server response that says x-gemini: true or whatever.
That would require adding headers, which means extension is possible, and that's explicitely something gemini doesn't want. I believe it makes sense in the goals gemini wants to achieve.
> And I will disagree on this part, http 1.0 is actually easier to implement than the gemini protocol.
HTTP 1.0 still has multiple headers and multiple verbs. It's actually closer to HTTP 0.9. Yes, you can say "don't use those" but at some point it's good to refresh the spec and see what is and what isn't needed. Moreover HTTP is just HTTP, Gemini is transfer + encryption + client identification (through client certificates); the latter is still the wild west for the HTTP world, there is no clear set of "best practices" in this domain
> 1.4 Do you really think you can replace the web?
> Not for a minute! Nor does anybody involved with Gemini want to destroy Gopherspace. Gemini is not intended to replace either Gopher or the web, but to co-exist peacefully alongside them as one more option which people can freely choose to use if it suits them. In the same way that many people currently serve the same content via gopher and the web, people will be able to "bihost" or "trihost" content on whichever combination of protocols they think offer the best match to their technical, philosophical and aesthetic requirements and those of their intended audience.
For the other point you seem to forget that gemini doesn't exist on technical grounds but on philosophical grounds: it wants to create a new space with its own rules, even though the technicalities are close to something that already exist. People have written blogs (called gemlogs in gemini), and they "hacked" the format to build an informal replacement to Atom. The constraints of the medium created the requirements and the result is a simple, human-readable and human-editable document that can replace Atom in most cases: https://proxy.flounder.online/gemini.circumlunar.space/docs/.... It follows the philosophy of making this new space more human-centered.
By "This is what they claim, yes." I meant that they claim that they are not trying to replace the web, not that they claim that they try to replace it.
Every Gemini post on HN has an inevitable post like this.
Gemini developers want to keep things inside of a box that can't be bulldozed by corporate interests. I love it. I just wish Gemini browsers would optionally inline media and video links, but I'd be surprised if that doesn't happen before too long.
What I meant I guess was displaying images and video inline on a graphical browser instead of on a new page or browser instance. Looks like LaGrange already does that at least for images.
Yeah, I really like the links being on distinct lines. I don't know why, but it's refreshing. I think it also encourages a document writer to actually provide details about the link and definitely gives the user agent an opportunity to display the destination and be clear about what is happening.
> 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.
Not that I can't see the appeal for the gemini devs to start from scratch and roll their own protocol rather than start with a browser and subtract the unwanted parts, but that justification is, technically, practically, and also generally very weak.
Technically, because you can very well limit HTML to a subset of markup elements (for example, to exclude <script> elements or, likewise, onclick and similar attributes accepting script). The whole point of SGML, on which HTML is based, is to define markup languages, and also derive restricted languages from general ones. The problem here is rather that HTML on its own isn't expressive enough for interactive things we've come to expect (such as idk menus, table-of-content summaries, and other navs or in-page search dialogs and other interactive features that are not quite webapps) yet is also too powerful with js being inserted everywhere to non-heuristically comprehend content for reader mode apps and screen readers in the general case.
Practically, because syntax checkers (SGML or otherwise) and NoScript exist and have for a long time. It would also be cool if search engines could finally come around and penalize or at least flag content relying heavily on script and/or invasive tracking for ads. One way to make this happen is to introduce application/html as opposed to text/html media types.
Generally, because HTML and other markup vocabularies have been developed using public money for, well, publishing hypertext in academia, and it's odd to marginalize that original use case just because of the desires of ad companies.
The argument isn't being technical or practical, it's being mental.
It's acknowledging the fact that if you given humans a different/unfamiliar protocol they will be naturally inclined to treat it's content differently, which is the entire point.
> It's difficult or even impossible to deactivate support for all the unwanted features in mainstream browsers
Just do not use mainstream browsers then. Make your own like you do for gemini. They address it a bit later with:
> Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch
And I will disagree on this part, http 1.0 is actually easier to implement than the gemini protocol.
> Even if you did it, you'd have a very difficult time discovering the minuscule fraction of websites it could render.
Except gemini browsers render even less websites right now.
It seems to me that the gemini developers can't really think outside the box. This is further proven by their dependence on things like TCP, TLS, and DNS.