A few weeks back, I started up a new spare-time side project: Magpie. It's an app to to provide a UI for downloading games you've purchased from GOG (and maybe other sites in the future) to keep them locally in Domino.

The goal is to have a self-hosted way to keep access to games you've purchased without having to rely on the future availability of them on someone else's servers. Domino's a perfect fit for that sort of thing, and this is an itch I've wanted to scratch for a while.

GOG

I've always liked GOG. Their original "Good Old Games" mission of dusting off old games to get them easy to run - both legally and technically - on modern systems has been a great boon to game preservation, and it's been easy to build up a big library of games. They've also always had a policy of making the games you buy DRM-free - even modern releases - and they offer offline installers in addition to their Steam-style GOG Galaxy app. It's this part that allows Magpie to be practical.

While I like GOG and fully expect them to keep doing what they're doing, it's become quite apparent especially lately that you can't rely on any company acting in ways you like indefinitely. Even if GOG itself stays "good", they can't guarantee anything for the future. For example, they used to sell Warcraft 1 and 2, but, when Blizzard released their remasters, they quickly had GOG remove their version from sale. If you purchased the GOG versions before then, you can still download them, but I wouldn't be surprised if that changes down the line. It's within Blizzard's rights to do this, but that's sort of the point: I don't want to rely solely on the continued good graces of a vendor to let me access a thing I bought.

Fortunately, GOG has an API... sort of. It's clearly designed just for their own app to use and you have to piggyback on a single client ID for tokens, but it ends up working, at least for now. It's not the sort of thing you'd build a commercial application on, but a for-fun project can be fine with that level of risk. With a token in hand, the API works well to list and access your owned games, and the download URLs will redirect over nicely to the offline installers and ZIPs of extra materials.

App Structure

Since this is a from-scratch clean project, I'm free to use the XPages JEE project exclusively and target Domino 14.5 with Java 21, and it makes it a joy to program. The remote API access can be clean MP Rest Client interfaces, I can map the JSON to record types, and I can use Concurrency executors to download files asynchronously.

Writing an app like this is also a big boon to the upstream project. There's no better way to test a framework than to actually do stuff with it, and this has helped me improve the Concurrency experience and find a couple bugs that hadn't cropped up in abstract tests.

The downloaded files end up getting stored as attachments in the NSF, which is... fine for now. It's no problem at all for a 13MB game like Ultima 1 and remains pretty reasonable for a 1GB game like Stardew Valley, but I'd start feeling pretty weird about putting a 300GB mountain of assets like Baldur's Gate 3 in there. I guess it'd probably work thanks to DAOS, but it's making me think I may want to add support for direct storage in your own S3-compatible bucket. That'd be a nice extension to the JEE project's NoSQL driver for sure.

Future Additions

Being a low-key side project, work on it is coming in drips and drabs, but I definitely have a bunch more that I want to do.

I've recently been working on integrating IGDB data (which does have an official API) to supplement the sparse game info from GOG to make the local library more pleasant and useful as it grows. I would love to add support for itch.io as a source of games, though the lack of API and the frequency with which you purchase games without logging in makes that one a daunting prospect. Along similar lines, the Internet Archive's software catalog is a natural fit - while they obviously intend to keep going, they have a lot of foes that could make that difficult in the future.

And, beyond that, this is also just a good playground to tinker with web stuff. I always challenge myself to keep the JavaScript to a minimum when I have the choice and I like to use newer-era HTML elements like <progress> when I can. I've been using the Milligram CSS "framework" as the baseline for the design, since it has a philosophy I like: style basic HTML elements so they look nice and coherent and don't force a lot of weird mangling of your code. It admittedly might be a little too sparse for a non-designer like me to make something attractive out of, but it's been serving me well in the scaffolding phase.

I'd also like to use this as a playground to push the boundaries of the Jakarta Concurrency support. I'm already using it to handle game downloads, but I'd love to have periodic background tasks to do things like check for updates to already-downloaded games and potentially auto-download new purchases that fit some criteria (e.g. "under 10 GB"). On paper, that should work, but the XPages stack is a hostile place for long-running code like that, so it'll be a good way to find the limits.

Anyway, this is a fun one. It's good to play around with these various APIs, Domino is a good conceptual match for it, and - at the risk of sounding too grandiose - I think it's a moral good to have more self-hosted tools like this. I'm looking forward to seeing how it evolves.