💾 Archived View for inimeg.space captured on 2024-05-12 at 14:47:19. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
Welcome to this little Gemini capsule. Actually, I refer to it more as a pod. There is not much on here yet.
This pod runs on a little 7+ year-old Raspberry Pi 2 that is currently sitting somewhere on my home desk in Magdeburg, Germany. The OS (Alpine Linux 3.16.1 for armv7) is loaded from an even older and slower 512 MB MicroSD card. However, once it has booted up, the whole operating system is running entirely within the Raspi's 1GB of RAM. This "diskless mode" makes any (simulated) file access extremely fast, while sparing the elderly SD card. Only selected files are occasionally synced back to the card. Most temporary files, including log files, are genereally not preserved between reboots.
Low bandwidth b/w picture of the little Raspberry Pi running this pod
Medium bandwidth color picture of the little Raspberry Pi running this pod
As Gemini server software, I'm currently still using my very own shitty and obsolete implementation "Lunokhod" that I hacked together in Go. It's online as open source on sourcehut somewhere, but I'm too embarrassed to link to it here.
Networking-wise, the Pi used to be just one of the devices attached to my regular run-of-the-mill home router, where it ordinarily wouldn't be reachable from the outside Internet. To circumvent this, the Pi in the past simply kept up a (wireguard) VPN tunnel to the cheapest, lowest-spec virtual machine I could rent from the hoster of my choice (for about 3 euros a month). I then pointed the inimeg.space domain name to the VM, which in turn simply forwarded all incoming TCP traffic on port 1965 via the wireguard tunnel to the Pi. Worked like a charm and I could have stopped there.
However, as it turns out, the "customer premises equipment" (aka the home router) that my ISP had shipped to me also supports some more advanced network configurations. I could exclude the Pi from the usual home NAT and have it directly reachable under the public IPv4 and IPv6 addresses that my ISP assigns to my home network at any given time. No more need for VPN tunnels and port forwarding, if I could just keep the inimeg.space domain up to date to always point to my current home IP address(es).
And that turns out to be quite easy and straight forward if you re-use the cheap VM that you rented earlier to run your own DNS server there instead...
In late 2020, I thought I had hit upon an amazing idea about how to upload content to a Gemini Pod in-band, without reliance on other protocols like FTP, SSH or the like. With "Inimeg", i.e., "reverse Gemini", a Gemini client would temporarily act as a Gemini server, with the Gemini server briefly playing the part of a Gemini client. The server would then be waiting for any content that the client may send (i.e., "upload") to the server.
I felt like a genius and created a full and sophisticated specification and a crude first implementation of my Gemini protocol extention, making extra sure to not break compatibility with vanilla Gemini in any way. I even registered this domain and proudly announced my invention to the Gemini mailing list.
People were very kind.
As it turned out, I had pretty much re-invented one of a range of mechanisms that folks had already proposed and discussed to death on the (now apparently defunct) Gemini mailing list.
Archived overview of a range of proposed protocols
I have since embraced the view that Gemini can stand on its own and that the community is rightfully skeptical of any technical proposals that try to extend or augment the protocol in any way. Simplicity is a virtue that needs to be kept sacred.
Thus I banish my Inimeg ideas to the attic. I'll keep them online for posterity but don't expect to build upon them in the future.
Overview of the Inimeg Protocol
The Inimeg Protocol Specification
Contact me directly at <benthor@posteo.de>
