DEV Community: Marco Allegretti

Building a Deep Fantasy Manager in Rust: Want to join?

Marco Allegretti — Mon, 16 Mar 2026 21:10:51 +0000

I’ve been heads-down building Mythic League, a persistent fantasy guild manager.

The goal is the long-term depth of manager sims like Hattrick / Football Manager, but set in a tactical fantasy world: you run a guild, develop heroes across seasons, play scheduled league matches, and deal with the economic consequences of every decision.

This is not an “idea” post. The backend, schema, and core simulation loop already run locally end-to-end, and there’s a first-run workflow that takes you from an empty database to scheduled matches, battle processing, and a replay log.

CURRENT STATE (WHAT’S IMPLEMENTED)

You can do this today in local dev:

Create an account and a guild
Use a dev-only panel (guarded by DEV_MODE=true) to:
- seed a world (season, divisions, NPC guilds, missions)
- seed starter heroes
- schedule matches
- enqueue a match into a Redis-backed battle queue
Process matches via a background battle worker
Persist match results and battle logs in Postgres
Navigate core UI areas (roster, missions, market, matches, league standings)

On the persistence/narrative side, these are real tables + queries + endpoints (not a pitch):

Guild Chronicle: chronicle_events table + API endpoint to list events per guild
Hero Legacy: hero_legacy table for long-lived hero career stats / defining moments
Hall of Fame: hall_of_fame table + API endpoint

THE STACK (ACTUAL REPO STACK)

Backend: Rust + Axum (HTTP + WebSockets)
Jobs/workers: Rust crate for background processing (including battle processing)
Battle sim: a dedicated battle-engine crate
Database: PostgreSQL 16
Queue/realtime: Redis 7 (battle queue + pub/sub for match events)
Frontend: React 18 + Vite + Tailwind
Shared types: ts-rs is in the Rust workspace dependencies (Rust↔TS type sharing)

The repo is split accordingly: crates/api, crates/jobs, crates/battle-engine, crates/db, crates/domain, plus frontend/.

WHY I’M LOOKING FOR A CO-MAINTAINER

I’m not looking for someone to “help out” with busywork. I’m looking for a technical partner who wants to co-own hard problems in a production-grade simulation game codebase.

The interesting work is in the seams:

1) Battle simulation determinism + debugging ergonomics

Matches are simulated by the worker with a derived seed and a blocking simulation call.
I want to tighten determinism guarantees and make edge cases easier to reproduce and regression-test.

2) Market correctness under concurrency (Redis + Postgres boundaries)

Redis is already in the stack and there are dev endpoints for closing/settling expired auctions.
I want to nail atomic settlement and sniping behavior and prevent race conditions between API calls, settlement, and background processing.

3) Chronicle / legacy data that stays useful long-term

Chronicle events are persisted as first-class rows; hero legacy lives independently.
I want to keep this useful, queryable, and fast without turning it into an unbounded logging dump.

4) Economy + progression balancing that survives seasons

There are weekly jobs (training, salaries) and match-driven income.
I want help validating the sinks/sources and preventing degenerate strategies (inflation, runaway guilds, “always optimal” builds).

WHAT YOU’LL BE WORKING WITH

A repo that boots locally with Docker (Postgres + Redis)
A defined first-run workflow that gets you from empty DB to simulated matches
A backend split into API / domain / DB / jobs / battle engine crates
A React UI with real pages and navigation (not just a landing page)

If you’re a Rust + TypeScript dev and you want to co-maintain a simulation-heavy game project, I’d like to talk.

Let's Connect!

mythicleague.online

COSMIC and WEFT OS: Two Ways to Build a Rust Desktop (Smithay, Wayland, Servo)

Marco Allegretti — Mon, 16 Mar 2026 07:41:52 +0000

COSMIC and WEFT OS: two ways to build a Rust desktop

I’ve been thinking a lot about what a modern desktop actually is once you strip away the branding, the defaults, and the decades of inherited assumptions.

At the core, the shape is surprisingly simple:

A compositor owns the screen, the input devices, and window placement.
A shell defines the experience around those windows.
An app model decides how software starts, what it can access, and how it talks to the rest of the system.

That is why System76’s COSMIC and my experimental project WEFT OS are so interesting to compare.

They both live in the Rust + Wayland world. They both use Smithay as an important building block. But they point in different directions.

COSMIC asks: what does a polished, practical, Rust-first desktop environment look like?

WEFT asks: what happens if the shell becomes web-native, the app logic becomes WebAssembly, and the OS is designed around explicit boundaries from the start?

This is not a competition piece. It is a structural comparison.

The common ground: Wayland and Smithay

Both projects start from the same place.

Wayland is the protocol that lets clients present windows and receive input.

A compositor is the part that actually owns the screen. It decides:

which window is visible
where it appears
who receives keyboard, mouse, or touch input
how everything is composed into the final frame

Smithay matters because it gives Rust projects a serious foundation for building that layer.

That shared foundation is important. It means COSMIC and WEFT are not separated by language or by rendering era. They are separated by design choices.

COSMIC: a full desktop environment made of Rust components

The easiest way to understand COSMIC is to look at its shape.

It is not just a compositor. It is a desktop environment made of many coordinated Rust projects: panel, settings, terminal, file manager, session manager, applets, launcher, notifications, and more.

That tells you a lot before you even read the code.

COSMIC is trying to be a real desktop people can live in.

Its compositor, cosmic-comp, reflects that ambition. It is built to handle the realities of a desktop environment rather than a narrow demo path. It supports multiple backends, integrates XWayland, runs a Wayland event loop, and includes practical debugging and profiling hooks.

That breadth matters. A production desktop has to survive mixed environments, odd hardware, legacy applications, and the boring-but-essential details of logging, profiling, and session management.

So when I look at COSMIC, I do not mainly see “Rust desktop hype.” I see a serious attempt to answer a very difficult question:

Can you build a complete, modern Linux desktop in Rust without making it feel like an experiment?

That is what makes COSMIC important.

WEFT OS: a smaller system with stricter boundaries

WEFT OS is not trying to be a general-purpose desktop environment in the same way.

It is an experimental operating system project with a narrower, more controlled structure:

weft-compositor
├─ owns Wayland surfaces, input, and display composition
├─ hosts the system panel surface from weft-servo-shell
└─ hosts application surfaces from weft-app-shell

weft-servo-shell
└─ renders the system UI in Servo

weft-appd
├─ starts and stops app sessions
├─ supervises runtime state
├─ relays per-session IPC
└─ launches the per-app shell when the runtime is ready

weft-runtime
└─ runs the app logic as a WASI WebAssembly component

weft-app-shell
└─ renders the app UI in an isolated Servo WebView

weft-file-portal
└─ mediates file access for the session

The difference in philosophy shows up immediately.

COSMIC grows outward from the idea of a desktop environment.

WEFT grows inward from the idea of process boundaries and explicit contracts.

Every major responsibility has its own place:

the compositor composes
the shells render
the daemon supervises
the runtime executes app logic
the portal mediates filesystem access

That makes WEFT feel less like “a desktop with some apps” and more like “a small operating system made of cooperating parts.”

The real fork in the road: what the shell is

This is where the two projects stop merely looking different and start thinking differently.

In COSMIC, the shell is native

COSMIC’s user experience is built out of Rust-native components. The compositor is a key piece, but the desktop itself is a collection of native programs and libraries working together.

That is a very strong model if your goal is to ship a responsive, integrated desktop that behaves like people expect a Linux desktop to behave.

In WEFT, the shell is a document

WEFT takes a different path.

The system UI is rendered through Servo. App UIs are also rendered through Servo, in isolated per-app shells.

That means the shell is not just “a UI toolkit in Rust.” It is a browser engine embedded into the operating system model.

That changes the conversation.

When your shell is HTML and CSS, a few things happen at once:

layout becomes document layout
interaction becomes event-driven in a web sense
styling becomes a first-class part of the platform

That can be powerful. It can also be dangerous if the boundaries are vague.

So the important part is not simply “WEFT uses Servo.” The important part is how it uses Servo: as one piece in a system where the compositor, shell, runtime, and policy layer are kept separate.

That separation is doing a lot of work.

It is what makes “browser engine as shell” feel like an operating system design choice instead of a shortcut.

Two different ideas of what an app should be

This is the second major split.

COSMIC’s app model

COSMIC is a desktop environment. It is built to host the world Linux users already live in:

Wayland-native applications
X11 applications through XWayland
COSMIC-native applications built in Rust

