|
|
|
|
|
by rakoo
1972 days ago
|
|
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 |
|
> It doesn't try to replace the web
This is what they claim, yes.
> From this point of view it makes total sense to reuse TCP, TLS and DNS, because they're not trying to replace them
I do not understand this point. Wanting to replace the web is irrelevant to using better and simpler protocols.
> That would require adding headers
Treat any server that contains extra headers as invalid gemini then.
> which means extension is possible
Extension is possible regardless, even on gemini. I can set my mime to text/gemini-2 and add all kinds of stuff in it.
> Moreover HTTP is just HTTP, Gemini is transfer + encryption + client identification
HTTP might just be HTTP, https however..