Dropserver Progress - January 2025

This is the progress report for Dropserver for January 2025. While the previous report was a wrap up of 2024, this one is a look ahead for 2025.

The Battle Between the Drive and The Grind

A New Year’s celebration adds a new notch to a years-long project. A new year is a time to take stock of how far a project has come along, and what it still needs.

Safe to say that for Dropserver I’m not beaming with confidence. There are a few things making it feel like an endless grind. Some features take forever, like Tailscale integration which is kicking my butt.

Also, after realizing that the problem space is bigger than I had anticipated and my ideas on how to solve it shifts, I have to contemplate doing more work in a direction I hadn’t anticipated.

On the other hand, there are things that drive me forwards: there is light at the end of the Tailscale tunnel, and its integration into Dropserver is key to reaching the project’s goals.

This is no celebration but the current political environment in The US of A (f*** yeah?) is making self-hosting from home something many Americans may want to look into. As dark as that is, it pushes me forwards.

Finally I am motivated because I have realized what I need to do to make Dropserver stand out from the crowd of self-hosting platforms: make Dropserver very to install.

The way forward

I think the most game-changing characteristic I can bring to the table with Dropserver is to make it very easy for anybody to install. This means:

• use a cheat code for networking (the cheat code is “Tailscale”)
• make ds-host installable on popular operating systems (MacOS, Windows)
• use GUI installers and wizards
• ditch the config file

There are many self-hosting platforms out there, but most only work on Linux. Any platform that requires Linux has to first convince the potential user that they want to mess with Linux. For many people, that’s a foreign country they’ve never heard about and have no intention of visiting. A real demotivator.

I already build and run ds-host on my Mac. Unlike platforms based on Linux namespaces (aka containers), there is nothing about Dropserver that requires it to run on Linux. So it will be no problem to make a build for MacOS. Windows support will be harder simply because Windows is so different from Linux. But I should get to it because Windows market share is completely ridiculous if you believe StatCounter.

The next challenge will be to get rid of that config file somehow. Ideally the service needs to start via a GUI and live in the tray. No CLI or config file editing should ever be needed.

Further challenges will be to leverage the MacOS and win32 sandboxes to good effect to provide additional protection around Deno (I currently use bwrap on Linux). In addition to all that, Dropserver needs to update itself gracefully.

Note that the no-CLI and no-config approach applies to Linux too. Despite what I said above, buying a Raspberry Pi with the graphical OS pre-installed is within the reach of many. I’ll be exploring a release for arm64 and techniques for making it easy to install on a Pi.

These and a few other adjustments in my approach to Dropserver are where I see things going in 2025 …if I can just ship Tailscale integration already! 😭

Tailscale Integration Work

The current focus of the Tailscale integration work is to merge the users who appear as peers of the appspace node into the appspace’s users.

Tailscale is just one way to access an appspace on Dropserver. As such, a user might access it via Tailscale one day, and via the local network another day. Although this adds complexity, I am convinced that it is required to support multiple simultaneous ways of accessing an appspace, and not be “either-or”. This aligns with how I use 3rd party services when home hosting.

As a result each appspace user can have different “identities” depending on the network used to access the appspace. I have to consider this in all aspects of authentication and user management.

Then, it turns out tailnet users are… different to work with. Like I’ve mentioned before, everything about working with tsnet is an exercise in reversing the flow of data for everything. In this case, users don’t come from my database, they come from the list of peer devices for the appspace node. This is only available when the node is connected and can change at any second. So I have to listen for changes to the peers, deduce the list of users from the devices, and then decide whether that tailnet user is a user of the appspace or not.

Or rather, I have to decide how to decide if the user is an appspace user. It depends on how the tailnet is managed. If someone is carefully crafting their ACLs in the Tailscale UI, then any peer of the node should be authorized. But if they use set-once-and-forget ACLs that treat all appspaces the same they will use Dropserver’s UI to authorize users for individual appspaces. (Some admins may not want to mess with Tailscale ACLs on a regular basis because they are, quite frankly, user-unfriendly.)

Originally I thought that “shared” users would automatically become appspace users because sharing is a deliberate action by the admin, and there is no need to second-guess it. But I had reverse that. Why? Because there is a decent chance that the person is already a user of that appspace, and auto-adding would create two users for the same person. This is obviously bad and confusing.

The goal in all this is to present the appspace owner with a clear view of appspace users along with their identifiers on Tailscale and elsewhere. And then give them a way to manage the Tailscale peers by turning them into new appspace users or adding their identifiers to existing users.

Eventually, to make user management less manual, I will develop the “Contacts” section of Dropserver. Once a user is in the list of contacts then auto-adding becomes possible in some cases. But that’s for later. The first release of ds-host with Tailscale will have a clunky UX, sorry.

The grind

• add appspace users from tsnet (unfinished) bc8a63c
• change tsnet backendURL property name to controlURL 4b1ea07
• remove last_seen from appspace user and user auths 56532b0
• refactor appspace users reactivity c767b84

Onwards

See you next month.