In other words, COSMIC is designed to be a place where existing desktop software can live comfortably.

WEFT’s app model

WEFT is stricter.

In WEFT, an app is really two things at once:

logic, running as a WebAssembly component in weft-runtime
UI, rendered in a separate Servo-based app shell

The launch path reflects that design:

The system UI asks weft-appd to launch an app.
weft-appd creates the session context, including IPC and, when needed, a file portal.
weft-appd starts weft-runtime, which runs the app logic.
Once the runtime is ready, weft-appd starts weft-app-shell.
The app shell creates the Wayland surface and presents the UI through Servo.

That structure is not just about startup order.

It is the app model made visible.

The app logic does not silently become the UI process. The UI process does not silently gain full filesystem access. Lifecycle is supervised. Filesystem access is mediated. IPC is part of the design, not a hidden implementation detail.

That is the heart of WEFT.

What Smithay makes possible

One of the most interesting lessons here is that Smithay does not force a worldview on you.

It gives you the infrastructure for a compositor, but it does not tell you what kind of desktop must sit on top of it.

That is why both of these can exist on the same technical foundation:

a production-oriented desktop environment like COSMIC
an experimental, shell-and-runtime-driven system like WEFT

That flexibility is exactly why Smithay matters.

It is not only a toolkit. It is an enabler of architectural diversity.

Why Servo is still interesting

Servo is easy to talk about in abstract terms, but it becomes more interesting when you place it inside an operating system design.

In WEFT, Servo is not being used just to say “look, web tech on the desktop.” That would be shallow.

The interesting part is that Servo becomes the rendering engine for a shell that is still constrained by:

compositor rules
process boundaries
lifecycle supervision
capability boundaries

That makes Servo feel less like a gimmick and more like a deliberate experiment in what a desktop shell could be.

Not a browser pretending to be an OS.

An OS deciding that document rendering can be a first-class part of its user interface model.

What I take away from the comparison

When I look at COSMIC, I see confidence in the idea that Rust is ready for mainstream desktop infrastructure.

When I look at WEFT, I see a different question being asked:

If we take the compositor seriously, the boundaries seriously, and the web seriously, what kind of OS falls out of that?

That is why I think these two projects sit well next to each other.

COSMIC shows how far a modern Rust desktop can go when the goal is completeness, polish, and practical deployment.

WEFT explores what happens when you use the same low-level world—Wayland, Smithay, process isolation—but point it toward a different model for shells and apps.

Both are valuable.

Both are modern.

And both say something important about where the Linux desktop might still go.

Closing thought

The most interesting part of the current Rust desktop moment is not that people are rewriting old ideas in a new language.

It is that the same technical base is now strong enough to support genuinely different visions.

COSMIC is one vision: a serious, full desktop environment built in Rust.

WEFT is another: a more experimental system where shells are rendered through Servo, apps are split between WebAssembly logic and web UI, and the operating system is shaped around clear process contracts.

That difference is exactly what makes the comparison worth having.

marcoallegretti / WEFT_OS

WEFT OS is an experimental operating system built around WebAssembly, Servo, and Wayland, designed to run secure, GPU-accelerated web and Wasm applications in a modular package-based system.

WEFT OS

WEFT OS is a Wayland compositor and application runtime where every app is a WebAssembly component rendered in an isolated Servo WebView. No capability is granted by default; all resource access is declared in a per-app manifest and enforced at runtime.

What is implemented

Compositor — weft-compositor is a Smithay-based Wayland compositor with DRM/KMS and winit backends. It implements the zweft-shell-unstable-v1 protocol extension, which typed shell slots (panel, application) register against.

System shell — weft-servo-shell embeds Servo (feature-gated, --features servo-embed) and renders system-ui.html as a Wayland panel. Without servo-embed, the binary builds as a no-op stub. Navigation gestures from the compositor are forwarded to weft-appd over WebSocket.

App shell — weft-app-shell is a per-process Servo host for application WebViews. It resolves weft-app://<id>/ui/index.html, injects a weftIpc WebSocket bridge into the page, and registers with the compositor as an application surface. Also feature-gated behind servo-embed.

App…

View on GitHub

LLMs Are Just Another Layer of Abstraction

Marco Allegretti — Sun, 15 Mar 2026 16:15:12 +0000

