DEV Community: Art

A free textbook about Forge4D in the making: native apps from two small text files

Art — Wed, 21 Oct 2026 14:26:51 +0000

This is a whole app:

Window {
    id: mainWindow
    title: "My First Forge App"
    size: 480, 320

    VBoxContainer {
        anchors: left | top | right | bottom
        padding: 32, 32, 32, 32
        spacing: 16

        Label { id: greeting text: "Hello, Forge!" fontSize: 24 }
        Button { id: btnHello text: "Say hello" }
    }
}

var clicks = 0

on btnHello.clicked() {
    clicks = clicks + 1
    greeting.text = "Hello for the ${clicks}. time!"
}

The first file says what is there. The second says what should happen. There is no main function, no event loop and no listener registration, and you don't have to install anything by hand. ./run.sh url file://…/app.sml opens a native window on macOS or Linux, and before it appears the script has already been compiled to machine code.

I'm writing a textbook about this, and while I write it, you can read it for free.

What it is

Forge4D is an open source app platform built on the Godot engine. You describe the user interface in SML, a small markup language of nodes and properties. You describe the behaviour in SMS, a small Kotlin-flavoured scripting language that is compiled ahead of time through LLVM. Together they form what we call ForgeIL – the Intention Language: you write down intentions, and the runner takes care of the how.

The book is called Forge4D – Building Apps with ForgeIL, the Intention Language. It is hands-on. Every chapter has a goal, a complete example, a line-by-line walk-through, a list of pitfalls, an exercise, and a solution in the appendix.

What is out today

Part I – Intention: why an intention language, and your first running app
Part II – Structure (SML), first three chapters:
- Nodes, Properties and Values: the whole syntax, built around a small business card app
- Layout: containers instead of coordinates, size flags, split views, grids, tabs, and anchors for the rare element that should float
- Resources and Themes: one strings.sml per language, colour tokens by role, named styles, and switching between a dark and a light theme at runtime

Coming next: Markdown inside SML, the element catalogue, and Part III on SMS: values, control flow, functions, events, files, and non-blocking calls.

Every example runs, and that's not a slogan

Each example in the book is started in the real Forge Runner, clicked through and screenshotted before it goes into a chapter. That habit has paid off quickly.

While I was writing the SMS chapters, the tests turned up a list of things the native compiler did not handle correctly yet: strings passed through functions, floating-point math, some loops. So we stopped writing and fixed the compiler first. The new compiler infers types and is checked by a conformance suite that runs every test both in the interpreter and as native code. The book waited for it.

The SML chapters found smaller things. One example: padding takes its four values as left, top, right, bottom, not in the CSS order you probably expect. The book now says so, and every pitfall in it comes from a real run like that one.

Read it

📖 Forge4D on CrowdBooks: free while it is being written

Source code of the platform: codeberg.org/CrowdWare/Forge4D
All book examples: codeberg.org/CrowdWare/books

You need a Mac with Apple Silicon or a Linux PC, git, and a text editor. git clone, ./run.sh, and the runner downloads itself on first use.

If you try it and something in a chapter doesn't work the way it says, I want to know. It's an early edition, and your feedback goes straight into the next chapter.

– Adam Art Ananda

A community marketplace without a database or payment provider: the Ğ1 (June)-Markt

Art — Sat, 03 Oct 2026 09:33:02 +0000

Today the June-Markt went live on crowdware.info/markt. It's a marketplace for the community around June (Ğ1), a free currency. Members offer honey, massages, websites or guitar lessons, post requests such as "band looking for a guitarist", and pay each other directly from wallet to wallet.

It runs on ForgeCMS, my small CMS written in Go, as a new module. There's no database, no payment provider, and the platform never holds a single coin of anybody's money. The operator can still charge a fee on sales.

This morning I bought a 1 Ğ1 test item from my own listing. About 90 seconds after the transfer, the order was marked as paid, both emails had gone out, and 0.03 Ğ1 of market fee was booked on the vendor's fee account.

👉 For operators: https://crowdware.info/market-module

Why a market for June?

Ğ1 has been running since 2017. Every member creates the same 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 runs on Duniter v2, a Substrate-based blockchain.

A currency is only as useful as the things you can buy with it. Ğchange, a classifieds site for June, already exists. I wanted something that fits into local websites, for example one market per association. I also wanted the site to see payments by itself, so it can do more than show ads.

What it does

For visitors:

a list of listings with photo, price, place and hashtags, sorted into goods, services and requests ("wanted")
search by text, postcode or place and kind, plus hashtags like #honig, #massage, #bandsuchtgitarist, with a tag cloud and a few quick filters chosen by the operator
a contact form on every listing that mails the vendor and keeps the vendor's address hidden
a "report" button on every listing, because the EU Digital Services Act requires a notice-and-action mechanism
direct purchase on listings that allow it

For vendors: login by email link (no password), a profile with an optional Ğ1 wallet, up to four photos per listing, Markdown descriptions, and pause, renew and delete with one click. Listings go offline after 90 days, with a reminder a week before.

