💾 Archived View for josias.dev › microlog.gmi captured on 2023-03-20 at 17:27:42. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
Thoughts I'd like to share for any particular reason. Archival is not guaranteed.
Reply with `ssh note@josias.dev`, emailing me@josias.dev, or sharing your reply via Antenna.
More time has passed than I would have liked between writing about my progress on the reverse proxy. I've been busy with other pursuits and haven't gotten back to writing it yet. I've learned a couple of things recently that are relevant and are making me rethink my approach.
I forgot that TLS requests include SNI which includes the host of the request. For the majority of use-cases, this is sufficient for proxying. Just read the destination and pass the request along accordingly. The rewrap dance I mentioned in the last entry is unnecessary. This can already be done with tools like sslh which passes along TLS connections based on certain qualifications. You can also do it with nginx.
How do use sslh (from the XMPP wiki)
As I said, this covers most use-cases. Unfortunately, it's not sufficient for more advanced rewrite rules. SNI only includes the host, not the URL of the request. If we want to decide where to pass the request based on the URL or scheme, we have to decrypt the message. That comes with all the baggage I mentioned earlier. This is doable, but creates a deeper mess. Now that most use-cases are already covered, is it worth pursuing a more complicated solution to resolve the remaining few?
One primary use-case I was considering was separating Titan and Gemini requests. That way you could have one server that handles serving a capsule and one for modifying it. Was this a good idea? I don't know. I didn't consider it thoroughly and never developed an implementation. I figured it'd be a useful feature for niche use-cases. Now all that remains *are* those niche use-cases, ones that may be better-served by CGI.
Anyway, that's all I have for now. More thought on this reverse-proxy journey is required.
The proof of concept for the reverse proxy is finished. I'm now working on rewriting it properly putting thought into every aspect. I'd like the program to be robust from the beginning, since I'm sure it (or someone's reimplementation) will be a fairly popular tool in the future.
I'm plagiarizing many design patterns from the Agate Gemini server, since it is well-designed and also written in Rust. Its certificate-handling code is particularly helpful.
If anyone would like to share their own use-cases for a Gemini reverse proxy, please share them so I can consider them in the initial design.
A few hours later. I'm still working on the reverse proxy. I found a similar utility in Go, but it was incomplete.
Here's the problem with reverse proxying Gemini: most (all?) Gemini servers have TLS baked-in. For a reverse proxy to work properly, it must decrypt the incoming connection, determine where to pass it based on the host, then wrap it back in TLS and pass it along. This is a needless step. With Web applications, we host an HTTP server on some unused port and let the reverse proxy handle TLS. Gemini has no equivalent to HTTP, as all requests are wrapped in TLS.
The simplest solution (from the perspective of a reverse proxy) to this dilemma is to permit serving unwrapped connections via some flag in the server software. This violates the specification, but solderpunk anticipated this usage. As long as it's served locally and on a distinct port, I think this is viable.
I think my reverse proxy will do the unwrap-rewrap dance by default, but also support directly proxying without rewrapping. That way it will support existing use-cases as well as my own. New servers I write will likely follow the following rules:
I'm probably going to fork agate to add this, in addition to Titan support.
Thoughts are welcome. I'll probably compile this into a gemlog post when my thoughts have solidified.
Working on a reverse proxy for Gemini. I'd be useful for future experimentation. I have the Gemini protocol specification in one window, the Rust tokio documentation in another, and finally NeoVim in yet another for writing the code.
Let's see where this goes. Let me know if any of y'all know of an existing option for a reverse proxy.
Most of the notes I get on my server via SSH nowadays are comments about how cool the idea is. I appreciate the sentiment, but there are other things on my capsule too. :)
A whole lot of things are easier to do than be honest with myself sometimes. I'd expand that to the plural, but I don't want to assume your inner motivations. I'm not you, dear reader.
Just spent some time working on my personal micro-journaling tool. I had to get it to pass editor arguments correctly to support my usage of Neovim.
Technical jargon.
My alliteration is getting out of hand. My current capsule is composed of countless categories:
I just added "Communication" because "Creation" was getting lengthy and I don't consider this microlog to be "creation".
I was just inspired by Rurario to start my own microlog. I left Mastodon recently and would like another place to share short thoughts.