(A reflection on AI-generated code and the history of software development)

In the last couple of years, many developers have started saying something like:

“AI will replace programming.”

Personally, I don’t think that’s what’s happening.

What we’re seeing looks much more familiar.

It’s just another layer of abstraction.

The History of Programming Is the History of Abstraction

If you look at the evolution of computer science, it’s essentially a story about building layers.

At the beginning we had to write:

machine code
assembly
low-level languages

Then came higher-level languages.

Then frameworks.

Then platforms.

Every step moved us further away from the machine while making software easier to build.

Compilers, interpreters, and APIs all did the same thing: they allowed developers to work at a higher conceptual level while the system handled the complexity underneath.

Now something similar is happening again.

LLMs as a New Interface

Large Language Models introduce something interesting:
natural language as an interface to software creation.

Instead of writing:

syntax
configuration
boilerplate

we can increasingly describe intent.

You explain the idea, and the system generates the code.

In this sense, LLMs behave almost like a new kind of compiler.

Not a compiler from C to assembly.

But something closer to:

intent → implementation

But Abstractions Are Never Perfect

There’s an old meme that says:

“If your code doesn’t work, blame the compiler.”

It’s funny, but it also reveals something important.

Abstractions don’t remove complexity.

They move it somewhere else.

Every developer knows this moment:

You’re happily using a framework…
until something breaks.

And suddenly you have to understand the internals.

The abstraction leaks.

This isn’t a flaw of abstraction — it’s simply how complex systems work.

The Skill That Never Changes

Because of this, one thing in programming never really disappears.

The ability to look below the abstraction layer.

It doesn’t matter if that layer is:

a framework
a compiler
a runtime
or now an LLM

Eventually something breaks.

And when it does, someone needs to understand what’s happening underneath.

AI Doesn’t Replace Engineers

If anything, AI might make this skill even more important.

Because the higher the abstraction, the more critical it becomes to understand:

when to trust the system
when to inspect the output
when to go deeper.

LLMs might generate code.

But understanding systems is still a human responsibility.

Final Thought

AI-generated code is not the end of programming.

It’s simply the next chapter in a very long story.

A story about abstraction, tools, and the evolving relationship between humans and machines.

And like every abstraction before it,
it will make some things easier…

while making other things more interesting.

WEFT OS – Rethinking “Firefox OS” For 2026

Marco Allegretti — Sun, 15 Mar 2026 13:30:04 +0000

When people hear “new operating system,” they usually think of big consumer products: Windows, macOS, Android, iOS.

When developers hear “new OS,” they often think of hobby projects that boot, show a prompt, and stop there.

WEFT OS is neither of those.

It is a serious attempt to answer a simple question:

If we took the best ideas from Firefox OS — the idea that apps are just web content — and rebuilt them with modern isolation, security, and reliability in mind, what would that operating system look like?

This article walks through that answer in plain language.

It is written for a general audience, but it is precise enough that a senior systems architect should recognize the design patterns and trade‑offs.

Remembering Firefox OS (And What It Got Right)

Firefox OS tried something bold:

instead of installing “native” apps, you would run applications built with web technologies — HTML, CSS, JavaScript — directly on the phone.

It got a few important things right:

The web as the app platform.

You don’t compile separate apps for every device. You build with the web stack developers already know.
Permissioned capabilities.

Apps didn’t just get full device access. They had to declare which things they used (camera, contacts, etc.).
Simple deployment.

Apps were essentially packaged websites, not massive native binaries.

What went wrong is more complex: hardware realities, market timing, and some architectural limits.

But the core idea — “the web as a first‑class app platform” — never stopped being interesting.

WEFT OS picks that idea back up, but with a much stricter focus on:

Isolation: every app is strongly contained.
Contracts: components talk over clearly defined channels.
Reliability: one broken app should not bring down your session.

WEFT OS In One Sentence

WEFT OS is an operating system that treats the web as the primary UI layer, runs each app in its own isolated sandbox, and connects everything through explicit, inspectable IPC (inter‑process communication) contracts.

That’s a mouthful, so let’s unpack it in human terms.

A Simple Mental Model: Three “Rooms” Talking

Imagine WEFT OS as a small house with three main rooms:

The Display Room – “the compositor”

This is the part that actually talks to your monitor and input devices (keyboard, mouse, touch).

