The problem of slides distribution…

As a PhD student, I often do presentations. A lot of presentations. In 2024 alone, I gave about 15 talks in different public venues, with a different slideset at each of those occurrences. As often as I can, I try to make those slides available to the audience if they need to re-read them after my presentation, but it frequently happens that I forget to do so, for multiple recurring reasons:

• I want to hold onto control of my slides a bit longer: they were not perfectly polished before the presentation, somebody pointed out a typo that I want to correct, in other words I am fine sharing the slides but I’d still like to be able to edit them;
• I don’t want to just send the files via email because the next time someone else will ask me for those slides, I’ll have to duplicate that work again.

The solution to those (procrastination inducing) problems is extremely simple. I should upload my slides to my website, point people to that link, and if I ever need (or have time) to update the slides I could simply overwrite that file. So why I am not doing just that? Well, having to re-upload files each time I produce a new version is taxing, and I also like sharing « living » documents that get updated pretty often, so I needed something more automated. A natural solution to this set of constraints is to use continuous integration: let CI build my slides or documents when their source change and push it somewhere where it could get served by a webserver, right? I used this approach successfully for a while, but it was not that satisfying:

• The artifacts I want to share are defined in multiple repositories, some public, some private, some where I control CI, some where I don’t, hosted on multiple forges, etc. Having a sufficiently general solution for the problem was just too painful after a while.
• I also wanted to add some kind of authentification layer on top of all that. There are some artifacts I want to share easily, but not to everyone. Ideally, I wanted to have some kind of « per-artifact » authentification.

Time to invent Artiflakery!

This prompted the absolute need for a 🌟homegrown solution🌟! Introducing Artiflakery, a webserver for on the fly delivery of Nix flake artifacts! The idea is very simple: you define pairs of the form (route1, flakeref1) and upon loading of route1 Artiflakery will serve the artifacts associated with flakeref1. For example, if you define:

/foo/bar/ github:foo/bar

then when a user will load https://artiflakery-domain/foo/bar/, the artifacts corresponding to the default package of the flake in the GitHub repository foo/bar will be served.

Of course, the served artifact are not really built « on the fly », but rather asynchronously updated when a request comes up.

Automatic reloading

Whenever a build produces a different artifact than the last one cached, Artiflakery will reload all the clients connected to the associated route.

Authentification

Routes may be public or guarded behind HTTP basic auth. Authentification policy is at the route granularity, meaning you could have different credentials for different routes.

Interested?

• Go have a look at the repository if you are interested to know more or contribute. Do not expect anything more polished that a hack made by a Haskell beginner so far, but I have the intention to hunt bugs!

• If you are simply curious, my personal instance of Artiflakery is running at static.luj.fr, don’t hesitate to poke around and tell me if you find something that you believe not to be normal!