Dropserver Progress - January 2026

This is the progress report for Dropserver for January 2026. The previous report is here.

I started the year by refreshing my personal note taking app, then I got back to work making ds-host more flexible with domain names, in particular making them unnecessary.

Updates to Illuminoted Dropserver App

Illuminoted is an app I wrote after getting fully fed up with the state of note-taking apps. It’s a very personal app, full of quirks and inadequate user experiences which is why I haven’t yet formally published it online as an installable Dropserver app, though I probably should.

As with all my personal apps I only touch the code when it’s sorely needed. With the Leftovers app I usually go half a year before I get in there and change things up. This is a key thing about home cooked apps: unlike commercial apps that are always after a bigger number for their KPIs, the changes are few and far between. Or rather you only change them when you strongly feel that something needs to change. Maybe there is a badly needed feature that you just don’t want to work around anymore, or a papercut bug that has snagged you so many times you’ve run out of virtual band-aids. I find that a few months is the right amount of distillation to surface the truly necessary changes.

Oddly, with Illuminoted, though it’s the app I use more than any (I’m on it all day every day, 19,360 notes deep, documenting all work stuff, non-work coding stuff, but also mundane things like my car tire shopping and research notes) it’s the one that has gone the longest without any significant upgrade.

October 2023! That’s the last time I did anything. Naturally after such a long time I had a long list of things improve. I didn’t get to all of them but I did knock out quite a few wins and I am happier for it. You can get an idea from the commit log.

I now have better threads management, better navigate-to-note support, better UX to create a new note, and proper full text search thanks to sqlite’s FTS5.

Back To Work Removing DropIDs

In the previous progress report I talked about my goal of removing the hard dependency on domain names in ds-host and how that meant I had to remove the hard requirement for users to set up a “DropID”.

This creates a cascade of changes around users and appspaces. I’ll try to summarize it all below:

Eliminate “remote” appspaces

These are appspaces hosted on other ds-host instances that can be accessed via federation (DropIDs were central to this). It turns out that a bug in my federation code prevented any such federation, so the “remote appspaces” could only be on the instance the user is on. A convenient mistake…

Make it possible for users to access an appspace on the same instance

Originally “remote” was used for both other instances and appspaces owned by others on the same instance. With federation gone, the latter capability had to be restored.

Double down on multiple identifiers for appspace users

When I integrated Tailscale into ds-host I made sure to use that network’s native IDs to identify users in an appspace. A good move, but then I had multiple ways of identifying a user: DropID and Tailnet ID. Once you allow that, the potential for conflicts is inevitable. An appspace user could match with multiple ds-host users and a ds-host user could match multiple appspace users. To avoid problems I wrote a system to detect such conflicts and report them to the frontend.

A reminder that all of this stems form the principle that appspaces should be “moveable”: you can download an appspace from a ds-host instance and move to another without losing all connections to the users. This is possible because appspace users are identified with established globally unique identifiers, not the instance’s user ID.

It’s good to have this work done because I will probably add more types of identifiers in the future, like the venerable email address.

Cleanup on aisle 6

Finally I was able to remove remote appspaces from the code as well as the faulty “federation” code. A few months ago I said I was about to do a “cleanup on aisle 6”. This was that cleanup, and it felt great to mop up over 2000 lines of code away.

What’s Next

I still have a number of loose ends to finish up before I can ship these changes, sadly. As always the pace of development of Dropserver isn’t what I’d like it to be. So it goes.

I’m late posting this progress update. Even later than usual in fact. January was stressful for reasons unrelated to Dropserver. See you for the February update, hopefully not as late this time!