Wanderer; Gopher2K; XMPP/AP Bridge

It’s been a minute since we’ve had a 100% self-hosting-focused Drop, so we’re doing that today!

---

TL;DR

(This is an LLM/GPT-generated summary of today’s Drop using MLX LLM in Ollama server compatibility mode, SmollM3-3B-8bit, and a custom prompt.)

• Wanderer allows users to manage GPS trail data on their own server, using ActivityPub for connections and a clean interface built with SvelteKit and Meilisearch. (https://wanderer.to/ [GH])
• Gopher2000 is a Ruby-based Gopher server that simplifies building Gopher sites with minimal code, offering a text-based, simple interface for content delivery. (https://github.com/muffinista/gopher2000)
• The XMPP/AP Bridge connects XMPP and ActivityPub users via client bots, enabling real-time chat between the two ecosystems with lightweight deployment and moderation features. (https://chat.gayfr.online/blog/ap_bridge%40gayfr.live/xmpp-activitypub-bridge-documentation-KdpNJ9)

---

Wanderer

As someone who tries to spend as much outdoor time as possible exploring Maine’s trails in boot and on bike, I’ve grown tired of subscription-based trail map and tracking services. Said fatigue finally resulted in some searches to see what was availble. And, sure enough, there are options, one of which is Wanderer (GH).

Wanderer is an open-source trail and GPS track database that you can run on your very own server (even one you may be carrying with you on the trail). Instead of trusting a company with your hiking data, you keep everything under your own control. You upload your GPS tracks, organize them however makes sense to you, and view them on maps without anyone else having access to your information.

You can connect your Wanderer with other folks running their own instances. It uses ActivityPub (yes, the same technology that powers social networks like Mastodon). You can discover trails from hiking communities in other places, share your own routes with people who might find them useful, and follow other outdoor enthusiasts – again, all while keeping your data on your own server.

The technical side uses SvelteKit for the web interface, PocketBase for storing data, and Meilisearch for fast searching. This gives you a smooth experience whether you’re using it on your computer or phone. You can tag your trails, search through them easily, create custom lists for different types of adventures, and view everything on interactive maps. Planning new routes and reviewing old ones feels natural and responsive.

Setting up Wanderer is designed to be straightforward. Most people (including me!) use Docker Compose, but if you prefer more control, you can install everything manually. For public setups, you’ll want to change some security settings and configuration values to keep everything secure (I use mine on Tailscale, but I will be making time to tweak said configs).

Whether you’re a solo hiker who just wants to keep personal records, part of a local trail running club looking to share routes, or a research group studying trail usage patterns, it provides a way to manage GPS tracks without depending on commercial services that might change their terms, raise prices, or disappear entirely.

---

Gopher2K

I have many conflicted feels about the resource in this section, since I 💙 Gopher as a protocol/service, but I have nothing but disdain for Ruby.

We’ve talked about Gopher in a few Drops, but for folks new to the protocol…

Before the web took over everything, there was Gopher. It was created in 1991 at the University of Minnesota as a simple way to organize and access information across the internet using hierarchical menus instead of hyperlinks. Think of it as the internet’s filing cabinet — clean, organized, and dead simple. While HTTP and the World Wide Web eventually won the popularity contest, Gopher never truly died, and today there’s a small but passionate community keeping it alive.

You can help said revival/survival by deploying your own Gopher2000 instance. It’s a Ruby-based server that makes building Gopher sites as easy as writing a few lines of code. You define routes using a clean syntax, render menus with simple commands, and serve content without worrying about CSS, JavaScript, or any of the complexity that modern web development demands.

Gopher is an environment where constraints cause creativity. There are no images, no styling, no animations – just pure, glorious text-based information delivery. Today, so many daft websites load megabytes of JavaScript just to display a blog post, Gopher’s minimalism feels revolutionary. Content loads instantly, works on any device with a text display, and focuses readers entirely on what you’re actually trying to say.

Is Gopher2000 going to replace your company’s React application? Probably not. But it offers something valuable that modern web development often lacks: simplicity, focus, and a reminder that sometimes the old ways of doing things weren’t just different – they were better (at solving certain problems).

---

XMPP/AP Bridge

Since I’ve blathered about ATproto quite a bit, I decided to add another ActivityPub-based service to today’s Drop to start to make up for that bias.

Folks were “chatting” well-before ActivityPub came around, and one messaging protocol which is almost a quarter-century old is XMPP. The XMPP/ActivityPub Bridge (GH) is designed to link the worlds of XMPP and the Fediverse, enabling real-time, chat-like conversations between users on these two ecosystems. Technically, the project takes a pragmatic and minimalist approach, relying on client bots: one bot runs as a user on a Mastodon-compatible server, and the other on an XMPP server. From an outside perspective, there’s nothing to install—messages sent to the bot on one protocol are relayed to their peer in the other world.

Deployment is lightweight and favors privacy where possible. You’ll need a Linux server (or container), icky Python 3.10, access to both XMPP and Mastodon-type servers that allow bot accounts, and a willingness to manage secrets and configuration files responsibly. The project supports granular configuration and environment variables for security and deployment flexibility, including where credentials live. systemd service files are provided for modern deployments.

On the technical side, communication is routed event-style: each bot listens to its respective protocol’s event stream using slixmpp (for XMPP) and Mastodon.py (for ActivityPub). Message handling, command parsing, user registration, moderation, and message ID management are all local functions. While the architecture is robust, there are clear limitations on scalability, largely stemming from Mastodon API rate limits (300 API calls per five minutes on a single bot) and the federated quirks of both protocols.

Administratively, the bridge supports assigning moderation accounts separate from bot accounts for managing blocklists (by account or domain), enforcing local policies about who can use the bridge, and mitigating abuse with rate limiting.

While I’m not running this, it seems to be a viable option if you prefer some older-school messaging tech.

---

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on:

• 🐘 Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev
• 🦋 Bluesky via https://bsky.app/profile/dailydrop.hrbrmstr.dev.web.brid.gy

☮️