Dropserver Progress - January 2024
This is the monthly progress report for Dropserver for January 2024. The previous report is here.
The Big Picture
Dropserver 0.13 is out! 🎉 This is the release that lets Dropserver install apps from a 3rd party website. If you’ve been reading these progress reports, you know it’s been a long time coming.
Getting to a Release
Before releasing I had to add a few more features and close up some unfinished work.
Generate the App Listing
The goal of the 0.13 release is that a Dropserver app should be installable (and upgradeable) just by pointing your instance to a URL. I spent most of my time in the last few months on the ds-host side of this: opening package files, fetching manifests, displaying changelogs, etc… But now I needed to do the other side: generating the files that can be hosted on a static file server.
At the very least ds-dev should be able to generate the app-listing.json which is the starting point of any interaction with a URL from the ds-host side. The app listing contains a list of versions and relative paths to each version’s package, icon, and changelog.
This part was easy enough. Commit 85b99a.
Generate the Website
What about generating an HTML page? I resisted doing this. It felt so superficial compared to the actual core functionality of 0.13. And yet, imagine this: you have an app published, and you can point people to a URL and tell them that’s how they can install your app. But visiting that URL just disgorges some useless data. Shouldn’t there be a webpage? Something that a human can consume?
The more I thought about it, the more it seemed that not having some page that describes the app, its relation to Dropserver, and how to actually install it, the more the whole idea of apps from URLs would fall on its face.
So I banged it out. It’s crude, it’s low-tech, but it’s there. Now when you generate an app listing you also get an HTML page. It’s self-contained but references the app icon to make it more lively. Screenshot below:
All the data is sourced from the app itself so it’s missing a lengthy description and screenshots. It’s really mostly good as a minimal presence to accompany a blog post for example.
Commit 18e1e2.
Finalize Handling of Redirects
Up until this point I had punted on how to handle redirects from the site where the app is hosted.
For the time being I don’t want the site that hosts the files to redirect to other sites. I concluded that the user is likely putting some level of trust in the site that claims to host the app files. If redirects are followed transparently, the files may actually come from a completely different host without the user knowing.
For this reason I don’t allow redirects. In the case where the app has to be moved to a different host or a different address the site can return a permanent redirect. However this redirect is not followed by ds-host. Instead, it presents the user with a notice of a new location for the app, and the ability to change the URL if they approve.
This way the user is always aware where their app files are coming from.
Commit 14f77f and others.
Update the Docs
I update the docs to describe listing and website generation and the process to move your site to a new URL:
https://dropserver.org/docs/app-packaging-distributing
Post-Release Meandering
After shipping 0.13 (🎉🎉) I have been feeling a bit directionless. I know there is tons more to work on but after focusing so much on one outcome, the sense of purpose feels awfully thin once the outcome is achieved.
I am allowing myself a period of vagabonding through some ideas I have. In particular I don’t like how we build frontends for web-apps right now. Big messy SPAs are more trouble that they are worth. So I’m thinking about some possible ways of doing better there. I may write a bit of experimental code just to get it out of my system.
This idea isn’t entirely disconnected from Dropserver: DS apps are meant to be “home cooked meals” and as such get put on a shelf for 6 months or more and revisited only occasionally. If upon revisiting the build system demands to be upgraded and then fails to do so, the app may be abandoned.
I am also thinking about the IndieWeb, the way search engines are failing us, and how we have a lot of tech that already exists on websites (RSS, microformats) but is under-utilized and under-valued.
These projects are fun to think about, but I can’t launch into anything that will take too much time away from the core of Dropserver. One thing I can do is improve the apps for Dropserver that I have built for myself, and publish them to a website. That was the whole idea of 0.13, right?
Leftovers App and Site
I made a few improvements to the Leftovers app and released version 0.6.2. There are more small bugs I want to fix, and will do soon.
First though I wanted to put Leftovers into its deserved home online:
https://leftovers.olivierforget.net.
I didn’t want to settle for the automatically generated website. There really needs to be a description and some screenshots. I took the generated HTML and added what I felt was necessary. I link to the generated site for version details.
Other Work
IndieWeb
I added social media preview images to this site and polished some of its microformats. I have more work to do, but I’m excited to get involved with the IndieWeb. In particular I am thinking of ways that Dropserver can help. Some of the IndieWeb requires a server to work, which often falls on a centralized solution. I’d love to see if Dropserver can help break that pattern.
ds-dev on Windows
I spent a bit of time working on getting ds-dev to compile and run on Windows. I still want to do this but I am dialing back the time I spend on it.
A version of Dropserver that is very easy to install and run on any OS is going to be a long term goal. I realized that after installing, the whole networking/domain/TLS certificates problem is such a huge hurdle for self-hosters that it’s just as important to resolve.
Lume and npm on Dropserver
I played with Lume to see if it could eventually run as part of a Dropserver app. It won’t be easy because it depends on a lot of modules from npm, some of which expect to have full read permissions on the filesystem.
I think a lot of the issues I encountered running Lume can be resolved and it will be able to run in a Dropserver app. It will take some tweaks on the Dropserver side, but this is a good test. App developers will want to make use of many npm modules, and Dropserver should accommodate this pattern.
If Lume does run on Dropserver, that means you have a full fledged static site generator that can run in a Dropserver app. This opens up exciting possibilities: CMS for Lume inside a Dropserver app?
What’s Next
I’ll continue to improve the Dropserver apps I have, and publish them online. This will help people who are kicking the tires of Dropserver have something to play with. I also have ideas for more experimental “demo” apps (like a CMS+SSG as mentioned above) that give people a sense of what can be built.
I’ll continue exploring possibilities for making Dropserver easy to install and self-host. But it will be a long road, and I realize that there is an other side to this equation: there needs to be a reason for people to install DS in the first place. That’s why I’ll also spend time on apps and demos of what’s possible.
When I feel ready I’ll get to work on some bug fixes and improvements in view of a 0.13.1 release.
Thanks for reading, see you next time.
