mazassumnida: a solved.ac badge service for GitHub profile READMEs

A badge image rendered from a solved.ac profile

The project description states its purpose plainly: it is a project that shows a boj profile nicely in a GitHub profile. The reference to boj is the Baekjoon Online Judge, and the linked profile pages in the README are on solved.ac, the site that aggregates Baekjoon and other judges' problem solving records.

The output is a single image. The README shows it in the form a user would paste into a profile README, which is a markdown image link pointing at the service with the judge's handle in the query string, wrapped in a link to the profile on solved.ac. The badge renders the user's rank tier, and the README documents six tiers with a screenshot for each: Ruby, Diamond, Platinum, Gold, Silver and Bronze. The tier is the badge's whole content, so the visual variety across the six screenshots is a palette change rather than a data change.

The interesting part is the aesthetic. The word in the project name and the description is about looking good, and the README's own screenshots are the argument. A solved.ac account is a record of solved problems, and a tier badge turns that record into something a reader of a GitHub profile sees in a second.

The audience is narrow and obvious: competitive programmers and problem solving hobbyists who also have a GitHub profile README, which is the standard place to show off a coding profile.

Three endpoints and the refresh interval you get

The service exposes three URL shapes, one per visual version, and each is a path prefix on the same host. The base one is at /api/generate_badge with the handle in the boj parameter. The v2 version is /api/v2/generate_badge with the same parameter, and the mini version is /api/mini/generate_badge with the same parameter again.

The mini endpoint additionally accepts a second parameter, c, which the README's own example passes as a colour choice. The example badges at the top of the README use it in one case and omit it in the others, so the parameter is optional.

The update cadence is the operational detail and it is stated as a caution at the top of the README. The v1 and v2 versions update at one hour intervals, and mini updates at one day intervals. That is the trade the three versions offer: the full versions are fresher, and the mini version is cheap enough to regenerate daily.

The README also explains how to see the animation again. If it has loaded and you want to watch the animation repeat, you press ctrl + shift + R for a hard refresh. That is a small thing to document and an instructive one, because it tells you the badge is animated and that the animation is rendered client side, so a browser cache is all that stands between a reader and a stale frame.

For a person who solves a handful of problems a week, the daily cadence of the mini badge is more than sufficient, and the hourly cadence of the full badge mostly buys a badge that looks fresher than it is.

A Django service with an api package and a Procfile

The repository layout shows a Django project deployed as a service. There is a manage.py, an api/ package, a mazassumnida/ package holding the project settings, a requirements.txt, a pyproject.toml, a Procfile and a runtime.txt.

The Procfile plus runtime.txt combination is the Heroku shape, and the pyproject.toml confirms a gunicorn dependency, so this was designed to run as a WSGI application on a platform that starts one process per dyno. The api/ directory holds the request handling and the badge rendering, and the mazassumnida/ directory is the Django project configuration around it.

The dependency list is more revealing than the layout. requests and httpx with the http2 extra are both present, and so is curl_cffi, which is a client that impersonates the TLS fingerprint of a real browser. Having all three in one project suggests two things: the service fetches solved.ac pages over HTTP, and it does so with a client that can look like an ordinary browser to the site it is scraping, with httpx and requests serving different needs such as one path using HTTP/2.

The pinned requirements.txt is the older generation of that stack, with django 3.1, requests 2.24.0, gunicorn 22.0.0, httpx 0.23.0 and curl_cffi 0.5.5, plus the transitive pins that come with them. The pyproject.toml is the newer description, with python ^3.7, django ^3.1, requests ^2.24.0, gunicorn ^22.0.0, httpx with http2 at ^0.23.0 and curl_cffi ^0.5.5. The two files agree, which is a good sign for a project this small.

The consequence for anyone running it is a Django 3.1 and Python 3.7 era stack, which is a floor rather than a modern baseline.

Running it locally with Poetry or pip

The install section gives two paths, and both end with the same Django development server command, which is a useful sign that the project has one entry point rather than several.

