Hi, thanks everyone for coming to this lightning talk about ESLONDROIT's download statistics.
Given this is a lightning talk, we probably won't have time for any questions.
So if you do have questions, I invite you to come to the ESLONDROIT booth and UD.
So let me just talk about what the downloads statistics are, how they work and how to use them.
And for the people who don't know yet, ESLONDROIT is a source for open source apps.
Similar to F-Troid, except that we get it from the developers directly, and in 60% of the cases,
have reproducible builds to make sure that it matches the source code.
First about me, who am I? I'm Sylvia Finals.
I'm known online as the last project.
For my day job, I do DevOps, a Linux system administration, aka I write a lot of YAML.
I'm a contributor to the ESLONDROIT project, and some of you may know me for contributing
to Katima. This is a little app for storing QR codes, playing takes, etc.
So first of all, why do we even have download statistics?
Well, we already had other ways to, like, prioritize good apps, especially in a sort of new store.
But a lot of people have been asking for download statistics to help figure out which apps are popular
and likely to be well maintained for a longer time.
So we decided to implement this to help use those choose to write apps for them.
We believe that down statistics help prioritize popular apps, which in the first world is a lot of the time,
mostly word of mouth, because there's generally a bit less budget.
And it also prioritizes all the well maintained apps because an update gives a download spike
and the age reflects a total amount of downloads.
It's however not a silver bullet, just because an app is downloaded a lot doesn't mean it is a great app.
So it's just an indicator of quality and the guarantee of quality.
And it works best when used over medium periods.
So you account for the age of the app, but not solely.
So the general overview, as you can see here,
the first step is a client, or your phone, or your browser, whatever.
Download an APK from one of our azure and right mirrors.
That mirror then writes that download to the silver lock.
Then we have a little tool, which we call the stats builder, which scans true the server for lock and outputs some statistics JSON.
It's a very simple tool.
At the recent server for lock, it turns them into statistics.
It's just two Python files, and a total config file, and it works in two phases.
First of all, of course, we need to configure it.
So say you have this download, this log line in your patchy lock.
Now you'll have to write a regular expression.
And it feels that our necessary art of date, time,
demetted the path, the status code, and the user agent.
The other feels our notes necessary, but I've included them here to make the regular expression easier to eat, to read.
If you have a browser that, or if you have a server that outputs JSON, for example, like Cadi,
you can also directly parse the JSON.
And you also need to tell it the date time format.
So as you can see, this is how that regular expression gets played up.
So, for example, let's say we run this over our patchy lock.
We have the logs in far-load a patchy access lock.
We first throw it through grab to filter out all the APK downloads.
It means it's a lot easier to write a proper regular expression.
If you want to have other stuff in your logs, like server, we're starting, or whatever.
Then we throw it into the parser with the config file, and we just write it to a JSON file.
And we got a simple JSON file that's per date says this app had that many downloads with that client.
That's step one.
And then for step two, after we have all these statistics, we run the index generator,
which creates an index suggestion, saying, for this date, you have to look into these files.
And it's important to keep this index suggestion and test directory together.
The problem with this, if you want to use these downloads a t6, that you only have data for one server.
And it's very verbose. It's always as like the looks per day.
And you have to read the index JSON to figure out where to find the stats for specific day.
So to make that a bit easier, I'm more usable.
So we have the stats collector, which pulls the build stats for all of our known Mirrors.
Currently three, two in Germany, one in the United States, we're very welcome to more Mirrors.
And then just merge those together into a basic and an upstream.
These files are a lot easier to consume.
And currently, we run an instance of this, which daily uses woodpecker CI on codeberg to generate that output.
And we publish it to a public URL.
I've not written the public URL here, not because I want to hide it, but just because I want to be able that if people use it,
that we can communicate with them, if we have to make some changes, especially because it's still rather new.
So feel free to ask us for the URL if you want to use it.
We don't have two basic types. We have the basic types, which is per app download stats.
We've got the client info. As you saw in the earlier slides, we had like per client information.
That's too much info for some people.
And we have the upstream statistics, which is basically the exact same format as shown earlier.
And we also provide 40 state types, 4 formats.
We provide a yearly format, the monthly and days, which is just 4 a month every single day, and the daily format.
And we also have a rolling dot JSON for most of these.
So you can get like the last year of statistics, the last month, etc.
So for example, if you want to know the total number of downloads per app in the last 30 days,
you just grab the rolling dot JSON in the monthly directory in the basic directory.
So you need few kilobytes. If you want per day information, of course that file is going to be a lot bigger.
For example, in June 2025, 2025, 06 per JSON in monthly in upstream.
And of course, if you just want all the downloads, the apps on a certain date, just grab that date from the daily.
Those statistics are then uploaded to the statistics server.
And then a client can download it. So what kind of client?
Well, for our first version, we build stats.isionbrite.org, which gives you like a web browser dashboard,
which helps a lot to make these JSON files more readable.
But where it actually gets a lot cooler is that we've been working together,
we've to identify and in the new store developers, to show these downloads statistics directly into the new store.
In the new store, you just see the amount of downloads total in a period.
But in the new store, you can even sort the apps by popularity, which will help you find popular,
most likely well maintained apps.
And the new store has a lot of graphs and stuff, because the new store developed a lot of graphs.
Some of you will surely love graphs too.
That is basically the quick overview.
There's a lot of texty slides, so please do take this opportunity to just download the slides
and look them over as a reference sheet.
I'd like to say a quick thank you to Announat for sponsoring this work,
and other related work through an NGI movie free grant.
It's the first grant we've ever got as Asionbrite, which is a really cool accomplishment for us.
And I'm just leaving these important links up for a bit,
to skewer code, contain all of this data, so you can check out some of this stuff.
Yeah, thank you.