I’m going to let app devs declare an “accent-color” in their #Dropserver app manifests. It’s a very cheap, easy and safe way of giving apps more personality inside the Dropserver UI.

Dropserver’s local development helper ds-dev will package an app for you with one command. So the burden is not high. It should be pretty easy to make it work from a CI/CD service too if you want to go that route.

A month ago I wondered if #Dropserver should support “Single File Apps”. ( https://social.tchncs.de/@teleclimber/110216573477447480) Some thoughts, after a month of working on app packaging:

@ocdtrekkie@mastodon.social I tried to find a comparable Sandstorm app and it weighted in at over 10Megs. Maybe just a by-product of how it’s built. But good to know that’s not how it has to be.

Small app packages makes it possible for app devs to self-distribute their apps.

To be fair, the app works well but doesn’t even include an icon. So that size will grow.

Got to the point where #Dropserver can package an app.

It’s too bad, #TOML’s multi-line string handling is nice for longer text like app description and others.

I’m looking at config file formats for #Dropserver app metadata. #TOML looks good but there are criticisms I can’t ignore:

@ocdtrekkie@mastodon.social I also think this is where an app store/catalog can be helpful. The people running the store can do its own signing. That gives the store the ability to patch problematic apps and it removes the issue of vanishing authors, which we know is commonplace.

@ocdtrekkie@mastodon.social Yes that’s an interesting conundrum. I think author-signing is right.

@ocdtrekkie@mastodon.social - YUNoHost has a CI-driven automatic quality ranking for their apps, called “level”. Details here: https://yunohost.org/en/packaging_testing#application-quality-level

Now looking at prior art for app packaging for server app platforms such as #Sandstorm and #yunohost

@ocdtrekkie@mastodon.social Yeah that’s a big footgun.

@ocdtrekkie@mastodon.social Another thing I’d like to support is “lateral migrations”. Meaning migrating to a fork of an app, or a completely different app.

@ocdtrekkie@mastodon.social I’d like DS to warn users if the app does not provide a “down” migration to reverse an “up” migration. This is feasible now. Note that I expect app devs to provide a “down” migration that reverses an “up” migration.

@ocdtrekkie@mastodon.social It sure is. But this is an area where not attempting to run legacy applications helps a lot. With full control over what constitutes an “app”, and with migrations declared by the app but controlled entirely by Dropserver, I can put constraints that make the situation much more manageable for users.

To be clear this error should only happen if you restore your appspace data from an old backup.

There’s lots of different things to work on in Dropserver, but right now I am going through the frontend code to bring the code quality up (it’s a bit of a mess), move to using Pinia and the “setup style” of #Vue SFCs (huge reduction in boilerplate).