Hey everyone, I recently published <kiit-codes>, a...

# opensource

[kishore]

Hey everyone, I recently published kiit-codes, a library i've been working on and off on for years ( pre-AI ).
It's a small taxonomy for classifying success and failure into named groups (Succeeded, Restricted, Invalid, Rejected, ...)
Think HTTP status codes, but generalized and usable at any layer, not just HTTP.

Notes
1. Extensible: Status and Group are fixed, Code is open and extensible for your own domain, with sensible defaults so nothing's required up front.
2. Usability : The same taxonomy works as a plain API status, in validation, exceptions, or a Result<T, E>
3. Protocols : There are converters for HTTP and gRPC too, validated against every gRPC status code and the common HTTP ones.
kotlin

implementation("dev.kiit:kiit-codes:1.0.3")

1. GitHub: github.com/kiitdev/kiit-codes
2. Docs: kiit.dev/docs/kiit-codes
Would genuinely love feedback, whether the classifications make sense, or anything that seems off or missing.
I can answer questions here too.
Thx!

[Bernd Prünster]

I really like the idea! would be interesting to map it to other, more complex protocols, to see if tier 2 really is generic and expressive enough. It sure seems like it, but throwing it at some auth protocol would be really something. Probably the perfect job to automate using AI and still get reliable results

[kishore]

Hey @Bernd Prünster, appreciate this, definitely the kind of feedback I was looking for. I spent a lot of time on the Tier 2/Tier 3 codes to make sure they're broad yet expressive enough to accommodate different protocols / use cases. There's also an "origin" field that can designate where a code came from, like "kiit" or "myapp1."

The thinking around the Failed Groups was:
1. Restricted = security/permission related
2. Invalid = request/client related
3. Rejected = server/business/domain rules
4. Unserved = operational issues.
Security/auth is a good callout. I'm familiar with OAuth, but if a different protocol comes to your mind as a better stress test, I'd be curious. These could map to the Tier 2 groups above with custom codes plus origin = "OAuth."

I'm putting together a blog post soon and thought an example from someone in security would be great, so if you're ever up for it, happy to chat and credit you however you'd like. Totally fine if not, just wanted to put it out there.

Thanks again.
-K

[Bernd Prünster]

OAuth would be a prime candidate, I fully agree! I'd like to discuss the kiit-codes and the idea it represents internally. In addition, I think your concept would tie in naturally with rfc-editor.org/rfc/rfc9457.html?… and should definitely do so!

The main issue I see in general is that without a good amount of dogfooding and external usage, you'll never know how well it bridges the gap between covering everything well enough and being generic enough to fit basically whatever; and that means cross-domain usage. Rooting this in HTTP error codes is mos def the right starting point and abstracting from there (which feels like you did), because HTTP has pretty much succeeded TCP as de-factor transport protocol, so millions of services and apps already to a mapping from HTTP to their domain-specific foo.
I especially see the strength of your concept in distributed, heterogeneous systems and microservice deployments, which only strengthens the case for OAuth. Also OAuth is a complex beast with a billion backs bolted on. So getting that to work well with kiit codes (and a good documentation to explain the mapping) will probably be the first real sink-or-swim moment outside the initial domains of HTTP and gRPC

[kishore]

Hey @Bernd Prünster, thanks for calling out that RFC 9457! Turns out this is the third time it's come up independently while working on this, you, myself, and even AI tooling all landed on it separately, which made it worth taking seriously. I'd looked at it initially and made kiit-codes somewhat aligned, but not fully, so I sat down, thought deeply about it and worked through a much more comprehensive alignment and compatibility approach to the RFC. Putting the changes together now, with a release coming in a few days. Really appreciate the reference to it.

Regarding OAuth, the updates above are likely going to further facilitate supporting other protocols/codes. I'm thinking of it as an "extension pack" on top of the foundation. Might have a tentative design and example ready in a week or so, on the repo or docs page, happy to ping you if you're interested in taking a look.

[Bernd Prünster]

Sure. Keep me in the loop