For the operator: moderation (the first listing of every new vendor waits for approval), reports, blocking, and a fee on direct sales.

Like everything in ForgeCMS, it's server-rendered HTML with Bootstrap classes and no JavaScript.

Hashtags instead of categories

My first plan had fixed categories in the config. Then I realised a community market is too varied for that. Someone selling honey, someone offering a massage and someone looking for a band don't fit into one category tree. So every listing gets one to five free hashtags:

#Software, massage #Mann_sucht_Frau

They are normalised to lower case, without #, and limited to 2–30 Unicode letters, digits or _. The list filters by any combination of them.

The ✓ badge: trust from the Web of Trust

Ğ1 members are certified by other members, so the currency has a Web of Trust built in. The public indexer tells you whether a wallet belongs to a certified member:

accounts(filter: {id: {equalTo: $wallet}}) {
  nodes { identity { name isMember } }
}

Vendors whose wallet belongs to a member get a "✓ Ğ1 member: name" badge. It doesn't guarantee the offer, but on a community market it is a strong signal against fake accounts. A new wallet only shows up after the vendor confirms it by email, so a stolen session cookie can't silently redirect payments.

Direct purchase: the money never touches the server

This was the hard design question. I wanted the operator to earn a fee, say 3 %. The obvious way is that the platform collects the money and forwards 97 % to the vendor. That has two problems:

The server would need a private key, so a hacked server would mean stolen money.
In Germany, collecting and forwarding other people's money is regulated as a payment service. That's not something a small community site wants to deal with.

So the buyer pays the vendor's wallet directly, and the fee is billed afterwards:

The buyer orders on the listing page and gets an order number, e.g. MK-EZMDY3GY.
They pay the vendor's wallet with that number in the transfer comment.
A watcher goroutine sees the payment, marks the order paid, books amount × 3 % on the vendor's fee account, and mails both sides.
On the 1st of every month each vendor gets a statement FEE-… and pays it to the market wallet, again with the number in the comment. Totals under 1 Ğ1 are carried over.
If a statement is still unpaid 30 days later, the vendor's listings are hidden until it is paid.

Vendors opt in per listing. The "allow direct purchase" checkbox also accepts the fee, so existing listings stay contact-only and fee-free.

Watching many wallets with one query

The shop module watches one wallet. The market has to watch every vendor wallet with an open order, plus the market wallet while a statement is open. The Duniter indexer is PostGraphile, so one in filter covers all of them:

transfers(orderBy: BLOCK_NUMBER_ASC,
          filter: {toId: {in: $wallets},
                   blockNumber: {greaterThan: $from, lessThanOrEqualTo: $to}}) {
  nodes { id blockNumber amount fromId toId comment { remark } }
}

Once a minute the watcher reads the blocks since the last run, minus 10 confirmations. An order ID only counts on a transfer to that order's wallet. A statement ID only counts on the market wallet. Partial payments add up, a transfer is never booked twice, and the last processed block lives in a small state file. Vendor wallets get plenty of unrelated transfers, and those are simply ignored.

No database, still

Everything is SML, my own small config format, written atomically next to the binary:

Listing {
    id: "k3f9qxab"
    kind: "goods"
    title: "Blütenhonig 500 g"
    tags: "honig lebensmittel"
    price: 800          // centimes: 8.00 Ğ1
    unit: "Glas"
    status: "active"
    buy: true
    Image { file: "k3f9qxab-abcdefgh.jpg" }
}

On start the store loads everything into memory, and every change is a temp file plus rename under one mutex. For a community market with hundreds of listings that's plenty, and backups are just rsync.

I did hit one classic bug. The list functions called a filter callback while holding the store mutex. When the filter started asking "is this vendor's fee overdue?", which needs the same mutex, the test froze. Now the store copies under the lock and filters outside it.

User content is untrusted content

A few things that matter more on a marketplace than on a normal site:

Photos are decoded one at a time (to protect a small VPS from memory spikes), turned upright using the EXIF orientation, scaled to 1600 px and re-encoded. That drops all metadata, including the GPS position of your kitchen.
Markdown in listings goes through its own goldmark renderer, not the site's. It drops raw HTML, empties javascript: links, adds rel="nofollow ugc noopener", turns images into plain links so nothing third-party gets loaded, and starts headings at <h3>.
The contact form doesn't send a copy to the sender. Otherwise anyone could use it to mail arbitrary text to arbitrary addresses.
Removing a listing or blocking a vendor mails the vendor the reason, as Art. 17 DSA requires. A reply to that mail goes to the moderator.

Try it

The market: https://crowdware.info/markt
For operators: https://crowdware.info/market-module
What is June? https://crowdware.info/june
ForgeCMS source (GPLv3): https://codeberg.org/CrowdWare/ForgeCMS

The market module is a one-time license for €49 or 49 June (Ğ1). If your association, village or community wants its own market, get in touch.

If you already trade in June, post something on the June-Markt. I'd love to see what turns up under #.

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.