Dropserver Progress - November December 2025

This is the progress report for Dropserver for November and December 2025. The previous report is here.

In November I began work on removing the dependence on domain names in ds-host.

Domain Names in Dropserver

When I started writing Dropserver I thought of it as a very standard server program. The main difference was that it served apps that could be easily installed through an interface.

Lately I have started peeling away the assumptions that go into making a server. In particular I started seeing that the server might actually be serving on different networks, or have requests funneled to it via a diversity of technologies.

The first sign that I had made some incorrect assumptions came when I wrote the integration with Tailscale.

In a typical server program the configuration file expects that there is a domain name that points to the server. Because of course there is, right? What’s a web server without a web address?

So ds-host was built with the idea that there was a domain name, and that the appspaces would live at subdomains on that domain, and that’s how you could refer to an appspace, because its address is its name. Nice and easy.

Then came Tailscale, and each appsapce is its own Tailscale node, and all of a sudden appspaces have two names: the subdomain based one, and the Tailscale one, which is somename.tailxxxxx.ts.net for example.

The Tailscale integration works really well. It’s a fantastic way of accessing a personal web-app from your phone or laptop from anywhere in the world. In fact it’s so good that if you only use Dropserver for personal stuff, a domain name pointing to your Dropserver instance is kind of unnecessary.

Not just unnecessary! It can be painful to set up and it costs money too.

Using a domain name to access ds-host typically involves making your instance accessible via a public IP, which makes it a target of bots and crackers. You need to buy and renew that domain name, point it to the right IP etc… All these things are surmountable, especially for regular web developers. But my goal is to bring self-hosting to non-tech people, and ditching the requirement for a domain name is a big win.

Going beyond Tailscale I am thinking about creating an integration with a tunneling service. Those also sometimes offer use of their own domains, so once again, no need to bring your own.

In the end the goal is to let people run Dropserver on some small computer in their home, and use one of these tunneling for software-defined network services to make that instance accessible as appropriate for their use case. But this all means that “the domain is defined in the config file” is completely inappropriate.

Removing the Requirement for Domain Names

The problem right now is the entire Dropserver code assumes a domain is set in the config file. When you think you’re building something in a bog standard way from day one, as I was doing with Dropserver, the assumptions you made have had all that time to take root and spread their tentacles all over the code.

I’ll need to figure out how I “name” appspaces when their subdomain+domain is no longer necessarily a thing. But that will be for a different time.

As I explored the code, I found that a big dependent of domain name is the “DropID” concept that I hallucinated long ago and baked deep into the system.

A DropID is a handle (username) and a domain. It’s like an email address, but there is no mailbox. It’s just a way of uniquely identifying a user (the ds-host instance ensures usernames are unique, and on a public domain name the domain part is unique too.)

Why did I create this thing?

Appspaces, Users, and DropIDs

I dislike having to create a username and password for every new service I do anything with. I dislike using OAuth because it gives too much control to the identity provider (usually giant megacorps) over my access to that service.

Should Dropserver become popular one day, with each person running their own instance, then joining a friend’s appspace would mean becoming a user on their instance (username + password). That’s friction and I don’t like it.

So I decided that Dropserver should be federated in some way. Two instances would be able to talk to each other and a user of one instance could obtain a login token to a different appspace from their own instance.

(Totally not reinventing OAuth over here 🤦‍♂️)

This works if instances are on the public internet with a registered domain and TLS. That was my assumption back then so I didn’t question it.

(I am not going to go into the details of how this worked because I can tell this post is going to be long enough.)

Instead of referring to users by the instance’s user_id, appspaces referred to users by their dropIDs, which are ids that are globally unique, and that allows people to log in from a different instance.

There are few things wrong here. First, it was half-baked. This kind of thing needs a lot of work to get right. I didn’t spend the time, and it showed in the completely lame implementation.

Second, really not a great idea to reinvent the wheel.

Third, it’s only useful when people have their own instance. It leaves potential users who have not gone down the road of setting up the ds-host (meaning everybody on the planet except me and maybe one or two other nerds) completely out of the loop.

Walls Versus Ramps

This could be its own blog post, but I’ve been thinking a lot about walls versus ramps. In short: what I should focus on is an easy way for non-Dropserver people to gain access to a DS appspace. Let them get into the system in the easiest way possible for the first time. Give them a ramp.

I’ve been talking lately about making Dropserver work on computers users already have at home like a Mac or Windows machine (a ramp) instead of asking them to learn Linux (wall).

By implementing DropIDs I was assuming many people would successfully climb walls. Instead I should focus on building ramps that help people get into Dropserver to begin with.

It’s a New Year

In 2025 I managed to ship Tailscale integration, and got ds-host builds for the Mac and for arm64. Then I got to work on simplifying configuration and installation of Dropserver. Work is slow, but steady.

In 2026 I’ll continue to make Dropserver easier to get into (ramp) by reducing the requirements for a basic minimal install that is useful and safe for serving personal web apps.