💾 Archived View for rawtext.club › ~sloum › geminilist › 001861.gmi captured on 2020-09-24 at 01:35:41. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Phil Leblanc philanc at gmail.com
Tue Jun 23 22:29:00 BST 2020
- - - - - - - - - - - - - - - - - - -
First, thank you all for your answers.
@Felix Queißner
Yeah, definitely. It sounds like the perfect match for embedded devices,as it requires no encryption and no complex state machines.
I think also for hobbyists and education. As soon as "what is asocket" has been explained, Mercury can be used as one of the firstexamples of how it works. Add TLS in the mix and suddenly it becomesmore difficult to grasp.
@defdefred
Seems that the protocol specification should be separate from the text format protocol (true for gemini too).
Of course the request/response protocol and the text/gemini format aredistinct. But I think at the moment they are best together in the"Gemini Spec" document. It doesn't prevent anybody to servetext/gemini pages over http... :-)
@William Casarin
I don't see why there couldn't be another ecosystem around mercury. Ipicture clients eventually supporting a suite of protocols, such asgopher, mercury and gemini all at once.
In my mind, it wouldn't be a different ecosystem -- exactly like thereis only one "web ecosystem", with both http and https URLs.
As long as the spec specifies both the "with TLS" and "without TLSbits", and as long as most client/server authors agree to supportboth, there shouldn't be any ecosystem split -- again, same as whathappened with http and https
Phil