It knows how to draw windows, move them around, and react when you click or type.
The System UI Room – “system shell”

This is where the system interface lives:

task switcher, status bar, notifications, “home screen”, system dialogs.

In WEFT OS, this entire room is a single web page running in an embedded browser engine.
The App Rooms – “app runtimes”

Each app gets its own small, locked‑down room.

Inside it runs app logic and UI, also driven by web technologies and WebAssembly.

Every app room is separate from every other app room.

The key is how these rooms talk.

In WEFT OS, they don’t reach into each other’s memory.

They send messages over well‑defined channels, like people passing written notes under the door.

That sounds slow and over‑engineered.

But it buys you three things that are very hard to retrofit into a traditional desktop OS:

Crashes are contained.
Permissions are explicit.
Behavior is inspectable and testable end‑to‑end.

What Actually Happens When You Launch An App

Let’s walk through a concrete example: opening a “Notes” app on WEFT OS.

1. You click the icon

You see a system UI page — think of it like a “desktop” or “home screen.”
That UI is just HTML + CSS + JavaScript rendered by Servo (a modern browser engine).
You click the “Notes” icon.

2. The click becomes a message

Instead of launching some random binary directly, the system UI sends a structured message to a background service:

“Please start app com.example.notes for session 12345.”

This background service is the app daemon.

Its job is to manage app lifecycles: start, stop, track state.

3. The daemon sets up a safe environment

Before any app code runs, WEFT OS:

Works out which files and folders the app is allowed to see.

For example: a per‑app data directory, maybe a shared “Documents” folder, nothing else.
Optionally launches a file portal process.

This is a small helper that sits between the app and your real filesystem.

The app asks the portal to read or write files; the portal enforces the rules.
Prepares IPC sockets (communication channels) so that:
- The app can send and receive messages (for example, to the system UI).
- The system can observe and control its lifecycle.

Only after all that is in place does the daemon start the app’s runtime process.

4. The app starts and announces “I’m ready”

Inside the app room, the runtime boots:

It loads the app’s code (WebAssembly / web code).
It sets up the local environment (permissions, pre‑opened directories, IPC).
Crucially, it does not get full system access; it only sees what was explicitly granted.

When initialization is complete, the app runtime simply prints one line:

READY

The daemon watches for that.

If it doesn’t see READY within a fixed time window, the daemon:

Kills the app process.
Cleans up its file portal.
Marks the session as “Stopped”.
Notifies the rest of the system that this launch failed cleanly.

If it does see READY, the daemon:

Marks the session “Running”.
Sends a message back to the system UI: “Notes app session 12345 is ready.”
Optionally launches a per‑app UI shell (another browser instance) to render the app’s front‑end.

The result: when the Notes window appears, it has already proved that:

Its code loaded correctly.
Its IPC channels work.
Its basic environment is valid.

There is no half‑started zombie process hanging around.

Why This Is Different From “Just Use The Browser”

You could ask: why not just run everything in browser tabs?

Three big differences:

Ownership of the screen

In WEFT OS, the compositor is not the browser; it is the OS component that controls displays and input directly.

The system UI and apps are guests in that space, not owners of it.
Hard isolation by process

Each app runs in its own dedicated process with a very narrow view of the filesystem and OS services.

It doesn’t share memory with other apps.

If the app crashes, the compositor and system shell stay alive.
IPC as a contract, not an afterthought

Instead of arbitrary internal calls, components communicate via structured messages with clearly defined types.

For a senior architect, this looks much more like micro‑services than a monolithic desktop shell.

You still get the productivity of the web stack, but on top of an OS that behaves more like a collection of small, cooperating services than a single giant program.

Reliability: What Happens When Things Go Wrong

Because everything is separated, WEFT OS can make failure a first‑class case, not an exception.

A few concrete examples:

Example 1: App never says “READY”

The app starts, but never prints READY — maybe it’s stuck in initialization, or crashed silently.

What WEFT OS does:

Waits up to a fixed timeout (e.g. 30 seconds).
If READY never appears:
- Kills the app process.
- Shuts down the app’s file portal.
- Marks the session as Stopped.
- Broadcasts that new state to anyone interested (e.g. the system UI).

To the user, this looks like:

“Notes failed to start. Try again or check logs.”

To an architect, this is:

