< Using GitHub as a decentralised contribution, centralised distribution system

If you are reading this, you are probably already aware of LibrExam. LibrExam, as of now, has been my most monumental achievement in software development — and yet, it has been on a two-month-long development hiatus.

Apologies.

Nevertheless, my project uses a (clunky) decentralised content contribution system that I would like to talk about here. It’s highly likely someone has already built something similar to - but much better than - this, but I could not care less. I only believe in homegrown technology.

I have used GitHub to achieve this. This means that neither I nor the end-user has to shell out money or computing power for a server, though this also fundamentally makes the system centralised.

This image was actually created to reflect an unironic sentiment. I have repurposed it.

Let me elucidate how I did it. (Does this already sound like a LinkedIn post?)

Here’s what happens:

1. The end-user creates an exam (which, obviously, follows a strict format). The file extension is .json.
2. They then create a GitHub repository
   OR
   commit to an already existing repository. Each repository can host one or multiple tests.
3. Each repository has a root-level indexing JSON file that defines metadata for these exams. Updating this index is manual and is the responsibility of the repo contributors, for now — though I might help automate this in the future using a GitHub workflow.
4. Each repository is tagged with the librexam-test topic.
5. I, on my behalf, have yet another central repository with a workflow that uses the GitHub API to find repos with this tag and index them. Since I am not using an API key here, I am rate-limited.
6. My app, LibrExam, simply moves top-down beginning with my repo-that-has-indexed-repos.
7. Voila.

An experience polished enough to attract 10 million dollars in VC funding.

There are some problems with this approach.

To begin with, I make a hard-write (by putting a timestamp) on my final indexed repo to avoid missing out on rapidly committed changes from the user-end repositories, regardless of whether there are any changes, thus bypassing cache issues.

And with that, we come across the next problem. Updates happen only around once every 10 minutes, indiscriminately. There’s no synchronicity in this system. Somewhere, someday in the near future, someone might have to wait up to 10 minutes to try out the Star Wars Trivia 100-marker that their friend has made. Tragically, then, Buzzfeed might eat into LibrExam’s market share.

Finally, there is the concern of unmoderated content — a concern expressed by one of my patrons. Truthfully, I must say, I would be very happy if such a concern materialised, because only then could I truly say that my project has been a success.