IndieBiz OS
The shared warehouse — a media network for the age when AI does the reading. And the personal AI OS that fills and reads it.
Homepage | English | 한국어
IndieBiz OS has two axes. One is an AI agent system — a personal OS that compiles plain language into an action language (IBL) and hardens frequent work into apps you own. The other is the shared warehouse — something that doesn't exist anywhere else, and simple enough to explain in a paragraph. So this README starts with the warehouse.
The shared warehouse — a media network without platforms
You put a file in a folder. That is the entire act of publishing. The 공유창고/0..4/ folders on your disk are served live at your node's public address — no index, no conversion; the filesystem is the truth. Humans open it in a browser; other people's AI agents read it through /manifest (JSON).
Platforms were shelving for humans
YouTube, blogs, Twitter, and shopping malls exist as separate services not because the data differs in nature, but because humans can't handle raw data, so someone had to pre-build — and monopolize — a different shelf (UI) for each kind. The moment an AI stands on the reading side, that premise dissolves: rendering happens at visit time, on the reader's side. So one warehouse becomes whatever you put in it:
| What you put in | What the warehouse becomes |
|---|
| videos | YouTube |
| writing | a blog · Twitter |
| a product catalog | a shopping mall |
| a list of services | a freelance network |
A broadcast station and a shop at once — and format-free (schema-on-read): the warehouse serves bytes (a PDF as a PDF, a spreadsheet as a spreadsheet), and interpretation is the reading AI's job.
The asker pays
The old web made the host pay for querying, rendering, and delivery — which is why a crowd of visitors melts the owner's server. The warehouse inverts it: the owner only places files; the searching, filtering, and rendering are computed by the asker's AI, on the asker's hardware. Serving costs the owner ~nothing. That's also why there is no CAPTCHA: the web blocks bots as a symptom of server-pays economics, but here a reading AI brings its own compute, so the door never asks "human or bot?" — only "who are you?" (identity and level).
The number on the folder is the gate
A visitor's level (0 → 4) is the same scale as their grade in your neighbor CRM — promote someone once and it applies to messaging, portal membership, and the warehouse alike. A viewer sees levels 0..their level merged into one flat list (same name: higher level wins), and a file above their level returns 404, not 403 — existence itself is information. The one deliberate leak is a single has_restricted flag, a smell: "there is more here," with no names or counts. Since the security is the level, the address needs no hiding — the front door stays confidently open.
/manifest — the machine face, and a very small protocol
Beside the human page, the same listing is served as JSON — a title, files with sizes, mtimes and direct URLs, has_restricted, a self-describing about, and a login block stating exactly how to authenticate. A foreign AI agent reads your node without scraping HTML or reverse-engineering anything.
And that is the entire contract of the face: GET /manifest + GET /f?path= + a cookie login. Just HTTP and files — no IBL, no cognitive pipeline, not even IndieBiz OS itself is part of the contract. Any AI system can implement the same face in an afternoon, and that's the point: like RSS and TCP/IP, the interfaces that win are boringly small.
The reading half — a neighbor feed, and reposts as files
Register a neighbor's warehouse and a poller fetches their /manifest every 30 minutes, diffing paths and mtimes into a timeline — seed on the first poll (their back catalogue, like seeing past posts right after a follow), then new and changed. The retained snapshots double as a filename index of your whole neighborhood, so one search sweeps every neighbor's warehouse at once. This layer is pure machine — zero model calls, zero tokens: collecting the scent is mechanical; interpreting it is the AI's job.
A neighbor doesn't have to run IndieBiz OS. Under the poller sits a dialect-adapter layer that normalizes nginx/Apache directory indexes, RSS/Atom feeds (auto-discovered from HTML), Nextcloud public shares, and even the file links on an ordinary web page into the same manifest currency — someone becomes a neighbor without installing anything. A blog's RSS or a file server's index subscribes as-is, so the entire existing web is a potential first neighbor — the network doesn't start in an empty room.
Once adapters existed, the problem inverted: the world is already full of warehouses and there was no way to look at them. So finding neighbors now has two halves — an inbox for people who introduced themselves, and browsing: a genre-tagged directory of warehouses you don't know yet (a live parse plus a seed list you can edit). A neocities adapter joined the dialect layer, which makes 1.69 million personal homepages warehouse candidates. And you can hand one neighbor to another: a public recommendation where the machine fills in only the facts and you rewrite it before it goes out — the body follows a small convention (Warehouse : <url>), so on the receiving side an "＋ add" button appears right there in their neighbor-finding tab.
A warehouse address isn't a separate address book — it's stored as one more contact type on a neighbor, right beside their email and Nostr key (someone you only know by address is still a proper neighbor). A repost is a standard .url shortcut file dropped into your own warehouse; when your manifest is served it resolves to the original, so a subscriber's click goes straight to the origin warehouse, never through you. Friend-of-a-friend discovery, implemented not as a protocol but as a file.
Subscription doesn't stay anonymous (level 0), either. Warehouses serve a join page; sign up or log in through the in-app browser and the credential is captured on the spot — no copying it anywhere by hand. From then on the poller logs in through the manifest's login contract, so files at your granted level flow into your feed and search. Expired or revoked cookies re-login automatically, and if login fails the poll continues anonymously (the feed never stops). There is no separate key exchange: the credentials you made at signup are the key.
The AI fills it — production is publication
What this system's agents produce is published the moment it is made. Daily schedules use checked, stored IBL functions to drop the morning newspaper, an AI trend report, and the latest blog post into the warehouse, and business items (Sharing · For sale · Can do …) are auto-materialized from the DB into garage-sale shelves — each item becomes a document plus photos in a warehouse folder, so an outsider browses your whole catalog without ever asking. The intro document ends with an automatically attached way to reach you (your Nostr address). To subscribing neighbors, all of it flows past like tweets.
The easiest live example — a sharing economy
Put something you're giving away under Sharing: it appears in your neighbors' feeds → a neighbor's AI recognizes the match → one DM → hand it over. The whole loop closes with no payment layer — the first practical case. Selling and commissioning are the next chapter, to be built on top.
Filling this warehouse — and reading and interpreting your neighbors' — is ultimately an AI's work. From here on, this README is about that AI: the second axis, the agent system.
In one minute
IndieBiz OS turns plain language into a real action language — IBL — that runs on your own desktop and phone, and lets the things you do often harden into one-tap apps you own. No app store, no cloud account, no code.
You say what you want. How you say it depends only on how often you do it:
| You want to… | You get… | Surface |
|---|
| "Find lease listings near Gangnam under 500M and put the top 5 in a report" — a one-off | the AI discovers the steps and just does it | Autopilot |
| the same kind of task, repeatedly | a lightweight model translates it into a reusable program you inspect and keep | Cockpit |
| a task you do every day | it crystallizes into an icon you tap — 0 tokens, instant — even on your phone | App |
One system, one person, from a one-off question to a superapp you authored just by using it. It starts minimal and grows only what you ask for; an AI agent is the blacksmith who keeps forging it to fit you.
New here? → What it actually is · See it on a phone · Install in 3 lines
The one idea
Most AI harnesses get more capable by reaching for more intelligence — a bigger model, a longer prompt, more tools. IndieBiz OS makes a different bet:
Handle complexity with structure, not more intelligence — because structure is the one layer no foundation model absorbs.
A better model keeps absorbing how to produce an action. It never absorbs where the action lives, who owns it, how often it repeats, or whose body it runs on — that's the life around the generation, and it's where IndieBiz OS works.
That bet rests on two generative cores. Almost everything distinctive about the system falls out of them — so instead of listing fifty features, this README shows the two roots and lets the features hang off them as consequences:
- There is a real language underneath — IBL. A small, regular vocabulary that every part of the system compiles to.
- A clean seam between the vocabulary and the body. What a capability is stays separate from which machine runs it.
If you grasp those two, you can re-derive the feature list yourself. That's the point.
What it aims to be — a wearable robot, not an autopilot
Most harnesses aim at autonomy: give a destination and the AI drives there on its own — you specify, you receive. IndieBiz OS aims to be a cognitive exoskeleton you wear. It absorbs your settled judgment so repeated work happens almost unconsciously, freeing your conscious attention for what doesn't repeat. And it doesn't need a clear destination up front: for the deepest work — research, writing, building, deciding what you even want — the goal isn't given then pursued, it's discovered in the pursuit. Autonomy treats the destination as a precondition; an exoskeleton treats it as a product — co-authored step by step, with you still holding the judgment.
So the development north star is fit (착용감): the exoskeleton disappearing into intention; trials made cheap enough that your taste drives a tight loop; your judgment reaching further — not you doing less. Success is the fruit you couldn't have made bare, never how little of you was needed. A self-driving car's endpoint is to delete the driver's seat; ours is to make the seat worth sitting in even when the system can drive itself. (Full vision: data/system_docs/vision.md.)
Philosophy — a system you raise, not one you're given
IndieBiz OS is not software you install and use as-is. It's a living system — like armor forged to fit your body, or a horse you raise and ride yourself. An AI agent sets up the skeleton, asks about your life, and starts building — but the system only becomes yours through use. Your habits shape it; your needs grow it.
No two installations are the same. A freelancer's system looks nothing like a small-business owner's; hand yours to someone else and it wouldn't fit. It starts minimal — only the core (IBL engine, cognitive pipeline, hippocampus) — and grows on demand: say "track my investments" and the investment package appears. No app store, no mandatory update, no one-size-fits-all. Your AI agent is the blacksmith who keeps forging it as you grow.
Only the body is hardcoded; the world is held provisionally. The only nouns this system fixes are the body's vocabulary (sense, self, limbs, others). Knowledge about the world — people, places, things, relations — lives not in a schema but in memory, as sediment that carries confidence scores and staleness marks and is allowed to be wrong. This is the opposite of enterprise ontologies, which model the world up front and then pay forever to keep the model current — here, use itself keeps rewriting the world-picture. (Constitutional clause: "The Place of Nouns" in data/system_docs/ibl.md.)
And one day these individually raised systems find each other — connecting over decentralized networks, each unique but speaking the same language. That is the vision.
Why this shape — the whole spectrum, not one end of it
People want two different things from AI, and the market sells them as separate products. One crowd wants autopilot: say it, the AI does it — fast, but you own nothing afterward and pay full price every time. Another wants the artifact: code-generation agents hand you something durable — but it's code, and code needs a production environment (terminal, server, hosting) to run.
A single person doing real work needs both — and a third thing between them — as one continuum, not three purchases:
- one-off, exploratory work → autopilot (let the model discover the steps)
- recurring work → functions (natural language compiles to an IBL program you keep)
- daily work → an app (an icon that runs deterministically, 0 tokens)
No single task needs all three; a single life does. The market doesn't sell the continuum not because it's unwanted, but because it only collapses into one product at personal scale. In a company the three stages split across three roles — developers generate, ops run automation, users tap apps — three people, so three products. Put all of it in one pair of hands and it has to be one system. Single-user isn't a limitation here; it's the condition that makes the spectrum coherent. That is what "IndieBiz" means.
It arrives as a link, and installs anywhere
The clearest demonstration is IndieBiz OS on the device already in your hand — and you get it there with a link, not an install. The remote launcher serves the same surfaces the desktop has — autopilot, cockpit, apps, your shared warehouse, and the foraging browser — to any browser: Android, iPhone, iPad, an old tablet propped up in the kitchen, a laptop you borrowed for the afternoon.
Then, if you want, it stops looking like a browser tab. The launcher ships a web app manifest, so "add to home screen" makes it an app — its own icon, its own name, no address bar, its own entry in the app switcher. Two taps on Android or iOS. Nothing built per platform, nothing signed, nothing approved by a store, and nothing to update. The remote finder installs the same way as a second app, IBFind, for reaching your files. Neither one caches: both are live views of a machine you own, so their service workers pass every request straight through.
That matters because a phone is a sealed consumption device: no build toolchain, no server, no way to author-and-run your own app. A code-generation agent's output strands there — an app you cannot run. IndieBiz OS's "app" is not a compiled binary but a declaration over the IBL the runtime already speaks — declare an instrument once and it renders on every surface at once, and one of those surfaces is a browser on any device you own. Authoring and running collapse into one moment, and the hardware stops mattering.
And the browser is a client, not a screen. Files cross both ways — upload from the gallery, download to the device. Audio plays out of the thing in your hand, not out of the machine that fetched the stream. The clipboard reaches your PC in one tap. The one honest condition is that your own machine has to be awake: this is your system reaching you, not a cloud renting it back to you.
The closest existing thing — Apple Shortcuts, Tasker — proves the demand is real, but it's only the bottom of the spectrum: you still hand-author each shortcut in a fixed visual language, nothing crystallizes from use, and it's bound to the OS's actions, not your context. IndieBiz OS is that on-device execution plus an autopilot on-ramp plus a vocabulary that's yours. Not "like a superapp" — the first superapp a person builds for themselves, without being a developer.
Core #1 — There's a real language underneath (IBL)
Every capability — a web search, a file write, a phone notification, a chart — composes into a program in one language, IBL (IndieBiz Logic):
$news = [sense:search]{query:"AI news"}
[self:write]{path:"result.json",content:json($news)}
Six nodes (sense, self, limbs, others, engines, table), one composable vocabulary. The point is not the size of the action list — it's that it stays small (down from 332 at its peak; current counts live in Under the hood, regenerated by the build), because related tools keep getting folded into single actions with parameter/op branching (45 bespoke Android actions became one [limbs:android]{op}). The language got smaller as it got stronger — and it is still shrinking: a 2026-08 compression pass took it from 163 to 144 while adding expressive power. Fewer, more composable verbs that a human or a small model can write one line of and have work. Because everything speaks one vocabulary, your accumulated experience forms a single coherent corpus instead of a pile of incompatible tool calls.
Three moves do the shrinking, and they are worth naming because they're the opposite of how tool catalogs usually grow:
- Delete a compound, add a universal.
[sense:pew_research] (one hardcoded URL) retired in favor of [sense:feed]{url} — the dictionary is net −1 +1, but the possibility space grew to any feed, and a duplicate parser collapsed.
- Fold same-shaped words onto an axis. Five search verbs became
[sense:search]{source}; four business-ledger verbs became [self:ledger]{store, op}. The axis has to be honest, though: contacts got folded into [others:neighbor]{op} rather than [self:ledger]{store:"contact"}, because store is the axis of peer ledgers and contacts are a child collection — putting them there would have made the axis start lying.
- Procedures aren't words; they're sentences. Anything that's only an ordering of existing verbs gets frozen as a registered script (
[self:script]) or an app instance instead of a new verb. That makes "should I add a word for this?" default to no — an anti-vocabulary-inflation device built into the language.
Once a word is justified, implementation is still only half the job. description and ops.values put what exists into the catalog every agent reads; hippocampus examples (natural-language intent → IBL code) teach which phrasing should recall it and which arguments to use. Only arguments observed in the corpus and real executions become the catalog's ⟨args: …⟩ shape. A new capability is therefore complete only when body (handler), dictionary (catalog prose), textbook (corpus), and observation (argument/return shapes) close together. Description without examples is visible but hard to recall naturally; examples without a body cannot run.
One measurement lesson from that pass, since it generalizes: a call count is not a life sign. A retired action had 19 recorded calls and had never once returned a result — the count said "invoked", not "worked". The test that survived is to open the handler and measure the replacement path.
Here is what falls out of having a real language:
→ Three surfaces for every task (the trilemma)
Because there's a compile target, the same IBL expression can be reached three different ways. Each surface takes two of {speed, expressiveness, sovereignty} and gives up the third:
| Surface | How you reach the IBL | Trade-off |
|---|
| Autopilot | A flagship model takes your intent and discovers the steps, emitting IBL as it goes. Best for new, exploratory work. | speed + expressiveness − sovereignty |
| Cockpit | A lightweight model translates natural language into IBL. You statically check it, review effects, and run it; system state, model gear, run history, and supervisory intervention live here too. | expressiveness + sovereignty − speed |
| App | An icon invokes a fixed IBL expression directly — 0 tokens, deterministic. Fastest, most discoverable. | speed + sovereignty − expressiveness |
No other harness can offer this, because no other harness has a compile target: there is nothing for the Cockpit to translate into, no stable expression to check, and nothing for an icon to invoke. The three surfaces are not a UI menu — they are a property of having a language.
→ Crystallization
Frequency moves a task between surfaces. Autopilot explores it once → its IBL trace seeds the Cockpit → a proven, high-frequency flow crystallizes into an App icon (0 tokens) on a 2D desktop you own and return to. A saved shortcut is not the same as an icon you keep — the difference is placement, and most harnesses have no launcher surface at all, so a proven flow has nowhere to live. This survives cheaper models: what you want from a daily task isn't a lower token bill — it's determinism, instant response, and control. Crystallize only what's proven.
(The Cockpit obeys two rules: side-effecting steps are gated behind explicit confirmation while read-only steps run friction-free, and the hippocampus learns only the results you approve. App instruments are declaration-driven — each is an app: block on an IBL action, and one declaration renders identically on the desktop, the remote launcher, and the phone.)
→ The place you work is an app too — documents, spreadsheets, code
Frozen IBL calls are not the only thing on the App surface. Three workspaces let you and the AI handle the same file or repository in the same place. Documents use a declarative instrument, including when opened in a separate window:
- Documents — edit DOCX, ODT, RTF and PDF in their original format (a local ONLYOFFICE editing server), and HWP/HWPX in theirs (a local open-source engine that makes no external font requests). Rotate, delete and reorder PDF pages; correct OCR and save a searchable copy; preview and export Markdown and source documents.
- Spreadsheets — workbook editing, CSV/TSV import that doesn't mangle identifiers, phone numbers or text that merely looks like a formula, format-conversion copies, printable forms, and tables that flow from a pinned sheet snapshot into a document report.
- Coding — open a repository and each task gets its own isolated workspace; an executor (a native CLI such as Codex, or a plain API model — swappable) makes the change, then it closes through verification command → diff review → approval → apply and commit.
For documents and spreadsheets, the engine only writes drafts; only your explicit save replaces the original. If the original changed underneath you, the save is refused; a late save from an editor window you already closed is dropped; versions and drafts can be restored. An AI proposal is bound to the selection you saw on screen and arrives as a tracked change — it never quietly rewrites the file. And no new vocabulary was added for any of it: agents join the same editing session through the self:document and self:sheet actions that already existed. Coding uses its own task review, approval, and apply flow.
(The honest scope: the editing engines listen only inside your own PC, so original-format editing is desktop-only, and the Coding app's write boundary is currently guaranteed on macOS only. What is still unfinished — full fidelity on complex Hancom documents, for one — is written down as-is under "implementation status" in docs/DOCUMENT_APP_DESIGN_2026_10_02.md, SPREADSHEET_APP_DESIGN_2026_10_02.md and CODING_APP_DESIGN_2026_10_02.md.)
→ Research projects — keep sources, questions, and a plan with each conversation
Create a research project in the launcher to give each topic conversation its own source library. Attachments and material actually read during research retain their originals and versions. The current gear's API or CLI agent retrieves them in later turns; a saved-sources-only mode is also available.
Persistent questions carry provisional answers, supporting and contradicting evidence, and remaining checks. Evidence points to a source version, paragraph, and quotation actually read. Editing or closing a question preserves its earlier revisions; closure records a reasoned decision, not a certificate of truth. → Research projects · Questions and evidence
Each topic conversation also keeps a research plan. Consciousness reads the current plan and decides whether to keep it or revise its purpose, scope, or method. Keeping it reuses the current plan without another plan-writing call or a new version; the executor receives that plan together with this turn's scope. Explanation and discussion do not automatically trigger more research. → Research plan continuity
→ Share the embedded browser's tabs with your AI
The existing limbs:browser action can open embedded browser tabs and read material using an existing login or a saved account. The local vault fills credentials without sending passwords to the model. Extra authentication or an unresolved account choice returns the tab to the person; human interaction also returns control. Separate Chrome MCP and Playwright drivers remain available. Site compatibility and supported operations are recorded in the embedded browser design.
AI tabs and login popups start in the background, leaving your selected tab and launcher alone. They become visible when authentication or account selection needs your input, then hide when that handoff ends or is cancelled. A panel you had already opened stays open. Hidden tabs remain available for follow-up calls; temporary collection tabs are removed when collection finishes.
→ A currency algebra
The table node carries domain-agnostic transformers — filter / sort / take / select / compute / dedup / groupby / join / union / merge / rename / flatten. Lists and records flow as explicit values, and emitters (chart / spreadsheet / document / structure) turn those values into artifacts. Any search result can therefore compose through >> without glue code:
$rows = [{id:"a",score:3},{id:"b",score:7},{id:"c",score:5}]
$rows >> [table:filter]{where:($row)=>$row.score>=5} >> [table:sort]{by:"score",descending:true} >> [table:select]{columns:["id","score"]}
Coverage is the nouns; depth is the currency verbs. A language with an algebra is what turns a search into a report.
→ Sentences, not just pipes
A pipe can only say "then". Real requests also say "for each of those", "only if", and "keep at it until". Current IBL expresses these as values, expressions, and blocks, not sentence strings or implicit slots:
[table:each] { … } receives each input row as $it and $i. mode:"map" returns one result per input, flat_map flattens one level, and effect returns no value; parallel still preserves output order.- Blocks —
[if:Bool expression] { … } [else] { … }, [case:expression] { … }, [repeat:…] { … }, and [try] { … } [catch] { … } [finally] { … }. Conditions, arguments, and callbacks share one expression language, and an undecidable value is never guessed to be false.
- Parallel branches —
& and each{parallel} run branches concurrently and keep output order. A nested program borrows whatever slots its parent left free, and read-only API bundles the engine has verified as safe run in parallel at one common boundary; the tree shares one budget.
Adding grammar exposed a useful failure class: places where the system couldn't tell and reported something definite anyway. Those became explicit failures, and the pattern is now deliberate: anywhere there is a fallback branch, check whether "I don't know" is being rendered as "no".
→ One sentence, one program
The current grammar treats explicit values, functions, repetition, and failure as one system. A newly saved program begins with #!ibl edition=2, and check:true runs the same compiler without effects before execution:
- Values — a list is always a list; it has no virtual
.items. Only a tool that declares a Record result is projected through fields such as .items or .text. String interpolation is explicit as f"${value}".
- Functions — define
[def:name]($first,$optional=default){…} and call [fn:name]{optional:value}. The first argument is the pipe slot; free variables and recursion are rejected.
- Failure and repetition — sequential execution stops on failure. Recovery is written with
try/catch; per-item failures become values only through each{on_error:"collect"} and Result. Repetition explicitly states a count, while, or until condition.
- Evidence and resume — values, source completeness, and evidence remain separate. Large results are read by reference, and an interrupted run resumes with
resume:{run_id} plus the same code and inputs, without repeating completed external work.
The line is deliberate: domain procedures still freeze into registered scripts ([self:script]) or reusable functions rather than multiplying vocabulary.
Saved programs use that same function contract. A checked definition is stored through [self:workflow]{op:"save",edition:2,code:...} and called as [fn:name]{argument:value}. Since 2026-10-25 edition 2 is the only language the engine runs: edition-1 execution support ended, every active stored function was moved to edition 2 (the ones that could not be were retired), and the old parser, the compatibility adapters and the implicit conversions were removed. Old originals are kept as readable history, not as runnable programs. Stored functions, their versions, the memory that refers to them and their call record live in one ledger behind one change gate, so a recalled idiom is always the version that actually ran. data/system_docs/ibl.md and data/guides/ibl_composition.md are the authoritative contract and examples.
→ Publishing to the open web, at personal scale
The same language that runs a private action can also expose one to the public internet. A small family of others actions turns an IBL flow into a real web address anyone can open — no server to rent, no framework to deploy:
[others:portal] — personal portals at /h/<slug>/: give family, friends, or neighbors a login and a level (0 guest → 4 family), and they borrow your instruments and content through the browser, without installing anything. Members are your neighbor CRM, unified — no separate account system.[others:family_news] — a family newspaper at /n/<slug>/, typeset from your phone's photos, with a guestbook and photo uploads.[others:bulletin] — login-free bulletin boards at /b/<slug>/; anyone with the address posts text and photos.[others:showcase] — public file shares at /s/<slug>/, served straight off your disk.- report faces at
/r/<slug>/ — a recurring-report folder rendered to HTML on view, so a fresh report every morning never needs a fresh link. (Configuration only, no verb of its own.) Separately, [others:publish] pushes a piece you wrote out as a Nostr long-form article (NIP-23) and hands back a shareable link.
This is the first step of the larger vision — individually raised systems finding each other. The principle is "one node per community": your system is the node, and the people around you are browsers reaching it, speaking the same language from the outside.
→ The shared warehouse — the node's front door
If the surfaces above are destinations you make, the front door — the node itself having an address, with its publishing folders, level gate, machine face, neighbor feed, and reposts — is covered at the top of this README. One thing belongs here, from the language's point of view: all of it cost IBL zero new verbs. Publishing composes out of vocabulary that already existed (self:copy, table:document, self:delete); the outermost discovery ring — a Nostr profile whose website is your warehouse, plus an #IndieNet note carrying only a greeting and the address — is [self:ledger]{store: "document", op: "publish"}. A stranger finds you on an open relay, then reads you out of your own warehouse.
Core #2 — A clean seam between the vocabulary and the body
A capability's meaning ([sense:here] = "where am I?") is body-independent; how it runs depends on the machine. Keep those two apart with a clean seam, and a second consequence falls out.
→ One verb, three questions: what, which body, which surface
Three questions look like one and are not. What does this mean? [limbs:radio]{op: "play"} means "play this station" everywhere. Which machine can do it? Only one with speakers, or a camera, or the disk holding your files. Where should the result land? Wherever you happen to be looking. Collapse any two of those and you get a system that quietly does the wrong thing on the right machine.
The seam keeps them apart. runs_on tags mark each action honestly — anywhere, or bound to a machine that actually has the capability. Nothing in the vocabulary names a brand: your hub can be a Mac or a Windows PC (the tag is pc_only, meaning compute-class, not macOS), and an action that reaches for a camera says camera, not phone. The senses that are inherently indexical — where am I, what do I see, what do I hear — mean the same thing on every body; only the answering differs, and a body without the hardware says so instead of guessing.
→ Bodies with separate dictionaries, talking by calling card
The seam cuts one layer deeper than "which machine runs it": each installed body owns only its own vocabulary. The distribution ships the whole dictionary; an install keeps what it actually has, and both the action catalog and the hippocampus filter for ownership — you don't learn someone else's words. (What a body "has" is not a folder but a per-body activation ledger over the full dictionary it holds — see What's core vs what's yours.)
So how does one body get another to do something? Not with a privileged pipe. Each body serves a calling card (GET /nodes/card) — a description-only projection of what it can do, exchanged automatically when bodies register each other, ~70 tokens of scent. Then one body simply asks in plain language ([others:ask]): the receiving body compiles the request with its own dictionary, runs it, and returns the result — or honestly declines if the words aren't in its vocabulary. Nothing imitates the other side's action names, so neither body has to know the other's dictionary.
What makes a body special isn't wiring, it's rank: bodies are neighbors in the same CRM, at a level you granted. Your phone is simply your highest-level neighbor, and a stranger's ask is refused by the same gate that governs everyone else. ([others:delegate] hands work to a persona; [others:ask] asks a body for a capability.)
And a body can be temporary: plug a USB stick into an unfamiliar PC and it becomes a thin limb for as long as you want ([self:limb] issues, [limbs:guestpc] commands). The brain and the identity stay on your hub — the stick carries one revocable limb key, never your password — and the little helper dials out to your hub, so nothing on that PC's firewall has to change.
The third question is the surface, and it is genuinely separate. Press play in the desktop launcher and the sound comes out of that machine. Press the same instrument in a browser on your phone and it plays there — because the request carries which surface asked, not which machine executed. One line of IBL, no branch in the declaration that renders it. The same axis sends a download to the device in your hand while the work happened on the hub, and sends the clipboard the other way.
The seam also splits memory cleanly: your world-data (contacts, business, calendar, health) is shared and synced (CRDT union merge), while each body's subjective memory (conversations, hippocampus, self-state) stays private.
→ Resident PCs, phone extensions, and media connections
A resident PC helper registered over USB stays connected after the USB drive is removed and starts at user login. The cockpit can update the helper and share the current Mac, Windows, or Linux desktop; the AI can address work to the registered PC by name. Minimal connectivity is separate from optional media installation, and long jobs return receipts for retrieving progress and results. A finished job is reported over the helper's own HTTP path the moment it completes, not on the next command poll. Updating a helper is one central deployment path whether you press the cockpit button or ask the AI ([self:limb]{op:"update"}): running jobs drain and desktop windows close before the install, the previous execution state is restored afterwards, and [self:limb]{op:"list"} reports whether each PC is on the current signed build (macOS helpers have been signed with the owner's certificate since 2026-10-25). → Helper guide and OS requirements
An Android phone can also register over USB once and then connect remotely as an extension. It receives programs for its own IBL engine instead of PC shell commands. Standalone YouTube search and music playback paths run without a PC proxy; opening a YouTube video in an external app is distinct from confirming playback. Fixed control code already installed on the phone runs without spawning a separate Python process when its fingerprint matches, and results are pushed back over a reused connection; arbitrary code stays isolated (measured on one phone: the on-device part of a single control call went from about 2.6 s to under 0.1 s). → Remote phones · Standalone playback
Media sessions connect accepted voice/video calls and registered devices' cameras, microphones, speakers, and playback through a shared session layer. The existing registered script 미디어세션 controls them. Phone video playback is successful only after the display and first frame are observed. Remaining device, external-network, TURN deployment, and long-duration acceptance checks are documented in the media implementation status.
→ Shared control drivers for apps and AI
The PC and phone control apps use the same stored functions as the AI. The AI chooses the device and goal; the driver checks the target, executes the request, and reports what it could verify.
| Target | Control path | Scope |
|---|
| Local or registered macOS/Windows PC | PC제어 / PC제어확인 | Audio, displays, power, apps, clipboard, network, and OS controls |
| Registered Android phone | Android제어 / Android제어확인 | Settings, sensors, and accessibility UI; UI needs a compatible APK and permission |
| Local macOS Safari / Chrome | Safari제어 / Chrome제어 scripts | Window and tab operations with a check against the observed revision |
| Registered Windows Chrome | PC제어 chrome_* actions | Tabs in a dedicated CDP profile |
| Registered Samsung TV (network API, no helper) | TV제어 script | Power, input, volume, apps, DLNA playback; the hub keeps the verified driver's connection open across calls |
Each driver's guide carries a call brief: when a device is introduced or a control part is discovered, the AI receives the exact call shape and the observed return once, tied to the fingerprint of the guide it came from, so it does not re-read a device's catalog every turn. Device state is never cached. Receipt, execution, and verified outcome are separate states. An uncertain result is checked through the original receipt rather than replayed automatically. These drivers use existing IBL functions and scripts; browser DOM automation remains a separate capability. Supported operations and remaining device checks: PC · Android · Safari · Chrome.
The split mind — define the problem, then execute it
Most systems plan and act as a single agent. IndieBiz OS separates problem framing, execution, supervision, and evaluation into distinct roles:
User message
↓ association: hippocampus + deep memory
↓ classifier: REFLEX, EXECUTE, or THINK (or an explicit user tag)
├─ REFLEX → short, separate execution context → finish
├─ EXECUTE → existing full context → finish
└─ THINK → consciousness defines the problem and achievement criteria
↓
executor
↔ consciousness supervises only when needed
↓
tool-free final evaluation → at most one minimal repair
↓
after delivery, select durable execution/relational/spatial memory
The execution paths do not validate in the same way. Only THINK has achievement criteria authored by consciousness, and the final evaluator judges only those criteria. If they are unmet, all identified defects are handed back together for at most one repair, followed by evaluation against the same criteria. REFLEX and EXECUTE without consciousness-authored criteria skip supervision and final evaluation. A NULL episode evaluation therefore means “not evaluated,” not failure; UNKNOWN means the criteria could not be decided from the available evidence.
Two verdicts are kept apart (since 2026-10-26): review approval — did the response pass the stated criteria — and goal outcome — was the user's original goal actually reached. A well-written failure report can be approved while the goal stays unmet, and only a goal that was actually achieved lets a later identical request inherit the earlier framing instead of waking consciousness again; older records that carry only an approval count as goal-undetermined. When the criteria include a rendered image, the evaluator looks at the actual image together with its purpose and render diagnostics; a missing or undecodable file is reported as could not review, never scored as a bad picture. Supervision counts repetition by observation, not by rule: the same tool input producing the same actual result inside one run is what gets flagged (alternating calls included, up to an eight-call cycle), real progress or a new result closes the issue so stale instructions stop being repeated, and nothing is auto-retried or rewritten on the executor's behalf.
REFLEX keeps simple requests out of a long working transcript. It uses the same model gear, common prompt, vocabulary, and recalled material as ordinary execution, with only a short recent conversation in a separate session. Choose it explicitly with #reflex, or let the classifier select it. If more context is needed, it can return to the full history before calling a tool; after a tool call, it does not automatically replay the task. The main session is preserved, and the next ordinary turn receives the separate execution's outcome. Hippocampus similarity does not select this path. → Context policy
The consciousness agent reframes the raw request into a well-defined problem before the executor ever sees it. Because the two are different subjects, the executor solves an already-framed problem: the off-target or unsafe paths a single plan-then-act agent would have to consider and reject are largely kept out of its frame from the start. This is containment, not alignment — safety dissolved into the goal rather than bolted on as a rule. And it's a property a single agent cannot have, because it cannot un-ask its own question — which is exactly why a more capable reasoning model doesn't absorb it.
Three model tiers serve this cheaply — lightweight, midtier, full — but which tier each cognitive role uses isn't hardwired. An automatic transmission (the unconscious classifier) already picks a tier per task; on top of it sits a manual gear lever (Save / Balance / Max) that shifts the whole system at once, the way a car's gearbox does. The four cognitive axes — classify, evaluate, execute, consciousness — each map to a tier through the chosen gear, so one lever rebalances cost vs. quality across the entire mind without restarting. (Models — and their API keys — flow from the gear, not from any per-agent setting.)
Memories that learn you — and your spaces
Several memories learn from you automatically and keep themselves clean:
- Hippocampus (procedural) — a fine-tuned 768-dim embedding model maps your natural language to past IBL code (retrained locally on Apple Silicon whenever the corpus grows; the current generation's Top-5 scores and corpus size live in the hippocampus table of
data/system_docs/memory.md). Successful runs distill into reusable examples, so the system gets faster at your recurring tasks. A closed loop records whether a recalled example actually worked, so proven patterns rise and bad ones sink.
- Deep memory (relational) — after each conversation a lightweight pass extracts durable facts about you (preferences, decisions, key dates) and recalls them, with their last-seen date, when relevant. Auto-recall is conservative: only items above a relevance floor are injected (at most three per turn, two inside the current topic branch and one outside), and an empty slot stays empty rather than being filled with the next-best candidate.
- Foraging memory (spatial) — remembers where material lives and how to interpret it: what a table row represents, a column’s units, or the conditions for joining two sources. Meanings stay attached to their file or location, with evidence and scope preserved in editable documents that can rebuild the database index. Recall returns the location’s memories and reports whether their source evidence changed, is missing, is unchanged within the checked scope, or remains unknown. Metadata checks do not certify identical content; an explicit content check compares the recorded scope. Facts about you belong in deep memory; the foraging browser searches without personalized memory. → Memory contracts and limits
A periodic consolidation pass (part of the immune patrol below) merges near-duplicates, prunes stale or proven-bad entries, and resolves contradictions, so memory stays sharp instead of bloating. Long-term writes happen after the final response is delivered, in one pass that selects durable value from the user's original words and actual tool observations; saving nothing is a normal outcome. Foraging memory distinguishes source statements, user declarations, and AI interpretations; repeated wording alone adds no evidence. Distillation no longer pre-judges candidates by surface form (politeness, question form, conjunctions, length): the full original goes to the distiller with each unit's position and hash, and the distiller decides authorship, adoption and durability.
The system watches itself
- World Pulse — hourly: economy, weather, news (every 6h), user activity, system health.
- Self-Check — once a day, a deterministic sweep: static consistency, a currency probe over every action's fixture, and a set of golden pipelines (no model calls — the AI patrol it replaced was retired). On
/self-inspect, the system AI retries failures to classify them transient vs reproducible and rate fix difficulty (easy / medium / hard).
- Commit-time guards — the checks that hold the vocabulary together (a three-way match between source, tool schema, and handler) were extended to the seams — the things that aren't actions: an auth gate that fails closed rather than open, a check that every publicly-exposed route really has its own gate (the oracle is the live route table, not a re-parsed list), a scan for blocking calls inside async code (this server calls itself often enough that a blocked loop is a self-deadlock), a Unix-only-import scan for Windows portability, and a fresh-clone CI — because
main once passed only on the machine that wrote it. The scanner that used to grep commits for retired phrases was itself retired on 2026-10-25 (its registry is archived); the weekly guide-hygiene pass now measures guides only against the current vocabulary, paths, observations and budget, and a guide that still checks out skips the model call.
- Capability history — records first observation, implementation and dependency changes, verification, repairs, and execution separately for vocabulary, scripts, and stored functions. Verification is tied to current fingerprints and explicit evidence; an unknown creation date stays unknown. → Body history guide
- Boot observability — the subsystems a server may start without are wrapped in "log it and carry on" blocks, which is correct; the problem is that three days later the answer to "why did nothing get scheduled?" is somewhere off the top of a terminal. Every one of those blocks is now instrumented, and a failed boot step shows up in the health endpoint.
- Self-repair — when you tell it to, the system fixes its own code. Not on top of its living self, though. Every change is made in an isolated working copy, and only the exact bytes that passed the relevant checks in that copy are applied to the canonical tree. Applying, restarting, and rolling back on failure belong to a restart controller that lives outside the backend — a step that must run after your own death belongs to a process that outlives it. There is no fallback that writes to the canonical tree when isolation fails. Facts a machine can verify (real test reports, candidate and environment fingerprints) are no longer re-approved by another AI reading prose; the evaluator is asked only where a judgement of meaning is needed. The authority is bound to : schedules, delegation chains and external channels never get it, and another run under the same agent name cannot borrow it.
Agents you design, teams that delegate
You don't just say "act as a doctor" — you define who an agent is and how it communicates, and it remembers your context (medications, preferences, past conversations):
agents:
dr_kim:
role: |
You are Dr. Kim, an internal-medicine specialist of 20 years.
You acknowledge the patient's concern before asking questions,
explain terms in everyday language, and always end with clear next steps.
allowed_nodes: [sense, self, limbs, others, engines]
You define who an agent is, not which model runs it — model and API key are decided centrally by the gear lever above (with an optional per-agent pin to override one agent's tier). Agents form teams and delegate — synchronously (call_agent, wait for the result), on a schedule (hand a task to another agent's clock), or via a written plan (create_plan → execute_plan, each agent runs its part and hands off). Agents with a communication channel (Nostr, Gmail) can take orders remotely and reach other people's agents over IndieNet (Nostr; DMs use modern NIP-17 gift-wrap encryption).
Delegation also has a task-scoped form ([others:delegate]{scope:"task", request_id:…}): each call opens an independent session under the current conversation's parent task, several run side by side with &, the parent waits for its own children even when its model answered first, a follow-up continues a worker by its worker_ref, and the parent can steer a running child ([self:task]{op:"steer"}) without that counting as a user instruction. A delegated fixed IBL workflow is executed as written — original text, edition and inputs — rather than re-interpreted by the receiving model. Coding tasks handed to an external repository are checked in an isolated copy, and only one candidate is conditionally merged back. None of this added a node or an action.
The IBL dictionary opens from the conversation header: a separate window in Electron and a dialog on the web. Selecting an action attaches it to the next message in the originating conversation. My vocabulary manages which bundles you own and activate. YouTube, radio, and CCTV each collect their operations under limbs:youtube, limbs:radio, and limbs:cctv; effects and execution location are declared per operation.
Under the hood (reference)
6 nodes, 171 composable actions — one tool (execute_ibl), one vocabulary, not 171 schemas:
| Node | Actions | What lives here |
|---|
| sense | 39 | Retrieval — web/news search (one verb, source-branched), any RSS/Atom feed, finance, real estate (official prices + live listings), accommodation, second-hand markets, freelance marketplaces, legal, statistics, classic literature, performances, academic papers/dissertations/researchers, entity resolution (Wikidata), AI grants & contests — plus the indexical senses each body answers its own way (notifications, location, mic, camera; no hardware → an honest no_hardware, never a guess) |
| self | 58 | System management, workflows, triggers, goals, files (read/write/edit/fill, plus surgical edits to a live spreadsheet), deep + forager memory, ledgers (business catalog, personal/company finance, health records), grounded Q&A over your own document piles, registered scripts, phone sync, my music library, USB-limb issuance, the web-app registry, slides & decks, library install (approval-gated) |
| limbs | 13 | UI automation (browser, Android, desktop screen), phone-native actions, a guest PC reached by USB limb, media playback (YouTube, radio), window opening, maps |
| others | 20 | Collaboration, delegation, asking another body in plain language, messaging (DM/feed/board/Nostr NIP-17), neighbor CRM (contacts are ops on a neighbor — a warehouse address is just another contact type), auto-response — and the public-web surfaces others can reach: personal portals, family newspaper, login-free bulletin boards, public file shares |
| engines | 19 | Pure media generation — images (generate + vision read/critique), icons, the morning newspaper, websites, web components, TTS. Slides and video moved to self in the 2026-08 consolidation |
| table | 22 | Currency algebra — transformers (filter/sort/take/select/dedup/groupby/join/union/merge/rename/flatten), the higher-order each, and emitters (chart/spreadsheet/document/structure). Split out of engines so the grammar survives even when heavy media generation is off |
IBL's definition lives in a single source of truth (data/ibl_nodes_src/ plus each package’s ibl_actions.yaml, built to data/ibl_nodes.yaml via scripts/build_ibl_nodes.py), and a commit-time check matches source ↔ tool schema ↔ handler three ways. Tool packages (51 in the held catalog, plus 5 backend core modules; activation is per body) are folders — drop one in and it's recognized, independent of the language; an AI agent can build, install, or modify them for you. Per-agent allowed_nodes restricts what each agent can reach.
(The numbers in this section are regenerated from the registry by scripts/build_ibl_nodes.py — don't edit them by hand.)
Getting started (recommended)
The easiest way to install IndieBiz OS is through Claude Desktop.
- Open Claude Desktop and switch to the Claude Code tab.
- Tell Claude:
"Install IndieBiz OS from https://github.com/kangkukjin/indiebizOS on my PC"
- Claude clones the repo, installs dependencies (Python, Node.js), asks about your needs, and sets up a system tailored to you.
Why Claude Desktop? IndieBiz OS is a living system, not a static npm install. The agent that installs it becomes the blacksmith who keeps forging it to fit you.
You'll provide: an LLM API key (Anthropic, Google, or OpenAI) — or a Claude Code / Codex subscription login, which needs no key; answers to a few questions about what you want; external API keys only as you actually use those features. To also turn on the public surfaces — Shared Warehouse, remote access — you'll additionally need a Cloudflare account + your own domain; the full setup map is in the Getting Started guide.
Don't have Claude Desktop? Download a prebuilt desktop app. It bundles everything (Python, Node, all runtimes) inside the app, so nothing has to be installed on your machine and installing costs nothing — you just enter your own AI API key (Anthropic / Google / OpenAI) on first launch.
Get it from the app-latest release:
- macOS (Apple Silicon):
IndieBiz-*-arm64.dmg
- macOS (Intel):
IndieBiz-*-x64.dmg
- Windows:
IndieBiz-Setup-*.exe
Open the .dmg and drag IndieBiz into Applications (macOS), or run the installer (Windows). The apps aren't code-signed yet, so the first launch may need right-click → Open on macOS, or More info → Run anyway on Windows SmartScreen.
Language: the AI replies in whatever language you write to it, so no setting is needed. The interface language is chosen in the launcher (한국어 · English · 日本語). Korean is the source and the others are generated at build time and shown offline — interface text is never sent anywhere for translation at runtime, and your conversations, file names and inputs are not translated at all. Adding a language requires registering it in frontend/i18n/languages.json, filling the translation memory, and building the interface. (The bundled guide documents are currently Korean.)
This is the canonical install path — CI verifies this exact recipe on all three OSes on every push (clone → bootstrap → boot → /health 200). The Claude Desktop path and the desktop app are both wrappers around it.
git clone https://github.com/kangkukjin/indiebizOS.git
cd indiebizOS
python3 scripts/bootstrap.py # Windows: py scripts\bootstrap.py
python3 scripts/update.py # upgrade later (keeps your package on/off choices across git pull)
The bootstrap creates .venv (auto-selecting Python 3.10–3.13), installs backend dependencies (core strictly; tools and semantic-memory extras best-effort — without the latter, recall degrades to keyword search), seeds .env from .env.example (put your LLM API key there), and installs the Electron desktop UI if npm is present — backend-only otherwise (remote launcher/REST still work).
Optional dependency: LibreOffice — needed only for ledger (xlsx) rendering with formula recalculation ([engines:render]{op:"xlsx"}): macOS brew install --cask libreoffice / Linux apt install libreoffice-calc / Windows official installer. Without it, only that feature fails — honestly, with the install hint.
Run:
./start.sh # macOS/Linux (backend + desktop UI)
Windows: .venv\Scripts\python.exe backend\api.py
You configure agents, packages, and preferences yourself on this path. The Claude Desktop path is more comfortable because the AI handles all of it for you.
What's core vs what's yours
IndieBiz OS ships a standard core — the IBL grammar, the function-word nodes, the backend/frontend engine, and a catalog of tool packages and apps — but the moment you install it, it becomes your instance. You add vocabulary, install or author apps, accumulate conversations and settings. The line between the two is a single source of truth: data/core_manifest.json, derived from what's committed to the repo (scripts/build_core_manifest.py), so nothing has to be hand-tagged.
Two guarantees follow:
- Install doesn't dump everything on you. Many packages need their own API keys; installing them all would bury you in things you can't use. The whole catalog ships, but only a curated set is active by default — the rest sit available, ready to switch on when you want them. Since 2026-09 that switch is a per-body activation ledger over the full dictionary you hold: waking or putting a word bundle to sleep changes the ledger and the prompt cache, never a folder or a rebuild, and a sleeping bundle keeps its files, settings, examples and vectors. You do it in My vocabulary (launcher glasses menu, below External User Management) — an icon desktop where bundles sit in folders, a storage vault, and a trash — and a bundle travels as a single
.iblpack file: import through the vault, export from the bundle's own menu; an imported bundle arrives asleep and runs only once you wake it (format: docs/IBLPACK_FORMAT.md). Every package carries an origin (core / user), and the desktop-app packaging is built from the manifest, so your own committed apps and personal files never leak into a distribution. (Committing a personal package for backup? Mark it origin: user and it stays out of the core.)
- Updates never overwrite what's yours. A reinstall or update refreshes only core-owned files. Which packages you've turned on or off, the vocabulary and apps you authored, your settings, and your conversation history all survive untouched — the updater respects the folder placement you chose rather than re-imposing the bundle's defaults.
This is the same substrate/superstructure seam that separates the standard grammar from your personal dictionary — pushed all the way out to packages, apps, install, and update.
Technical Stack
- Backend: Python FastAPI (port 8765)
- Frontend: Electron + React (TypeScript)
- AI Providers: Anthropic (Claude), Google (Gemini), OpenAI (GPT), DeepSeek, OpenRouter, Ollama (local) — plus two subscription-login CLI harnesses, Claude Code and Codex, that need no API key (Codex's model and reasoning effort are picked from the installed Codex's own model catalog, so new models appear without a code change)
- Database: SQLite
- Document engines (optional): ONLYOFFICE Docs (a local container, published on this PC's loopback only) for original-format office documents and spreadsheets · RHWP for HWP/HWPX · Tesseract for OCR. The system starts without them; only those editing features are off.
- Deployment: Local-first, optional Cloudflare Tunnel for remote access
Running
# Development mode
./start.sh
# Or separately
.venv/bin/python3 backend/api.py # Backend from the repository root (port 8765)
# In another terminal, from the repository root:
cd frontend && npm run electron:dev # Frontend (Electron)
start.sh runs the backend through the repo's .venv only (create it with python3 scripts/bootstrap.py; there is no silent fallback to system Python). backend/api.py is the restart controller: start is the default action, and status / restart --wait / shutdown --wait are the operating verbs.
Change history
The running record is git log and data/system_docs/changelog.log. The long documentation-update digests this README used to carry (2026-06 → 2026-10) are archived in docs/README_CHANGE_HISTORY.md.
IndieBiz OS — An AI system that grows with you, not one that's given to you.
