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

This month I kept grinding away on removing DropIDs from the hot path of authentication in appspaces. See the November-December update for an explanation of what it’s all about.

Showing User Conflicts in the UI

A consequence of removing dependence on DropIDs and also adding authentication via Tailscale means that each appspace user can be identified through different identifiers (their tailnet ID, their DropID, and in the future probably their email address.)

Having multiple ways for each user to authenticate is great but you might get in a situation where one appspace user might be associated with two separate ds-host instance users. This is a confusing situation to be in and is best not allowed. Similarly it is possible to associate one instance user with two appspace users. Again, confusing. But also, it means the system doesn’t know which appspace user to authenticate when an instance user wants to access an appspace. It’s best to disallow this situation.

Note that if I do my work correctly ds-host will prevent you from creating these conflicts in most cases. For example it won’t let you select an instance user for an appspace user if that instance user is already associated with a different appspace user.

But conflicts are still unavoidable. I am serious about making appspaces “movable”, meaning that you can export the data and import it on a different instance and, as much as it’s possible, things should work. In other words an appspace, along with its list of users and associated auth identifiers, can be imported into a ds-host instance, and there is no guarantee that this set of auth ids doesn’t conflict with auth ids and instance users of the new host.

As such, I have to assume conflicts can happen and make it possible for appspace owners to deal with them.

The first step is to display the conflicts as clearly as possible. See below for where I’m at with this right now. The first screenshot shows no conflicts, just one warning about a user that is not an instance user at all. (It’s technically possible to have non-instance appspace users, but it’s not implemented yet.)

Now if I change the DropID of the first user to “dropid.local.dropserver.org/altoli” and then set the DropID for the “Alt Oli” instance user to the same, then everything falls apart, and orange appears everywhere.

(nb: I still need to replace “User 1” with the actual instance user name and profile pic, and tweak some alignments, but you get the idea.)

If an appspace owner encounters this, clicking on the “Edit” link allows them to remove or change the problematic auth identifiers. Hopefully that’s clear enough.

Instance User Display Name and Images

I had punted on display name and images for ds-host instance users until now. With instance users becoming more important and DropIDs becoming irrelevant I needed to give instance users these display names and profile pics, and make them available to all other instance users so they can see for example who owns an appspace that they are using, etc…

Moving Along

Overall decent progress in February, especially considering that I was on vacation from the 20th onwards. I can see the light at the end of the tunnel with this work. See you next month.