A ByteFoundry product
Babylon

Apps

Our apps are plugins. Build your own.

The boards and the whiteboard your group uses aren't baked into Babylon anywhere special. Each is a plugin, and the seam they plug into ships with the source. If someone in your group writes code, this is their page.

An app is one Rust crate on the server and one Svelte module in the client. Each gets registered with a single line. Boards, the whole kanban feature, is about a thousand lines of server code plus its client parts. The whiteboard is smaller.

The seam

What the platform hands you.

Your crate implements one trait, BabylonApp. Everything below comes with it. Our own apps run on the same services, because there isn't another set.

The seam Your code either side, the platform in the middle. Boards and the whiteboard sit in the same spots.
Tables
Your app ships its own migrations and owns its own tables, prefixed with its id. They run at start-up against the app's own history, kept apart from the core schema. Removing the app touches nothing else on the server.
Lifecycle
Hooks for install, uninstall, and instance create, archive, restore and delete. A hook runs inside the platform's transaction, so if your code fails the whole request rolls back and nothing is left half-installed.
Realtime
You publish to your app's own topics and clients get it over the connection they already have open. No sockets to manage, no polling loop to write.
First open
When someone opens your app, the platform asks your code what they should see, and sends it to that person only. The whiteboard uses this to hand a full snapshot to whoever walks in mid-drawing.
Events in
Clients send your app events back over the same connection. The platform works out who's asking and whether they can view the instance before your code runs; the finer decisions are yours, made against the rights it hands you.
Files
Instance-scoped storage in the platform's own store. The platform writes the storage keys and namespaces them per instance, so your app can't reach another instance's files even with a bug.
Permissions
Apps can declare their own permission bits, and they ride the same role system as the rest of the server. It's why moderation reaches into apps instead of stopping at their edge.
Routes
For the parts that aren't realtime, an app answers ordinary requests under its own path. Boards does its create-and-edit work this way.

The path

Five steps.

// the server half — the whole registration surface
struct OpSheet;

impl BabylonApp for OpSheet {
    fn id(&self) -> &'static str { "opsheet" }
    fn name(&self) -> &'static str { "Op sign-up" }
    fn description(&self) -> &'static str { "Slots for the next op night." }
    fn icon(&self) -> &'static str { "clipboard" }
    fn schema_version(&self) -> &'static str { "1.0.0" }
    fn capabilities(&self) -> &'static [Capability] { &[Capability::Realtime, Capability::Database] }
    // migrations, hooks and events as you need them — every one defaults to a no-op
}

// main.rs — next to ours
app_registry.register(Box::new(babylon_boards::BoardsApp));
app_registry.register(Box::new(babylon_whiteboard::WhiteboardApp));
app_registry.register(Box::new(opsheet::OpSheet));

// the client registry — the other one-liner
opsheet: () => import("$lib/apps/opsheet/OpSheetApp.svelte"),
The path A minimal app, in full. The green lines are the two registrations.
1 — Take the source
Babylon is source available, though the repository isn't published yet — see What isn't built, below. Once it's in your hands, what you build compiles into your own server.
2 — Write the crate
Implement BabylonApp: an id, a name, your migrations, whichever hooks you actually need. The rest default to no-ops.
3 — Register it
One line in the server's main, next to the line that registers boards. At boot the platform mirrors the registry into the database and runs your migrations.
4 — Give it a face
The face is one Svelte module plus a line in the client registry, lazy-loaded and code-split without you doing anything. If the module isn't there yet, the app shows a placeholder pane instead of breaking.
5 — Build and run
Admins install it per server, members put instances of it in channels, and the archive, restore, rename and permission plumbing already works. You wrote none of it.

A commit hook in the repo refuses any commit that mixes app crates with platform code, so the boundary holds for us the same as for you.

Ideas

Things nobody has built yet.

None of these exists yet. Two of the six are on our own board; the other four are shapes we reckon a group would actually use, and they're up for grabs. Here's what one could look like in place.

Imagined An Op sign-up app, drawn to show the idea. This app does not exist.
realtime · permission bits

Op sign-up

Slots for the next op night, claimed live. A role bit decides who can lock the sheet. The mockup above.

tables · files

Quartermaster

Who holds what: kit lists, loadouts, photos of the actual shelf. The lifecycle hooks mean uninstalling it cleans up after itself.

tables · realtime

Ladder

Internal results and standings, updated as matches finish. Seasons are just an archive-and-restore away.

files · realtime

Map board

An uploaded map with shared markers on top — the whiteboard's snapshot-on-open trick, pointed at planning.

on our board

Quests

Challenges and completion tracking for a community. It's on the roadmap, parked, and nobody has claimed it.

on our board

Prediction markets

Points-only betting on your own group's matches. It sits on the roadmap in the same parked state. Beat us to it.

The deal

Trusted code.

An app compiles into the server. Nothing sandboxes it and no store sits between you and it. You read what you run, the same as every other line of a server you host yourself, and that is also why an app gets this much reach.

Where it's at

What isn't built.

The repository
The source isn't up anywhere public yet. Publishing it is the step everything on this page waits on — it's written down on the board.
Dynamic loading
Apps compile in. You can't drop a file in a folder to install one, so every app stays code you've read and compiled. See the deal above.
A marketplace
There's no app directory and no publishing flow. If you build something good, today you share it as source.
Some editor screens
Per-instance permission editing and the creator allowlist exist as server routes with no screens yet. The screens are on the board too.
Bots and tokens
Bot accounts and integration tokens have a roadmap line of their own, outside the apps seam. Incoming webhooks came off that line — a channel can take posts from your scripts today, and the features page has what they do.
What the built apps do The roadmap