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 a socket" has been explained, Mercury can be used as one of the first examples of how it works. Add TLS in the mix and suddenly it becomes more 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 are distinct. But I think at the moment they are best together in the "Gemini Spec" document. It doesn't prevent anybody to serve text/gemini pages over http... :-) @William Casarin > I don't see why there couldn't be another ecosystem around mercury. I picture clients eventually supporting a suite of protocols, such as gopher, mercury and gemini all at once. In my mind, it wouldn't be a different ecosystem -- exactly like there is only one "web ecosystem", with both http and https URLs. As long as the spec specifies both the "with TLS" and "without TLS bits", and as long as most client/server authors agree to support both, there shouldn't be any ecosystem split -- again, same as what happened with http and https Phil
---
Previous in thread (10 of 51): 🗣️ William Casarin (jb55 (a) jb55.com)
Next in thread (12 of 51): 🗣️ Case Duckworth (acdw (a) acdw.net)