The Manual

Protocol Overview

So here's the deal. AshcrestHQ isn't a company, at least not in the traditional sense. It's a handful of people who got tired of building things that disappear behind a login screen or a paywall the moment they're finished. Everything we make gets published, warts and all, from the first messy commit to whatever it eventually turns into.

That means you can read the code for Janus right now and see exactly how a microkernel handles memory allocation. You can pull up Aegis and see how anti-raid detection actually works under the hood instead of trusting a marketing page that says "advanced security." Nothing here is a black box, and honestly, we think that's how software should work more often than it does.

What We're Building

So here's the deal. Right now there are three main projects, and they're pretty different from each other.

Janus is an operating system. Specifically, it's a microkernel written in Rust, built around the idea that nothing on the system should be trusted by default. Every single action needs an explicit permission from the kernel, no exceptions. It's still early days for Janus, there's no filesystem yet and no shell, but the core security model actually works and we've stress tested it to prove that.

Aegis is the more approachable entry point if you're not into low level systems work. It's a Discord bot written in Java that handles security auditing, anti-raid protection, an AI assistant, and even runs music through voice channels.

Holocron ties the two together. It's a CLI that teaches security fundamentals and real open source contribution skills side by side, so if you finish enough of it, you're not just learning, you're actually ready to open a PR on Janus or Aegis.

Contributing to AshcrestHQ

Every line of Aegis and Janus exists because someone sat down and decided to write it. That's not a metaphor, it's literally true, since this whole thing started with just a couple of friends. If you fix a typo, that typo stays fixed because you fixed it. If you squash a bug, that bug is gone because of you.

Here's roughly how it goes once you find something you want to work on. Fork the repo, make a branch with a name that actually describes what you're doing, and get your changes working locally. When you open a pull request, write a description that explains what changed and why, not just what file you touched. A maintainer will look it over, usually within a few days depending on how big the project is at the time, and they might ask you to tweak something. That's normal. Nobody's first PR gets merged without a comment or two, and that's not a bad sign, it just means someone actually read your code.

What Can You Contribute?

Reporting Security Issues