A clear state machine: Starting → Running or Stopped.
No “half alive” processes.
A single place (the app daemon) responsible for enforcing this policy.

Example 2: UI shell can’t create a window

The UI shell is the embedded browser used to render the system UI or an app window.

If window creation fails (for example, graphics issues), WEFT OS:

Logs a clear error.
Exits the shell process cleanly.
Tells the event loop to stop instead of panicking the whole program.

The compositor itself stays alive; it doesn’t crash just because an app window failed to open.

Example 3: Background IPC channel dies mid‑session

Apps talk to the daemon and other components over local sockets.

If that socket breaks:

The daemon notices.
It cleans up the session and updates state.
The system UI can show “Disconnected” instead of hanging indefinitely.

These are small details in code, but collectively they define a failure‑aware OS, where the normal path and the error path are equally designed.

Security and Privacy: Capabilities, Not “All Or Nothing”

Traditional desktop apps often see your entire home directory by default.

On phones, apps ask for broad permissions: “Photos”, “Files”, etc.

WEFT OS takes a narrower approach:

Each app declares capabilities such as “needs persistent app data” or “needs access to Documents”.
The app daemon turns those into pre‑opened directories: “You can see /data and /xdg/documents, nothing else.”
A separate file portal process enforces this at runtime:
- It receives file read/write requests from the app.
- It checks them against the allow‑list.
- It can log or deny anything outside the allowed paths.

To a non‑technical user, this means:

“An app only sees the folders it really needs, not your whole system.”

To an architect, it means:

No direct filesystem syscalls from app code to arbitrary paths.
A single choke point for policy (the portal).
Easier reasoning about what data an app can touch.

Why Architects Might Care

From a systems‑design point of view, WEFT OS has a few interesting properties:

Clear component boundaries
- Compositor: owns displays and input.
- Shells (system + per‑app): own UI and user interactions.
- App daemon: owns lifecycle and session state.
- Runtime: owns execution of app code.
- File portal: owns filesystem policy.
Everything talks via messages

IPC is not a side detail; it is the backbone of the system.

That makes it possible to:
- Trace flows end‑to‑end.
- Test components in isolation with fake messages.
- Swap implementations without changing contracts.
Failure is explicit

Timeouts, missing binaries, socket errors, window creation failures — all mapped to:
- Well‑defined log messages.
- State changes (Starting → Stopped).
- Predictable cleanup.
Web UI without “Electron bloat”

Instead of every app bundling its own browser, the OS provides a shared, deeply integrated browser engine as a core service.

Apps are guests; the OS remains in charge.

You can think of WEFT OS as a small, service‑oriented system for running web apps, rather than “yet another Linux desktop.”

Why Non‑Technical People Might Care

If you are not a systems engineer, most of the above might sound abstract.

Here is what it means in everyday terms:

Apps feel like websites, but behave like proper apps.

They can send notifications, access your files (within limits), and integrate into the system UI.
Crashes are less scary.

If your Calendar app dies, it should not bring down your whole desktop.
Permissions are more understandable.

Instead of giving apps the keys to everything, the OS can say:

“This app can only see this folder and talk to this service.”
It is easier to inspect and debug problems.

Because everything is message‑based, operators and developers can see where something went wrong:

“The app never sent READY”, “The IPC channel broke”, “The portal denied this path”.

Closing Thoughts

WEFT OS is not trying to compete with the big general‑purpose desktops on features.

Instead, it explores a focused idea:

Web technologies as the primary UI.
Small, isolated runtimes for each app.
A compositor and daemon that treat contracts, capabilities, and failures as first‑class citizens.

If Firefox OS was an early experiment in “the web as an OS,”

WEFT OS is a modern, more careful experiment in “the web, but with strong isolation and explicit contracts.”

For non‑technical readers, the takeaway is:

This operating system is built so that apps behave more like well‑behaved website tabs, and less like all‑powerful desktop programs.

For architects, the takeaway is:

This is a message‑driven, componentized OS with clear boundaries, capability‑based access, and designed‑in failure handling — using the web stack as its primary UI layer.

If you are curious, the next step is simply to explore:

read the architecture docs, look at how sessions move from “Requested” to “Running” to “Stopped,” and see how much complexity disappears once you treat the OS itself as a set of contracts between small, cooperating processes.