The pip route is a single install followed by the server command:

pip install -r requirements.txt

The Poetry route is three steps, install the dependencies, enter the virtual environment, and start the server, which the README writes as poetry install, poetry shell and then the runserver command. The two routes exist because the project ships both a pyproject.toml and a requirements.txt, and the pinned file is the one with exact versions.

The pinned dependency set looks like this:

django==3.1
gunicorn==22.0.0
requests==2.24.0
httpx[http2]==0.23.0
curl_cffi==0.5.5

Neither path needs configuration beyond the dependency install, which means the project is simple to get running from a clone. The manage.py entry point confirms the Django structure, and the runserver command gives you a local instance to point a markdown image at while you iterate on the badge design.

What the documentation does not spell out is where the upstream solved.ac data comes from and how the badge image is produced, whether by rendering a template to an image or by returning an SVG. The api/ package is where that logic lives, and reading it is the fastest way to know whether you can re-render the badge with your own data, for example for a judge the service does not cover, or whether the rendering is hard-wired to a specific source.

Maintenance, licensing and the state of the deployment

The repository is not archived, and the last push was on 2026-04-13, which is more than six months before the present date. There are no GitHub releases, so the version history of the service is not visible in the repository, and the README's own version labels, v1.0, v2.0 and mini, refer to the badge designs rather than to published releases.

The licence identifier for the repository is not recorded. The README does not carry a licence section, and the top level of the repository has no LICENSE file, only the .gitignore, the Procfile, the README, the api and mazassumnida packages, manage.py, pyproject.toml, requirements.txt and runtime.txt. That is worth knowing before you do anything other than embed the badge: the code is readable and the deployed service is public, but the terms under which the source may be reused are not stated. This review does not give legal advice, and the practical step is to ask the author rather than assume the permissive default.

The hosted instance is the part that carries the risk in this project. Your README embeds an image from a third party domain, so the badge is only as available as the service, and only as fresh as the cache in the reader's browser and the CDN in front of it. A reader with the badge cached sees a snapshot from whenever it was fetched, which for the mini version could be a day old.

The documentation also includes a per-tier set of screenshots, which means the design of each tier is a deliberate thing that was iterated on rather than an accident, and that is why the visual quality is the project's actual differentiator.

Where mazassumnida is the wrong tool

The first case is a README that has to keep working. If your profile is on a company page, a conference site or a repository that people rely on for information, a badge that depends on a third party server is a single point of failure for a decoration. The same judgement applies to a printed or archived copy of your README.

The second case is a person who wants the badge without the service. A static image generator, run locally and committed to the repository, gives the same visual result with none of the availability risk, at the cost of it going stale until you re-run it. The trade here is freshness against reliability, and mazassumnida has chosen freshness.

The third is privacy. The service receives the judge handle on every request, and it is a hosted service operated by one person, so a request log can link your handle to the visits to your profile. That is a small amount of data and probably not a concern for most competitive programmers, but it is a fact rather than an assumption.

The alternative worth comparing is not another badge service, it is the solved.ac site itself. A link to your solved.ac profile in the README gives a reader the full record, the tier, the rating history and the solved problem list, rather than one rendered image, and it never goes stale. What the badge adds is that a reader sees your tier without clicking, which is the entire value proposition and is real, but it is a single glance of information that a link can also give in one click.

Editorial conclusion

mazassumnida fits a competitive programmer who wants a solved.ac record in their GitHub profile README and is happy to depend on someone else's hosted service for the image, since the three endpoint versions let you trade badge detail against refresh rate. It is the wrong choice for a README that must keep working when the service is down, for a person who wants the badge generated locally with no third party involved, and for a long-lived project that needs an uptime guarantee. Before embedding it, check the update interval against how often you actually solve problems, since the v1 and v2 badges refresh hourly while mini refreshes daily, and pick a version whose payload you would be comfortable hotlinking from your profile.

Frequently asked questions

Official sources

1. Issues
2. mazassumnida/mazassumnida on GitHub
3. README