NilLoaderSDK Is Becoming NilKit API — A Temporary Pause and a Necessary Change
Project UpdateEnglish6 min read

NilLoaderSDK Is Becoming NilKit API — A Temporary Pause and a Necessary Change

Aug 6, 2026TamKungZ_1219 words
Summary

NilLoaderSDK is being temporarily taken offline and renamed to NilKit API after concerns that its original name and branding could be mistaken for an official NilLoader project.

NilKit APINilLoaderMinecraft moddingopen sourceproject updatebranding

NilLoaderSDK Is Becoming NilKit API — A Temporary Pause and a Necessary Change

An update about the project name, its relationship with NilLoader, and what happens next.


A Change I Need to Make

I am temporarily taking NilLoaderSDK offline while I make a number of changes to the project.

When it returns, it will no longer be called NilLoaderSDK. The project will be renamed to NilKit API.

This change follows a discussion with the maintainer of NilLoader about how the project was being presented and how easily the name and branding could cause confusion.

I want to be clear about something from the beginning: I did not intend to impersonate NilLoader, claim ownership of it, or present my project as an official component of NilLoader.

But intent does not erase the fact that the name I chose could reasonably give people that impression.

That part is on me.


I Got the Naming Wrong

When I originally chose the name NilLoaderSDK, my reasoning was simple: it was an SDK I had built for development around NilLoader.

From my perspective, the name described what the project did.

What I did not consider carefully enough was how the name would look from the outside.

Names such as “Fabric API” and “Fabric Loader” have trained Minecraft modders to associate similarly named projects with an official ecosystem. Because of that, NilLoaderSDK could easily be interpreted as the official SDK or API for NilLoader, or even as something required for NilLoader mods to work.

That was never what the project was meant to be.

I had already tried to explain in the documentation that the project was independent and that NilLoader remained a separate upstream project, but documentation does not completely solve a branding problem. Many people will see a project name, logo, or Modrinth page long before they read a README.

So I accept that I made a mistake in how I named and presented the project.

It was not intentional, but it was still my responsibility.


The New Name: NilKit API

After discussing the issue, I proposed the name NilKit API, and the NilLoader maintainer confirmed that this name was fine.

The new name gives the project its own identity while still making sense for what it is: a collection of APIs, utilities, and development tooling intended for projects that use NilLoader.

Most importantly, it removes the implication that this is an official part of NilLoader itself.

Going forward, the distinction will be much clearer:

  • NilLoader is the original mod loader and Java agent project maintained by its own developers.
  • NilKit API is my independent community project that builds optional tooling around it.
  • NilKit API is not official, not required by NilLoader, and not a replacement for NilLoader.

The original NilLoader project can be found here:

git.sleeping.town/Nil/NilLoader


Why the Project Is Going Private Temporarily

Rather than changing only the repository title and leaving a mixture of old and new branding around the internet, I want to do the migration properly.

For that reason, I am temporarily making the project unavailable while I review and update everything associated with the old identity.

This includes, where applicable:

  • The project name
  • Repository names and descriptions
  • Package and artifact naming
  • Mod IDs and metadata
  • Documentation
  • GitHub organization branding
  • Modrinth information
  • Logos and visual identity
  • References that could imply an official relationship with NilLoader
  • Internal implementation choices that deserve another review

I would rather take the project offline for a short period and bring it back consistently than leave half-renamed pieces scattered across different services.

This is a pause for cleanup, not the end of the project.


The Technical Side Also Deserves Another Look

The discussion was not only about the name.

Some parts of the project relied heavily on NilLoader internals through reflection and attempted to provide additional bootstrapping behavior around NilLoader’s normal machinery.

Even if those techniques can work today, internal implementation details are not a stable public API. They may change at any time, and relying on them too heavily creates unnecessary compatibility risks for both the project and its users.

I am willing to maintain compatibility when things change, but that does not mean every workaround is a good architectural decision.

So while the project is private, I will also use the opportunity to reconsider those parts instead of treating this as a cosmetic rename only.

The goal remains the same: make developing with NilLoader more convenient without trying to become NilLoader itself.


Why I Built This in the First Place

NilKit API exists because I personally encountered problems and repetitive work while developing with NilLoader.

My reaction was the same one that has started countless open-source projects: build the tool I wished I already had.

I still believe there is value in community tooling around a small, flexible project like NilLoader. Things such as development APIs, Gradle tooling, mappings support, installers, documentation, and utilities can make an ecosystem easier to approach without replacing the foundation underneath it.

I also still believe that improving and extending existing open-source software is often more useful than creating another competing implementation simply because something is difficult.

But building around someone else’s project also means being careful about where that project ends and mine begins.

That distinction should have been clearer from day one.


About AI

I also want to address this directly because it came up during the discussion.

Yes, I use AI tools as part of my development workflow.

I use them to help research ideas, review code, draft documentation, explore implementations, and speed up repetitive work. I do not consider that something that needs to be hidden.

At the same time, I am responsible for what I publish.

If an AI-generated suggestion is incorrect, if I choose a bad architecture, if documentation is misleading, or if a project decision causes problems, that responsibility belongs to me. An AI tool does not maintain the repository, make the final decision, or take responsibility for a release. I do.

That applies here as well.


What Happens Next

For now, the GitHub and Modrinth presence associated with the project will be temporarily restricted while I complete the transition.

When the project returns, it will return as NilKit API, with a new identity and clearer separation from NilLoader.

I will also review related tooling individually rather than assuming that the same naming or branding decisions are appropriate for every project.

There is no exact reopening date yet. I want to finish the cleanup properly before making everything public again.


A Final Note

I want to apologize to the NilLoader maintainer and to anyone who was confused by the original name or presentation.

There was no intention to take over the project, pass my work off as official, or diminish the work of the people who created NilLoader.

I should have contacted the maintainer earlier instead of making assumptions about how close my project’s identity could be to the upstream project.

I appreciate that the concerns were raised directly, and I would rather correct the problem now than allow the confusion to continue.

NilLoaderSDK is going away as a name. NilKit API will take its place.

The idea behind the project is continuing — just with a clearer identity, a cleaner boundary, and more respect for the project it was built around.


Built and maintained by TamKungZ_.