OpenLikwid: building governance infrastructure (without building a social network)

· 6 min read
#likwid #openlikwid #rust #axum #postgres #wasm #governance

I’ve been working on Likwid (the project behind OpenLikwid, the live demo at https://openlikwid.org) for a simple reason:

we’re citizens of the 21st century, but we still govern online with tools that weren’t designed for governance.

Issue trackers, chat rooms, mailing lists, polls… they’re great at communication, but they’re not great at decisions. And when decisions are made in a messy interface, you eventually get messy outcomes.

🔗What Likwid is (and what it refuses to be)

Likwid is a modular governance engine.

Not a social network. Not “a poll tool, but with vibes.” Not an app that assumes every community is the same.

It’s meant for organizations that actually need:

  • Structured deliberation (not endless threads)
  • Voting methods that can express nuance (not just 51% vs 49%)
  • Delegation that’s flexible and revocable (trust networks, but with brakes)
  • Moderation that is accountable (power exercised in daylight)

The core design idea is composability:

  • The platform provides the “boring but essential” layer: identities, communities, proposals, persistence.
  • Everything opinionated becomes a module: workflows, voting methods, deliberation rules, integrations.

🔗The two big modes: production vs demo

OpenLikwid runs as a demo instance.

In the codebase, “demo” isn’t a marketing sticker. It’s a real operational mode with different expectations:

  • Separate database (so demo data stays demo data)
  • Seeded communities, users, and proposal history
  • Restricted destructive actions
  • A reset mechanism to keep the instance in a known, meaningful state

I like this approach because a governance platform is hard to “get” when it’s empty. The demo exists so people can explore governance with context: delegations, moderation history, proposals in different phases.

🔗Architecture snapshot

Browser -> Astro (Node) pages + light client JS -> fetch to /api/* (reverse-proxied) -> Axum router -> SQLx/Postgres; meanwhile a plugin manager listens to domain hooks like proposal.created, comment.pre_create, vote.cast, and cron.*, and can run built-in modules or sandboxed WASM packages (wasmtime with compute/time/memory limits) that emit events back into the system; demo mode is the same pipeline, just pointed at a separate seeded database with a reset switch.

🔗The backend: Rust, Axum, SQLx — and a plugin-shaped brain

The backend is written in Rust with Axum (async, clean routing) and SQLx (PostgreSQL).

A few things I cared about from the beginning:

  • A clear API surface (so the frontend is not a mind-reader)
  • Strict-ish boundaries (auth, permissions, domain logic)
  • A system that can evolve without rewriting the world

That last point is where the plugin system comes in.

🔗Hooks everywhere (but in a “systems” way)

Likwid has a plugin manager that can run:

  • Built-in plugins (compiled into the backend)
  • Third-party plugins packaged as WASM

Plugins register hooks — events like:

  • proposal.created
  • comment.pre_create
  • cron.minute
  • vote.cast

So instead of hardcoding “the one true governance workflow,” the platform exposes predictable events, and modules react.

It’s the same mental model as a well-designed backend:

  • Keep the core small.
  • Add behavior with clearly-defined extension points.

🔗WASM plugins, but sandboxed like I mean it

WASM plugins run using wasmtime, with explicit execution limits:

  • Fuel metering (bounded computation)
  • Timeout via epoch interruption
  • Memory limits

And capabilities are not magic. The host side maintains a capability list and can deny things like outbound HTTP unless allowed and allowlisted.

In other words: yes, it’s extensible — but the goal is “safe extensibility,” not “run arbitrary code and hope for the best.”

🔗Governance features that feel like product decisions (because they are)

Here are a few pieces I’m particularly proud of.

🔗Structured deliberation: “read before comment” is not a meme

There’s a deliberation module that can enforce reading requirements before participating.

Not to be paternalistic — but to fix a real failure mode:

  • People respond to headlines
  • The thread becomes noise
  • The outcome becomes vibes

In Likwid, a proposal can have an inform phase (resources, context) and the system can require that you actually engage with it before your comment or vote counts.

🔗Decision workflows: proposals move through phases, not feelings

There’s a decision workflow plugin that models governance as phases.

That sounds obvious, but it matters: a proposal isn’t just a post with a comment section.

It can be:

  • Discussion
  • Review
  • Voting
  • Implementation tracking
  • Cooldown

…and the platform can auto-advance phases on a schedule (there’s a cron hook for periodic checks).

🔗Voting methods as plugins (and per-community defaults)

Likwid supports multiple voting methods (Approval, Ranked Choice, Schulze, STAR, Quadratic), and treats them as configurable plugins.

The point isn’t “look how many methods I can list.”

The point is: different communities need different trade-offs. A method that works for “pick one logo” is not the same as “prioritize roadmap items.”

🔗Moderation ledger: power should leave a receipt

This one is deliberately opinionated.

Moderation actions are recorded in an immutable, cryptographically chained ledger.

  • Each entry has a hash
  • Each entry references the previous hash
  • There’s a genesis hash
  • The chain can be verified
  • Updates are blocked, deletes are blocked (with an explicit escape hatch for legal compliance)

It’s the difference between:

  • “Trust the moderators”
  • “Trust the process — and verify it if you need to”

This is the kind of design choice that makes Likwid feel less like a platform and more like infrastructure.

🔗The frontend: Astro as a pragmatic UI layer

The frontend is built with Astro + TypeScript, in server mode.

Astro is a good match here because I don’t want the UI to become an infinite framework maze. I want:

  • Pages that are easy to reason about
  • A clean separation from the backend API
  • A UI layer that can be iterated quickly

The demo experience is also intentionally guided — because governance isn’t self-explanatory. The demo page points people to communities, explains the idea of “meaningful seeded data,” and gives accounts for different roles.

🔗Hosting: OpenLikwid on my VPS

OpenLikwid is deployed on my own VPS.

I like this setup because it keeps the operational story honest:

  • There’s a backend service (API)
  • There’s a frontend service
  • There’s a database
  • There’s a reverse proxy and TLS at the edge

Nothing magical, nothing proprietary. Just the kind of stack I’d want if the goal is to run a serious system without outsourcing understanding.

🔗Why I’m building this (the personal reason)

I build a lot of things. Some are audio tools, some are web systems.

Likwid is the one that feels the most like “infrastructure with consequences.” It’s not about shipping another app — it’s about designing an interface where power, participation, and accountability are treated as first-class concepts.

Also, selfishly: it’s a perfect playground for the kind of engineering I like.

  • Clear data models
  • Careful boundaries
  • Deterministic behavior
  • Extensibility without chaos

🔗What’s next

There’s a lot more to do.

But the direction is stable:

  • Make governance composable
  • Make deliberation readable
  • Make voting expressive
  • Make moderation accountable
  • Keep the system deployable by real humans

If you’re curious, the code is public:

And the demo lives here: