[robalni]

> The question here shouldn’t be why not to use a subset of HTTP and HTML, but rather, why not build on top of HTTP with a different markup layer other than HTML. We have APIs using HTTP with JSON instead of HTML, for example.

As you can read in the Gemini FAQ, the reason that Gemini is not compatible with HTTP is that it should be possible to know that when you browse Gemini content, you will stay in gemini content. If Gemini were compatible with HTTP, then when you make a Gemini website, you know that many people who use it probably are using HTTP browsers, so it will be easier to mix Gemini with HTTP links which means that Gemini users will be more exposed to the type of content that they were trying to avoid by using Gemini.

If Gemini instead is incompatible with HTTP, it will be harder for site owners to put a HTTP link on their Gemini site because they don't know how the user's client will handle that.

Maybe the best solution could have been something that makes it easy to get in but not as easy to get out. I mean something like it could be possible to have a HTTP link to a Gemini site that would work in all browsers, but that Gemini site could not have a HTTP link. I just don't know how you would make that.

[_heimdall]

Is there actually a good way for Gemini as a protocol to make linking to an HTTP site harder? I don't think the protocol actually limits the type of link on a Gemini page, and if I click on an HTTP link in an app my OS will just pop it up in a web browser without a problem. Yes I'd know the app changed, but I'm not sure that would really help guard me from following a link to the current web

[NoGravitas]

It is common for Gemini clients to represent HTTP links differently from Gemini or Gopher links, so the user can make an informed choice before clicking.