AliyevECO: The Sovereign Developer Ecosystem Behind AladdinAI
Four open-source projects that together form an alternative to the rented developer stack — from hardware to AI.
AliyevECO: The Sovereign Developer Ecosystem Behind AladdinAI
Four open-source projects that together form an alternative to the rented developer stack — from hardware to AI.
You Probably Came Here for AladdinAI
That's fine. AladdinAI is the project most people find first — self-hosted multi-agent AI workspace, 436 organic cloners in 14 days, real product with real code on GitHub.
But AladdinAI is one of four projects.
And the reason it exists in its current form is because of the other three.
This post is for the developers who tried AladdinAI and wondered: what is this part of? What's the bigger thing?
The bigger thing is called AliyevECO.
The Core Idea
Modern software is built on layers we don't own.
We use macOS or Windows. We code in VS Code or Cursor. We commit to GitHub. We deploy to AWS. We chat in Slack. We use Copilot, ChatGPT, Claude.
Every layer is rented from someone who can change the terms tomorrow.
AliyevECO is what happens when you decide to build the alternative — not just for one layer, but for the whole stack.
Four projects, four layers, one philosophy:
| Layer | Project |
|---|---|
| Intelligence Layer | OSINT Tools |
| Application Layer | AladdinAI |
| Hardware Layer | Aurora ARM64 |
| Foundation Layer | RCF Protocol |
Alternative compact list:
INTELLIGENCE LAYER → OSINT Tools
APPLICATION LAYER → AladdinAI
HARDWARE LAYER → Aurora ARM64
FOUNDATION LAYER → RCF Protocol Let me walk through each.
Project 1: RCF Protocol
The foundation. Not the most visible, but the most important.
RCF stands for Restricted Correlation Framework. It's a licensing protocol that protects methodology from being extracted and replicated by AI systems.
The Problem It Solves
LLMs are extraordinary at pattern correlation. Show them your codebase, your documentation, your design decisions — they will reconstruct the thinking behind them.
That thinking — the architectural decisions, the trade-off philosophies, the unique way your team approaches problems — is often the single most valuable thing your company owns.
GPL says "you can use this, but you must share derivatives." MIT says "you can use this however you want." Neither addresses the modern question: can someone use an AI to systematically extract the reasoning behind your code, then replicate it without ever copying a line?
RCF says: no.
How It Works
NPM and PyPI packages that sign your code with cryptographic markers
Legal framework — DMCA, WIPO, with established precedent for what counts as violation
Boundary contract — defines what AI systems may and may not do with marked code
Audit service — \(19/\)99 paid tier for legal-grade verification
It's not DRM. It's not anti-AI. It's a boundary contract for the AI era.
Why It's First in the Stack
Because every other project in AliyevECO is itself RCF-protected. The methodology behind Aurora, the architecture of AladdinAI, the OSINT collection techniques — all under RCF.
The protocol eats its own dogfood.
Project 2: Aurora ARM64
The hardware layer. Where the philosophy gets uncomfortable.
Aurora is a bare-metal, ARM64-native operating system built from zero.
Not a Linux distribution. Not a Unix derivative. Not a fork of anything.
A new substrate.
Why Build an OS in 2026?
Look at any modern "smart" device — IoT sensor, embedded controller, sovereign identity chip. They all run Linux derivatives designed for 1990s server hardware and bolted onto silicon that doesn't understand them.
The result: bloated firmware, security holes, compromise-once-pwn-everything architecture.
Aurora was built for the substrate it lives on:
C kernel, bare-metal, no Unix tax
A-Code VM — custom byte-code, only named state, no stacks or registers
Biological memory model — modules as tissues, bus as nervous system, opcodes as reflex pathways
Pure Intelligence doctrine — no general-purpose computation that wasn't explicitly designed in
Applications
Where you'd use Aurora today:
IoT and embedded systems that need to be sovereign by architecture, not just by policy
Sovereign identifiers — SIM cards, banking chips, biochips designed as extensions of the nervous system
Air-gapped sensors that must not be compromisable from the host they connect to
AR/VR substrate when you can't accept Apple/Meta's framework lock-in
This isn't theoretical. The kernel runs. The VM works. The doctrine — Trinity of Body, Mind, Witness — is implemented in C, not in slides.
The Sovereignty Principle in Aurora
Aurora has zero hardware access functions. None.
All hardware operations route through RCF Protocol → rcf-firmware on a separate chip (STM32). This means a compromised Aurora is cortex without hands — it has the reasoning, but no way to act on the world.
This is dual-use sovereignty:
Externally: RCF protects from LLM correlation attacks
Internally: RCF protects from Aurora-to-hardware compromise paths
Aurora is subject by architecture — closed on both interfaces by design.
Project 3: AladdinAI
The application layer. The project you probably came here for.
I write about AladdinAI more than the others on this blog because:
It has the most users
It's where most of the daily building happens
The architecture is most ready for public scrutiny
So I'll keep this section short — there's a full architecture deep-dive coming next on this blog.
What It Is
Self-hosted, multi-agent AI workspace. The idea: what if AI tooling was something you owned, not something you rented?
Multi-agent with three-tier memory (private per-agent, shared per-user, conversation summaries)
Vector recall via MongoDB Atlas
Tools registry with
@tooldecorator (no LangChain)Safety stack: NemoGuard, GLiNER PII, Llama Guard
Channels: Telegram, WhatsApp, Email, SMS
Terminal-in-browser for remote server access
Provider-agnostic LLM — bring your own NIM, OpenAI, Anthropic, Ollama
How It Fits the Ecosystem
AladdinAI consumes the other three:
RCF Protocol signs every outgoing webhook from AladdinAI agents
Aurora is the target deployment substrate for sovereign installations
OSINT Tools feed threat intelligence into AladdinAI security agents
Setup is one command: npx aladdin-ai Or one-click deploy to Render — button in the README.
Project 4: OSINT Tools
The intelligence layer. The smallest project, and the one I talk about least.
Open source intelligence tooling for security researchers and threat analysts.
The Problem
Existing OSINT tools are either:
Ancient — Maltego, FOCA, old Python scripts
Expensive — Recorded Future, ThreatConnect ($50k+/year)
SaaS-only — which is hilarious for an intelligence tool, because you're sending your queries to someone else's database
If you're doing threat research, the absolute last thing you want is to phone home to a third party every time you query an IOC.
What It Does
Self-hosted threat intel aggregation
OSINT collection from public sources
Defensive security tooling for SOC and IR teams
Integration hooks for AladdinAI agents (automation)
Why It's Part of the Ecosystem
Because the security mindset that built RCF and Aurora is the same mindset that builds OSINT tools.
If you genuinely believe in sovereignty, your security tools must also be sovereign. Otherwise you're protecting your stack with someone else's stack.
How They Reinforce Each Other
This is the part most "ecosystems" get wrong. They have multiple products, but the products don't actually need each other.
AliyevECO is different:
RCF Protocol ├─ protects code from LLM extraction └─ used by: Aurora, AladdinAI, OSINT (everything)
Aurora ARM64 ├─ sovereign substrate └─ deployment target for: AladdinAI, OSINT sensors
AladdinAI ├─ application layer ├─ uses: RCF (webhook signing), Aurora (sovereign deploy) └─ feeds OSINT data into agents
OSINT Tools ├─ intelligence collection ├─ runs on: Aurora (air-gapped sensors) └─ feeds into: AladdinAI agents
Each project gets more valuable because the others exist.
This is what network effects look like for open source. Not "users of one product also use the other." But: product A becomes structurally more useful because product B exists.
The Philosophy in One Sentence
Developers should be able to switch, fork, audit, and own every layer of their stack — when it matters.
Most of the time, you'll choose convenience. Cursor, GitHub, AWS. That's fine.
But when context shifts — compliance audit, geopolitical risk, vendor pricing change, philosophical alignment — you should have somewhere to land.
AliyevECO is somewhere to land.
Who This Is For
Not everyone.
If you're happy with the rented stack — AliyevECO isn't for you, and that's fine.
If any of the following describe you, we should probably talk:
You work in a compliance-heavy industry (finance, healthcare, defense, gov)
You build embedded systems and need a sovereign OS option
You ship code with valuable methodology you don't want correlated
You're doing security research and don't trust SaaS intelligence tools
You feel the gradient toward Big Tech dependency and want to row against it
What's Next on This Blog
Now that AliyevECO is mapped publicly, here's what's coming:
AladdinAI Architecture Deep-Dive — the memory layer, in detail
Aurora First Principles — why we don't use stacks or registers
RCF in Practice — how to mark a codebase
OSINT Toolkit Walkthrough — for security researchers
I'll alternate between deep technical posts and philosophy posts, one per week.
How to Engage
If this resonated:
AladdinAI is most ready to use today — github.com/aliyevaladddin/AladdinAI
Subscribe to this blog for weekly posts
Open an issue if you want to challenge any of this — out loud, in public
The goal isn't to convince everyone. It's to find the developers who already feel it.
Aladdin Aliyevaliyev.site
The four projects:
🤖 AladdinAI — GitHub
🌑 Aurora ARM64 — auroraaccess.site
🛡️ RCF Protocol — aliyev.site/rcf
🔍 OSINT Tools — aliyev.site/osint
