DEV Community: Art

A CMS with no database and no build step: your site is just a Git repo

Art — Wed, 30 Sep 2026 06:55:05 +0000

Recently Angela, a musician, sent me the link to her new website: music.angela-mahr.de. She built it herself. She didn't use a page builder or a WordPress theme. She told Claude Code what she wanted, and it wrote the pages for ForgeCMS, the small CMS I've been building since March. Then she built a second one: lebe-dich.info.

That's when I realized the design decisions behind ForgeCMS might be interesting to other developers too. This post explains how it works and why it's built this way.

The whole architecture in one line

Browser → Caddy (TLS) → forgecms → Codeberg (SML + Markdown)
                                   ↘ local cache

ForgeCMS is a single Go binary. Your site is a folder in a public Git repo: pages in SML, longer texts in Markdown, images in static/. When a request comes in, ForgeCMS fetches the files it needs from Codeberg, caches them, and renders HTML.

That means:

No database. Your history, backups and reviews all happen in Git.
No build step. Commit a change (even in Codeberg's web editor), and it's live within a few minutes. There's no CI pipeline and nothing to regenerate.
No admin backend to patch, and no plugin ecosystem to keep compatible.
One process, many domains. Put one config per domain in sites/<domain>/app.sml, and ForgeCMS switches to multi-site mode. Our production box serves eight sites from one process.

The dependencies are the Go standard library, goldmark for Markdown (with chroma for code highlighting), and sml-go for the page language.

Pages in SML, not JSON or YAML

Pages are written in SML: elements with properties and children. Here's a complete page:

Page {
    title: "My Bakery"

    Heading { level: "1" text: "Fresh bread, every morning" }
    Markdown { src: "main.md" }

    Cards {
        Card { title: "Sourdough" text: "Baked daily from a 12-year-old starter." }
        Card { title: "Opening hours" text: "Tue–Sat, 7:00–13:00" }
    }

    ContactForm { }
}

You don't need HTML, CSS or JavaScript. SML is also a format that language models get right on the first try. It has no indentation rules to break, no quoting puzzles like YAML, and no trailing-comma errors like JSON. Every element is written the same way, so a model that has seen three examples can write a fourth.

That's the real reason Angela could build her site. The repo contains an AI.md that explains the whole system to a coding agent: the elements, the folder layout, how languages work, and how to deploy. You point Claude Code at it and describe the site you want.

"Why not a static site generator?"

I get this question a lot, and it's a fair one. Hugo and friends are great. What bothered me is the part between "I changed a sentence" and "it's live": a build, a pipeline, an artifact, a deploy. For the people I build sites for (small associations, therapists, musicians), that pipeline is exactly where things break and where they need me.

With ForgeCMS the repo is the deployment. Anyone who can edit a file on Codeberg can update their site. If they break the syntax, the last good version keeps being served. A typo never takes the site down.

What I learned the hard way: caching against a Git host

Fetching content from Codeberg at request time sounds fragile, and the first version was. On September 25, after a routine restart, a burst of bot traffic made ForgeCMS fetch the same 404.sml about 800 times. Codeberg allows 250 raw-file requests per 10 minutes per IP. We got a 429 with Retry-After: 600, and three sites returned 503 for about 20 minutes.

The fix was three rules that I now think every "fetch from origin" system needs:

Revalidate at most every 5 minutes per file, no matter how many requests come in.
Use one shared backoff for the whole origin, and respect Retry-After. When Codeberg says "wait", every file waits, not just the one that got the 429.
Always serve the stale copy when the origin fails. A slightly old page is better than an error page.

With those rules, Codeberg can have a bad day and visitors don't notice. The same fallback also works for static files: if an image isn't deployed on the server, ForgeCMS fetches it from the repo's static/ folder. This morning I added the banner at the top of this post to our developer page with nothing but a git push.

Modules for the boring-but-necessary parts

The core covers pages, menus, themes, several languages per site (a de/, es/, … subfolder with fallback), per-page SEO descriptions and embeds. The things that need server-side state are modules in the same binary. You switch them on with a block in app.sml:

Blog with photos, Atom feed and share buttons without trackers (live)
Events with flyers, event pages and .ics export (demo)
Contact form and newsletter with form fields defined in SML, double opt-in and mailings written in Markdown (live)
Shop paid in Ğ1 or euros, with digital delivery
Feature requests with voting and magic-link login (live)

Whatever these modules need to store, like orders or subscribers, is written as small SML files on the server. There's still no database.

Quickstart

You need Go 1.22 or newer and a public repo on Codeberg for your content.

git clone https://codeberg.org/CrowdWare/ForgeCMS.git
cd ForgeCMS
go build -o forgecms .

# point the Site { } block at your content repo
cp app-demo.sml app.sml

./forgecms --port 8080

Put Caddy in front for HTTPS and you're done. For a real multi-site setup, our production repo is public: CrowdWare/sites contains the content, the per-domain configs and the deploy script for every site mentioned here. The page describing ForgeCMS for developers is one SML file in that repo.

License

ForgeCMS is free under the GPLv3 for non-commercial use. If you make money with it, for example by hosting sites for paying customers, there's a commercial license. Profits aren't paid out to individuals. They go into UBUNTU land projects.

Try it, break it, tell me

Everything in one place: crowdware.info/forgecms/developers

Source: codeberg.org/CrowdWare/ForgeCMS
Missing something? Propose a feature or vote. The most-voted requests get built first, and four of the first five are already done.

I'd especially like to hear from people who run sites for others: what would you need before you'd move a client off WordPress?

ForgeCMS: a CMS without a database, and our users decide what gets built next

Art — Tue, 29 Sep 2026 08:03:02 +0000

Six months ago ForgeCMS was a weekend experiment: can a website run without WordPress, without a database and without a build step? Today it runs several real sites, and it covers most of what a small business, an association or a creator needs from a website.

This post gives an overview of what's there, how it works, and how you can tell us what should come next.

The idea in one paragraph

ForgeCMS is a single Go binary. Your content lives as Markdown and small SML files in a Git repo on Codeberg. The server fetches the files at request time, caches them, and renders HTML. There's no database, no admin backend to keep patched, and no build pipeline. You edit a file in Git, and a few minutes later the change is live.

What a page looks like

Pages are written in SML, a simple markup of nested blocks with properties:

Page {
    title: "My Bakery"

    Heading { level: "1" text: "Fresh bread, every morning" }
    Text { value: "Family-owned bakery in Wittenberg. Stone oven, no additives." }

    Cards {
        Card { title: "Sourdough" text: "Baked daily from a 12-year-old starter." }
        Card { title: "Opening hours" text: "Tue–Sat, 7:00–13:00" }
    }

    Link { href: "mailto:hallo@meinebaeckerei.de" text: "Get in touch" }
}

Longer texts are plain Markdown. You can read SML in seconds, and it turns out an AI can write it just as easily. That was a deliberate choice: many of our sites are edited by describing the change to Claude Code on the server, and it gets SML right on the first try.

What's already in the box

The free core covers:

pages in SML and Markdown, menu, footer, themes
multiple languages: a de/, en/, es/ … subfolder per language, with fallback to the default
menu, footer and routes can live in the content repo too, so editing the site never requires touching the server
sliders, cards, tables, images, YouTube embeds, privacy-friendly analytics (Umami)
a content cache that keeps serving the last good copy if Git hosting is slow or down

On top of that there are modules, each built for a real site:

Module	What it does
Blog	Posts with photos, pages, Atom feed, drafts and scheduled posts, share buttons without third-party scripts, several languages
Events	Dates and gigs with flyer thumbnails, an event page per date, past events, `.ics` calendar export
Contact form	Text fields, checkboxes, radio buttons, selection lists; messages go by email and are not stored
Newsletter	Double opt-in, mailings written in Markdown in a small admin page, one-click unsubscribe (RFC 8058)
Shop	Physical and digital products, paid in June (Ğ1) or by euro bank transfer, no payment provider
Feature requests	Visitors propose features and vote, one vote per person

Everything that needs to be stored, like orders or newsletter addresses, is stored as small SML files on the server. Still no database.

A few of these are running in public:

the blog: art.ubuntu-pirates.com, a travel blog of a bike trip to Spain, written on the road
the events demo: crowdware.info/events-demo
the shop demo: crowdware.info/shop-module (the demo orders are real, you get a handwritten postcard)
contact form and newsletter: crowdware.info/contact

Login without passwords

The modules that need a login (feature voting, newsletter admin) use magic links. You enter your email address and get a link, and that's it. There are no passwords to leak and no accounts to manage. Login tokens live only in memory.

We use the email address for one more thing: it keeps feature voting fair. One address, one vote per request, and you can take your vote back any time. Nobody sees who voted for what.

You decide what we build next

This is the part I'm most happy with. On crowdware.info/forgecms/features anyone can propose a feature for ForgeCMS or vote for the ones they want. The requests with the most votes get built first.

It works. So far five features have been proposed:

Contact form — done
Event calendar — done
Blogging module — done (comments are not in yet)
Mailing list — done, as the newsletter module
Online course (lessons with videos and texts, saved progress) — open

That's four out of five done within a few days of being proposed. The online course is the next candidate, and if it matters to you, a vote helps.

The voting page itself is the feature-request module, so you're testing it while you use it.

Hosting: small and cheap

ForgeCMS needs very little. All our sites share one small VPS with a single forgecms process behind Caddy, which takes care of HTTPS. A €1/month VPS is enough for a small site. The README walks you through setting one up with Claude Code doing the work, even if you've never run a server.

License and pricing

The core is open source under GPLv3. For commercial use there's a commercial license.
Modules are a one-time license of €19 to €39, with no subscription. All six together cost €139.
If you'd rather not do it yourself, we build the site for you at €130/hour (or 130 Ğ1). Small sites are often done in an hour.

If we ever make a profit, it isn't paid out to individuals. It goes into UBUNTU land projects that take land out of speculation.

Try it, and tell us what's missing

Propose or vote for a feature: https://crowdware.info/forgecms/features
Overview and modules: https://crowdware.info/forgecms
Source code: https://codeberg.org/CrowdWare/ForgeCMS
Get in touch: https://crowdware.info/contact

I'd love to hear what you would need before you'd move a site off WordPress. The best place for that is the feature request page, because there it gets votes.

A web shop without a database or payment provider: the ForgeCMS shop module

Art — Sat, 26 Sep 2026 15:14:42 +0000

Today the shop module for ForgeCMS went live. Your customers can pay in two ways:

in June (Ğ1), a free currency, or
in euros by plain bank transfer.

There's no database, no payment provider taking a cut, and no monthly fee. The money goes straight from the buyer to the seller.

This afternoon I paid for my own test order with 1 Ğ1. Three minutes later the shop had marked the order as paid and sent me my download link.

👉 How it works for shop owners: https://crowdware.info/shop-module

Some context: what ForgeCMS is

ForgeCMS is a small CMS written in Go. It has no database and no build step. Pages are small SML files plus Markdown in a Git repo on Codeberg. The server fetches them at request time, caches them, and renders HTML. You edit a page in Git, and a minute later it's live.

I wanted a shop that fits into this. It shouldn't need a database, it shouldn't need an account with a payment company, and it shouldn't hand buyers' data to anyone else.

Why June (Ğ1)?

Ğ1 is a libre currency that has been running since 2017. Every member creates a small share of new money each day, the universal dividend, so it works a bit like a basic income built into the currency. Since March 2026 it has been running on Duniter v2, a Substrate-based blockchain. It's not a speculative token, and people in the network use it to pay for goods and services.

For a shop, what matters is that every transfer is public and carries a comment. The buyer puts the order number in the comment, and the shop can find the payment without any access to the seller's wallet.

The catalogue is one text file

Catalog {
    Product { id: "honey-500" title: "Honey 500 g" price: "12.50" priceEur: "9.90" image: "honey.jpg" text: "From our own bees." }
    Product { id: "ebook" title: "My e-book" price: "20" type: "digital" text: "PDF, 120 pages." }
}

price is the price in Ğ1, and priceEur the price in euros. A product with both prices lets the buyer choose. A product with only one price is sold only in that currency. On a page, Products { } renders the product cards with an Order button.

The price always comes from the catalogue, never from the order form.

How an order flows

The buyer fills in a short form: quantity, name, email, and for physical goods a shipping address. Then they click Place order (payment required).
The server writes the order as a small SML file to disk, e.g. G1-7KQ2MXRA.sml, and sends two emails, one to the buyer and one to the seller.
The buyer sees a payment page with the address, the exact amount and the order number.
The buyer pays and puts the order number into the transfer comment.

Detecting Ğ1 payments

A watcher goroutine asks the public Duniter indexer once a minute for new transfers to the shop's address. The indexer has a GraphQL API:

transfers(filter: {toId: {equalTo: $wallet}, blockNumber: {greaterThan: $from}}) {
  nodes { id blockNumber amount fromId comment { remark } }
}

A transfer is matched to its order by the comment. The watcher waits 10 blocks of confirmations (about a minute) before it counts a payment. Split payments add up, and overpayments are recorded. A transfer without a matching order doesn't get lost: the seller gets an email and sorts it out by hand. The last processed block is stored in a small state file, so a restart doesn't skip or double-count anything.

The server never holds a wallet key. It only reads public data.

Euro payments: one click by the seller

For euros the shop doesn't connect to any bank. There's no banking API and nobody else sees your account. The seller's order email contains a secret confirmation link. When the money is on the account, the seller clicks it, checks the amount on the confirmation page and confirms. From there everything runs the same way as with Ğ1.

Digital delivery

For downloads, the paid email contains a license key and a personal download link:

The link is valid for 30 days and 5 downloads.
The server stores only a SHA-256 hash of the link's token, never the token itself.
The files don't live in the public content repo. They live in a data folder on the server, and the download handler rejects path traversal and symlinks.
Before ordering a digital product, the buyer ticks a box saying delivery may start immediately. German and EU law require this so the right of withdrawal ends with the download.

What it deliberately doesn't do

no shopping cart: one product per order, any quantity
no credit cards, PayPal or Stripe
no stock management and no automatic invoices
euro payments need one click from the seller

For a small shop, a creator, a farm shop or a community project, that's usually enough. Every feature I left out is one less thing that can break.

Tested for real

Before going public, I ran the whole flow on the live site with a hidden test page:

Euro: a transfer of 0.01 EUR, confirmed with the link. The order was marked as paid and the emails went out.
Ğ1: 1 Ğ1 for a digital test product. It was detected after 10 confirmations, the order was marked as paid, and the download link arrived by email and worked.

Then I removed the test page.

Try it

See how it works: https://crowdware.info/shop-module
What is June? https://crowdware.info/june
ForgeCMS source (GPLv3): https://codeberg.org/CrowdWare/ForgeCMS

The shop module is a one-time €39 license, with no subscription. If you'd like a shop on your own website, whether you sell in June, in euros or both, get in touch.

If you already use Ğ1, I'd love to hear how you currently sell things with it and what's missing.

ForgeDesigner Alpha: an AI assistant that builds websites on your own machine

Art — Thu, 24 Sep 2026 06:49:12 +0000

Today I'm releasing the first alpha of ForgeDesigner for macOS (Apple Silicon) and Linux (x86_64).

ForgeDesigner is a small desktop app where you describe a website in plain words and an AI assistant builds it: it creates the pages, writes the Markdown, and shows you a live preview. The result is plain files in a folder on your disk. You don't need a hosting account, you don't get locked into a page builder, and nothing lives in somebody else's cloud unless you put it there.

👉 Download: https://codeberg.org/CrowdWare/Forge4D/releases/tag/v2026.9.23-forgedesigner-linux

Why I built it

I wanted something between "hand-write HTML" and "rent a website builder". The things people use today, WordPress, website builders and IDEs, all ask you to learn their world first. I wanted a single place where I can say "make me a landing page with a short intro and a contact section", then look at the files, change a sentence by hand, and ask for the next step.

ForgeDesigner is built on Forge 4D, an open platform where apps are written in two small languages:

SML (Simple Markup Language): declarative UI and content
SMS (Simple Script): event handlers and logic

The whole designer UI, including the docks, the file tree, the editor and the assistant tab, is itself an SML/SMS app running on the native Forge runner (C++ on top of Godot 4.6). A few lines from its layout:

DockingContainer {
    id: rightDock
    dockSide: right

    VBoxContainer {
        id: preview
        rightDock.title: @Strings.tabPreview
    }
}

What works in this alpha

AI assistant with tools. The assistant can list_files, read_file, write_file and run_command inside your workspace folder (~/ForgeWorkspace/...). You watch it work in the transcript, and the file tree updates as files appear.
ForgeCMS plugin. The first output target: pages as SML plus Markdown, ready to be pushed to a Git repo and served as a static site.
Live preview. Select a page or a Markdown file and see a layout preview next to the editor.
Editor that stays in sync. Every keystroke is saved, and changes the assistant makes show up in the editor right away.
Offline by default. Out of the box the assistant runs against a built-in mock: it's free and sends nothing anywhere. Switching to a real model is one config line (see below).
Retries. If the model provider answers with "overloaded", the request is retried automatically; after that there's a Retry button.

Security model

An AI that can write files and run commands on your machine needs guard rails. ForgeDesigner has these:

Permissions are declared and confirmed. The app lists what it needs (workspace files, running programs after asking, network access to openrouter.ai), and the runner asks you once on first start.
Commands are argv, not shell strings. A small set (git, ls, cat, ssh, scp) runs directly. Everything else opens a dialog where you decide, once or for good.
API keys stay in the runner. Your key lives in a chmod 600 file in the runner's data folder and is never handed to the app or the model.

Prompt injection is still a real risk. The trusted commands can reach whatever your user can. That's a big part of why this is an alpha.

Try it

macOS (Apple Silicon): unzip, then remove the quarantine flag once. The alpha is only ad-hoc signed.

xattr -dr com.apple.quarantine ForgeDesigner.app

Linux (x86_64):

tar xzf ForgeDesigner-2026.9.23-linux-x86_64.tar.gz
./ForgeDesigner/ForgeDesigner.x86_64

Connect a real model (OpenRouter)

Create a key on openrouter.ai (Keys → Create Key). Models ending in :free need no credit.
Open the app's data folder:
- macOS: ~/Library/Application Support/Godot/app_userdata/ForgeDesigner/
- Linux: ~/.local/share/godot/app_userdata/ForgeDesigner/
Put the key into forge_ai_keys.sml and run chmod 600 forge_ai_keys.sml:

   Keys {
       openrouter: "sk-or-v1-..."
   }

In forge_ai.sml, switch the provider:

   Ai {
       provider: "openrouter"
       chatModels: "qwen/qwen3.8-27b:free, nvidia/nemotron-3-super-120b-a12b:free"
   }

The first model is used, and the others are fallbacks. Free models come and go, so check the current ones with tool support.

Send your next message. No restart needed.

Known rough edges

macOS build is Apple Silicon only and not notarized; Linux build is x86_64 only. No Windows build yet.
ForgeCMS is the only output plugin so far.
Free models are sometimes overloaded or change without notice.
The UI still has a few leftovers from its origins as an SML editor.

What's next

Deploying a site straight from the app (Git push + SSH)
More output plugins: HTML, Android, macOS apps, and books (chapters by prompt, export to PDF/EPUB)
Finer-grained "always allow" rules for commands like git and ssh

The code is open source (GPLv3, with a commercial license available) on Codeberg: https://codeberg.org/CrowdWare/Forge4D

If you try it, I'd love to hear what broke, what felt wrong, and what you'd build with it. Issues and comments welcome! 🌱

Sustainable Web Design with the Help of AI (Workshop)

Art — Thu, 17 Sep 2026 09:36:30 +0000

Your website probably weighs more than it should

Page builders with a hundred plugins. Subscription fees stacked on subscription fees. Hosting bills that make no sense for a five page site. Most of the modern web is built on foundations that waste energy, waste money and waste your time.

I'm running a hands on workshop that takes the opposite approach: lean by default. No database, no plugin jungle, no bloated hosting, and AI used as a real tool, not a crutch that writes code you don't understand.

What you'll actually learn

A practical approach to sustainable, low overhead web design
How to use AI effectively in the design and build process, without losing control over the result
The mindset behind ForgeCMS: no database, no plugin jungle, no subscription trap

Who this is for

Freelancers, small teams, or anyone maintaining a website who is tired of the usual bloat and curious about a leaner, AI assisted alternative to conventional web development.

Format and pricing

One day: 4 hours, 130 EUR
Weekend: 2 x 4 hours, 250 EUR

(plus venue rental)

Want in?

Details and contact here: crowdware.info/workshop

No obligation, I reply personally, usually within a day.

Built with love, coffee, and a stubborn focus on simplicity. That's the whole philosophy, and it's what you'll walk away with.

Code & Koje: Building Software with AI, Aboard a Sailboat in the Mediterranean

Art — Sun, 23 Aug 2026 21:53:19 +0000

I'm Olaf, a freelance software architect with over four decades of IT experience, an open source developer at CrowdWare, and starting in September I'll be sailing my ketch Deep Blue toward the Mediterranean.

And I'm bringing people along.

(Koje is German for a ship's bunk, hence the name.)

The Idea

A weekend on board, somewhere in a marina in the Mediterranean. No seminar room, no slide deck, just a real boat, real remote work vibes, and hands on work building software with AI as a tool.

For 3 to 4 people: students, aspiring developers, or anyone already in software who wants to see what working with AI actually looks like instead of just reading about it.

What You'll Build

This first weekend is all about ForgeCMS: build your own website, no WordPress bullshit anymore. Later sessions will move into Forge4D, building actual apps.

What You Get

Hands on experience developing with AI assistance
Insight into cross platform development and open source workflows
An Android tablet (worth about 120 EUR) and a solar panel (worth about 80 EUR) to keep, so you're set up to keep working and learning afterward
A weekend that feels like a change of scenery, not a course
Conversations about remote work, self employment, and life outside the classic office job

Cost

A deposit of 200 to 250 EUR is due in advance, covering your Android tablet and solar panel. The course itself is around 250 EUR per person, on top of the deposit.

When and Where

Departure is early September, first leg heading south. There's a good chance the first sessions could happen along the way, even before the boat finds its winter berth in the Mediterranean. Exact dates and locations to follow here and on my channels.

Interested?

Reach out if you want to join or just have questions. Happy to chat either way, whether it turns into a booking or not.

Code & Koje: where software development meets sailing romance.

https://codeberg.org/CrowdWare

ForgeIL Has Been Self-Hosting Since May. Nobody Found It

Art — Mon, 22 Jun 2026 23:53:38 +0000

ForgeIL Has Been Self-Hosting Since May. Nobody Found It Yet.

It got quiet here for a month. Not because the project stalled, but because life moved.

I moved aboard my ketch, Deep Blue, now anchored in Rostock. A new band started rehearsing at a spot near the Admiralbrücke in Kreuzberg, we even found a proper rehearsal room now. Friends, a new city for some of it, a different rhythm. Good kind of busy.

But here is the thing I noticed once I surfaced again: ForgeIL has been sitting there, self-hosting, since the Sprint 4 post in May. 62 tests passing. The SMS compiler compiling itself to LLVM IR. And in a month, basically nobody picked it up.

That is not a complaint. It is just true, and it bugs me a little. Not because I need the attention, but because the thing is actually useful and almost nobody knows it exists yet.

So this post is not a new technical milestone. It is a reminder, and an invitation.

What ForgeIL Actually Is

ForgeIL is the language family behind the Forge ecosystem at CrowdWare. Two parts, one intention:

SML (Simple Markup Language) describes structure. UI layout, app shape, content.
SMS (Simple Multiplatform Script) describes behavior. Logic, compiled ahead of time through LLVM to native code.

No virtual machine. No garbage collector. Events resolve at compile time, not through a runtime dispatcher, which is part of why SMS event dispatch measured at 4.6 nanoseconds in earlier benchmarks, ahead of C++, C# and Kotlin Native, with only Kotlin JVM's JIT still ahead.

And as of Sprint 4, the compiler compiles itself. Lexer, parser and LLVM IR emitter, all written in SMS, all proven self-hosting. No C++ toolchain required to keep developing SMS itself anymore.

Why That Matters More Than It Sounds

A self-hosting compiler is a small thing to read about and a real threshold to cross. It means the language is no longer just describing other programs, it can fully describe and rebuild itself. That is the point where a language stops being a personal project and starts being able to outlive its author.

This is built under CWUP, the workflow I use across the whole stack: Claude as architect, Codex as coder, Claude back for review. Each sprint specified, implemented, checked, before the next one starts. If you are curious how far AI-assisted development can responsibly go on something as precise as a compiler, this is a working example, not a pitch.

And underneath all of it sits one constraint that never gets compromised: Ahimsa, do no harm to any living being. No telemetry by design, no dark patterns, no lock-in. Dual licensed, GPL3 for the community, commercial for those who need it, same model Qt has used for years.

The Actual Ask

I am not looking for employees or a funding round. I am looking for people who read "self-hosting compiler that compiles itself through LLVM, in a language with zero-cost UI events" and feel a small pull toward it.

If that is you, here is where to start:

The code lives at codeberg.org/CrowdWare
Look at the ForgeIL repo for the language docs and the self-hosting compiler source
Try compiling something small, break something, open an issue, ask a question, anything

You do not need permission to poke around in open source. You need a reason to. Maybe this is it.

Aho 🌱

ForgeIL is the language layer of Forge 4D, a cross-platform app framework built around SML and SMS, native compiled, targeting Android ARM today with more platforms ahead. Dual licensed GPL3/commercial. Everything developed in the open.

Why SML/SMS doesn't run on Windows - and why that's a feature

Art — Mon, 11 May 2026 17:31:46 +0000

Let me tell you a story.

I was leading a raid in World of Warcraft. 24 people. Everyone waiting on me. And Windows decided that exact moment was the perfect time for an update. No warning. No mercy. Just a reboot.

I switched to Mac the next day.

For years it was great. Steve Jobs understood something most tech CEOs never will: the user is not the product. The user is the guest. You treat guests with respect.

Then Steve left us.

And slowly - update by update, policy by policy - Apple became just another corporation. A beautiful one. But one that now decides what software you can run, what hardware you can repair, and what belongs to you and what belongs to them.

So here we are.

We are building SMS - a programming language that compiles to native binaries via LLVM. Open source. GPL-3. No telemetry. No stakeholders. No investors.

It runs on Mac and Linux. Not on Windows - and that is not an oversight. That is a choice.

Because we are not building for a world where your OS reboots your raid.
We are not building for a world where a corporation decides what runs on your machine.
We are building for the world we actually want to live in.

Ahimsa. Do no harm. Not even to your users.

If you are on Windows and want to try SMS - WSL2 works fine. One small rebellion inside the machine.

But if you are tired of building software on platforms that belong to someone else - come build with us.

SMS is free. Linux is free. Your time is not.

https://codeberg.org/CrowdWare/sms-cpp

ForgeOS Dojo - learn AI-assisted development, build something that matters

Art — Mon, 11 May 2026 17:08:06 +0000

"No Stakeholders. No Investors. Just Users."

In 28 days we built a new programming language from scratch.
Today it compiles itself.

Now we want to go further - together.

We are opening the ForgeOS Dojo: a learning community where you will master AI-assisted software architecture while building something real.

Not a todo app. Not another CRUD API.

An entire mobile OS. Free. No ads. No forced updates. No spyware.

You will learn:

How to work with AI as your architect (Claude) and your coder (Codex)
Sustainable software design - less code, more intention
SMS - our scripting language that now compiles itself to native binaries
How to ship real software that respects its users

What we build together:

ForgeOS - a mobile OS built on SMS and C++
Ahimsa as the single constitutional principle: do no harm - not even to your users

No prior OS experience needed. Just curiosity and the will to build something that matters.

If you are tired of building software for companies that spy on their users - this is your Dojo.

Drop a comment or follow CrowdWare on Codeberg:
https://codeberg.org/CrowdWare

We Wrote a Compiler in the Language It Compiles. It Works.

Art — Mon, 11 May 2026 16:49:00 +0000

Four sprints. One afternoon. 62 tests, all green.

ForgeIL is the compiler layer of Forge - an open source UI framework built around
a radical simplicity: one language, one binary, no runtime installation.

The Idea

There is a test every language eventually faces. Not a benchmark. Not a syntax
comparison. A question:

Can the language compile itself?

A self-hosted compiler is the closest thing software has to a proof of maturity.
If the language can express a lexer, a parser, and a code generator - and the
result of running that code is a working binary - then the language has crossed
a threshold. It is no longer a demo. It is a tool.

SMS is the scripting language at the heart of Forge. It is interpreted at
development time and compiled to LLVM IR at release time. We decided to test
whether SMS could implement its own compiler front-end: a lexer, a parser, and
an LLVM IR emitter - all written in SMS itself.

Four sprints. One afternoon. It works.

What We Built

The self-hosted compiler lives in the forgeil/ directory of
sms-cpp - three SMS source files that
together form a complete compilation pipeline:

SMS Source
    |
    v
tokenize(src)        sprint1-lexer.sms     ->  array of Token
    |
    v
parse(tokens)        sprint2-parser.sms    ->  AST of Node
    |
    v
codegen(ast)         sprint3-codegen.sms   ->  LLVM IR text
    |
    v
clang                                      ->  native binary

A single convenience function wraps it all:

fun compile(src) {
    return codegen(parse(tokenize(src)))
}

That is the entire public API. Give it SMS source text. Get back LLVM IR.

Sprint 1: Lexer

The lexer turned out to be the place where SMS's integer-character API became
a design constraint rather than a limitation. str.charAt(i) returns the
integer char code of the character at position i. So the entire lexer is
built on integer comparisons - no regex, no character class library.

fun isAlpha(code) {
    return (code >= 65 && code <= 90) || (code >= 97 && code <= 122) || code == 95
}

fun isDigit(code) {
    return code >= 48 && code <= 57
}

Two-character operators (==, !=, <=, >=, &&, ||) are handled with
a single lookahead:

if (ch == 61) {  // '='
    if (i + 1 < len && src.charAt(i + 1) == 61) {
        tokens.add(Token("OP", "==", line))
        i = i + 2
    } else {
        tokens.add(Token("ASSIGN", "=", line))
        i = i + 1
    }
}

The result: tokenize(src) returns an array of Token(type, value, line) data
class instances. 12 tests, all green on the first run.

Sprint 2: Parser

A recursive descent parser, written in SMS, for SMS.

The interesting constraint here: SMS does not allow forward declarations. Every
function must be defined before it is called - except at the top level, where
all definitions are registered before main() runs. So mutual recursion between
parseExpr and parseStmt works perfectly, because both are defined at the
module level before any call site is reached.

The precedence chain follows the standard pattern:

parsePrimary -> parsePostfix -> parseUnary -> parseMul ->
parseAdd -> parseCompare -> parseEquality -> parseAnd -> parseOr -> parseExpr

One non-obvious detail: the parser cursor is a single-element array used as a
mutable integer box. SMS arrays are passed by shared reference - field
assignments inside helper functions are visible to the caller. This is how the
cursor advances across the recursive descent without needing a global variable.

fun curTok(cur, tokens) { return tokens[cur[0]] }
fun advance(cur)         { cur[0] = cur[0] + 1 }
fun consume(cur, tokens, expected) {
    var tok = curTok(cur, tokens)
    if (tok.type != expected) { ... }
    advance(cur)
    return tok
}

24 tests. All green.

Sprint 3: LLVM IR Emitter

The code generator takes an AST and produces a complete LLVM IR text string.
Integer-only subset: every SMS value is i64, variables use alloca (memory-form
SSA), and clang/llc applies mem2reg in the optimization pipeline.

The context object accumulates emitted instructions:

data class Ctx(tempCnt, labelCnt, code, terminated, loops)

Because SMS data class instances use shared references (shared_ptr under the
hood), every helper function that mutates ctx.code or ctx.tempCnt has its
changes visible to every other function holding the same ctx. This is the
foundation of the entire emitter design.

A comparison compiles to an icmp followed by a zext - because LLVM
comparisons produce i1 and SMS uses i64 everywhere:

if (op == "<") { emit(ctx, cmpReg $ " = icmp slt i64 " $ left $ ", " $ right) }
emit(ctx, reg $ " = zext i1 " $ cmpReg $ " to i64")

For a function like fun add(a, b) { return a + b }, the emitter produces:

define i64 @sms_add(i64 %_p_a, i64 %_p_b) {
entry:
    %a = alloca i64
    store i64 %_p_a, i64* %a
    %b = alloca i64
    store i64 %_p_b, i64* %b
    %t0 = load i64, i64* %a
    %t1 = load i64, i64* %b
    %t2 = add  i64 %t0, %t1
    ret i64 %t2
}

If the source contains a fun main(), a C-compatible entry point is appended:

define i32 @main() {
entry:
    %ret64 = call i64 @sms_main()
    %ret32 = trunc i64 %ret64 to i32
    ret i32 %ret32
}

19 tests. All green.

Sprint 4: End-to-End

The final sprint is the proof. A new C API function -
sms_native_execute_string_result - captures the string value produced by the
SMS interpreter, instead of the integer it previously returned. This lets the
host application receive the generated IR text directly.

The test then does exactly what you would do on the command line:

// 1. Run the SMS compiler in the interpreter, capture the IR string
std::string ir = get_ir(load_all(), "fun main() { return 42 }");

// 2. Write to a temp .ll file
// 3. Run: clang -O0 -o /tmp/test_bin /tmp/test.ll
// 4. Run the binary, check exit code == 42

Exit code 42. Not chosen at random. The compiler's first words are a nod to
the only question that ever mattered.

forgeil_sprint4_tests: all tests passed (7)

The pipeline holds for arithmetic, if/else branches, and while loops. The tests
skip gracefully when clang is not available, so they run cleanly in any CI
environment.

What the Numbers Look Like

Sprint 1 - Lexer        12 tests  v
Sprint 2 - Parser       24 tests  v
Sprint 3 - Code gen     19 tests  v
Sprint 4 - Self-host     7 tests  v
---------------------------------
Total                   62 tests  all green

What This Is Not

SMS is not trying to replace LLVM's front-end infrastructure. The self-hosted
compiler covers the integer-only subset of the language: functions, variables,
if/else, while, break/continue, arithmetic, and comparisons. Strings, arrays,
data classes, and the standard library are outside its current scope.

The point is not feature completeness. The point is that the language has
enough expressive power to reason about itself. That is a different claim - and
a meaningful one.

The Code

Everything is open source under GPL-3.0 (with a commercial option):

sms-cpp: codeberg.org/CrowdWare/sms-cpp
Lexer: forgeil/sprint1-lexer.sms
Parser: forgeil/sprint2-parser.sms
Code gen: forgeil/sprint3-codegen.sms
Tests: tests/forgeil_sprint{1..4}_tests.cpp

If you want to try it:

git clone https://codeberg.org/CrowdWare/sms-cpp.git
git clone https://codeberg.org/CrowdWare/sml-cpp.git
cmake -B build -DBUILD_TESTING=ON -DSML_CPP_DIR=../sml-cpp
cmake --build build
cd build && ctest -R forgeil --output-on-failure

*Forge is being built in public at crowdware.info.
SMS, ForgeIL, and the self-hosted compiler are part of a longer project:
a UI framework that runs anywhere without asking anything of the user's machine.

ListenCircle: A Digital Talking Circle for Real Human Connection

Art — Wed, 22 Apr 2026 19:13:27 +0000

We built ListenCircle to bring the ancient practice of the Talking Circle into the digital world.

It’s a space where every human being can speak and be heard — regardless of where they come from or what they believe.

No accounts. No logins. No stored identities. Just real people, listening.

🌿 What is a Talking Circle?

A Talking Circle is an ancient form of conversation:

People sit in a circle.

Whoever speaks holds the Talking Stick.

The others listen — without interrupting.

When the speaker is done, the stick passes to the next person.

ListenCircle brings this practice into the digital age — for Rainbow Gatherings, community meetings, and anywhere people want to truly listen.

⚙️ How it works

Creating a circle

Choose a language
Set a topic (or keep it open)
Decide:
- Open Circle — anyone can join
- Closed Circle — invite only
Limit participants (default: 13)

Joining a circle

Open circles appear in the lobby
Join instantly — no account needed
New participants must listen through one full round before speaking

🪶 The Talking Stick

Hold button → speak (push-to-talk)
Release → stick moves to next person
Strict order — no interruptions
Max speaking time: 3 minutes

💛 Reactions

While someone speaks, others can respond with:

🌿 Aho
♥ Thanks

The speaker sees them live.

🔐 Privacy by design

No accounts
No stored identities
No IP tracking
No persistent data

Audio runs peer-to-peer (WebRTC) — never through a server.

🏗️ Architecture

Go backend for real-time logic
WebSockets for signaling
WebRTC for direct audio
ForgeCMS for rendering UI via SML

Separation of concerns:

Backend = logic
CMS = UI

🛡️ Abuse protection (without logins)

Session tokens (not IP-based)
Rate limiting
Join throttling
Speaking timeout
Stick timing rules

All without breaking anonymity.

🚀 Why this matters

Most online communication is:

chaotic
interrupt-driven
attention-seeking

ListenCircle creates something different:

one voice at a time
real listening
no identity games

It’s not just a tool.

It’s a different culture of communication.

🔗 Open Source

👉 https://codeberg.org/CrowdWare/ListenCircle

🌱 Final thought

What happens when people are truly heard?

That’s what ListenCircle is exploring.

Status

It's not yet ready...we just started it today, but I just wanted to start a discussion and you may add feature requests. Just think about the outcome. Are we able to stop wars this way?

Btw...it's free and open source...host your own server on a 1,- EUR VPS.

AI Writes Your App. You Lose Your Job. Good.

Art — Sun, 19 Apr 2026 19:03:34 +0000

AI Writes Your App. You Lose Your Job. Good.

Before you close this tab — read the second sentence.

You will not be jobless. You will be work-free. Those are not the same thing.

The Fear Is Real

Let us not pretend it is not.

A developer spends years learning React, Kotlin, Swift, C#.
They build a career on that knowledge.
Then an AI arrives that can generate working code from a sentence.

The fear is legitimate. The question is whether the conclusion is correct.

What AI Actually Does to Development

Here is what happens when you ask an AI to build a React app:

It generates plausible-looking code
The hooks are slightly wrong
The state management is from a blog post written in 2021
The dependency array is missing two items
It works in the demo, breaks in production

React is complex enough that AI-generated code requires a developer
to review, fix, and understand every line. The developer is still fully employed.
They are just a reviewer now instead of an author.

This is not liberation. This is the same job with extra steps.

What Happens With a Simpler Language

SML and SMS are intentionally minimal.

SML has no lifecycle methods. No virtual DOM. No reconciler.
A Column contains children. A Button has text. An ID identifies an element.

Column {
    padding: 24

    Label {
        id: counter
        text: "0"
        fontSize: 48
    }

    Button {
        id: btnAdd
        text: "+"
    }
}

SMS has no async/await. No promises. No event bubbling.
Something happened. Here is what to do about it.

var count = 0

on btnAdd.clicked() {
    count = count + 1
    counter.text = count
}

The entire rule set fits in a single system prompt.
Including the things that trip up AI:

IDs are not strings. Write id: counter, not id: "counter".

Event handlers use dot notation. on btn.clicked(), not onClick.

Variables are global to the script. No closures, no scope confusion.

An AI given this context generates correct Forge apps on the first try.
Not approximately correct. Actually correct. Deployable.

The Loop Nobody Talks About

When AI can generate a complete, deployable app from a description,
the development loop changes:

Before:
  User idea → Designer → Review → Developer → QA → Staging → Production
  Time: weeks

With AI + Forge:
  User describes → AI writes SML + SMS → Push to Codeberg → Live
  Time: minutes

The developer is no longer the bottleneck between idea and reality.

This is where the fear comes from.
This is also where the opportunity comes from.

"But That Means I Lose My Job"

Let us be honest about what that job actually was.

Translating human intent into machine instructions.
That is the core of software development.
A human has an idea. A developer translates it into code the computer understands.

AI is getting very good at that translation.

But notice what disappears when the translation is instant:
the gap between thinking and building.
The weeks of meetings, handoffs, misunderstandings, revisions.
The user who forgot what they wanted.
The developer who built the wrong thing for three months.

That gap was not valuable. It was waste.
We called it "the development process" because we had no other way.

Arbeitslos vs. Die Arbeit Los

There is a distinction that English handles clumsily but the idea is clear.

Jobless — without income, without purpose, without dignity.

Work-free — freed from labor that a machine can do better.

These are not the same condition.

A farmer who gets a tractor is not jobless.
They are freed from breaking their back with a hand plow.
The question is whether they have land to farm with the tractor.

The question for developers is not "will AI take my job?"
The question is "what will I do with the time AI gives back?"

UBI Is the Bridge

Universal Basic Income — BGE in German — is the infrastructure
that makes this transition survivable.

Without it: AI replaces jobs, income disappears, people suffer.
With it: AI replaces jobs, basic needs are covered, time is returned.

The technology already exists to feed, house, and care for everyone.
The question has never been whether we can afford it.
The question has always been whether we choose to.

When a developer no longer needs to spend 40 hours a week
translating requirements into React components —
what does that time become?

What the Time Becomes

Time for the things that were always more important and always got postponed.

Being present with the people you love.

Learning something because it is beautiful, not because it is marketable.

Walking 12 kilometers into a forest to sit with strangers around a fire.

Doing your Kundalini practice before the day starts instead of at 11pm.

Building something because it should exist, not because someone is paying for it.

Software was never the point.

The point was always what software made possible.

The Honest Risk

We should not pretend this transition will be painless.

Between "AI can now do this" and "everyone has UBI" there is a gap.
People will lose income before the safety net exists.
That is real. That is happening now. It should not be minimized.

The answer is not to slow down the technology.
The answer is to build the safety net faster than the disruption spreads.

That is a political problem, not a technical one.
Developers who understand both the technology and its consequences
are exactly the people who should be in that conversation.

What Forge Is Actually For

Forge was built for a world where the gap between idea and running app
is measured in minutes, not months.

SML and SMS are simple by design — not because simplicity is a virtue in itself,
but because a language that a human can learn in a day
is also a language that an AI can generate correctly in a second.

The sandbox is not a technical feature.
It is a commitment: the technology will not be used to harm.
Ahimsa. Do no harm. Written into the license, not the README.

When AI generates a Forge app and a user runs it,
they are running sandboxed code that cannot reach outside its permission boundary.
The AI cannot weaponize the app. The developer cannot weaponize the app.
The architecture enforces the ethics.

That is the kind of technology worth building.

A Different Question

Instead of "will AI take my job?" —

What would you build if the translation problem were solved?

What has been in your head for years that you never had time to make real?
What would you create if creation cost minutes instead of months?

That question is more interesting than the fear.
And the answer to it is what comes after the transition.

Forge is open source.

The tools exist. The time is coming.

Use both well.

Sat Nam. 🌱

Previous posts in this series:

→ We Benchmarked SMS Against C++, C#, and Kotlin. Here's What Happened.

→ From Request to Production in One Push. No Mockup Tool Required.