💾 Archived View for rawtext.club › ~sloum › geminilist › 007500.gmi captured on 2023-11-14 at 08:33:37. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Charles Iliya Krempeaux cikrempeaux at gmail.com
Wed Nov 3 06:03:39 GMT 2021
- - - - - - - - - - - - - - - - - - -
Interesting — did you post your work online somewhere?
--Charles Iliya Krempeaux, B.Sc.cikrempeaux at gmail.com
On Mon, Nov 1, 2021 at 4:19 PM <gemini at xj-ix.luxe> wrote:
On 10/31/21 21:30, Charles Iliya Krempeaux wrote:
For me I prefer to separate out the TLS part from the server part. So,
this implementation isn't an attempt to get rid of encryption, but
instead a way of dividing up the technology to make it easier to work
with.
I was originally doing this in a Gemini Protocol Go implementation, and
calling the TLS-free version "naked Gemini". But when I started reading
the mailing list archive, and some of the gemlogs — still working
through them — and noticed Mercury was the same thing, I created Go
package hg.
i've interpreted mercury similarly, though it doesn't exactly match the
thought experiment post that solderpunk made about it. i like this
approach as well to be honest. my gemini server project has a similar
approach and serves "mercury" or gemini sans tls on port 1958. i assume
this isn't canonical by any means, but it amuses me.
good luck with your project!
-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20211102/e45ec7db/attachment.htm>