Own your data. Shape your environment. Grow the commons.
Communities grow, adapt, and discover forms of organisation no product team would ever design for them. A bioregional group, a DAO, a maker collective, a neighbourhood network — each finds its own way of deciding, valuing, remembering, and belonging.
Their software does none of that. It is fixed at the moment it ships, by people who will never meet them.
So the relationship inverts. Most communities today are perfectly capable of growing, creating and self-organising — but they cannot evolve the software conditions they live inside. And so the tools end up shaping the community far more than the community can shape the tools. How you decide, what gets counted, who gets heard, what's even expressible — all quietly bent to fit whatever a product team happened to build.
A community that can't shape its tools will eventually be shaped by them.
WE exists to invert that back — on a single conviction: communities should be able to evolve not just what they say, but the interfaces, incentives, and institutions through which they relate.
That inversion isn't abstract. It shows up as six walls, and they'll be familiar:
You're renting your own community. Every group chat or shared workspace lives on someone else's land. One day they change the rules, raise prices, or shut down — and your entire history and culture can vanish overnight.
Everything is scattered across too many apps. Your group juggles Slack, Docs, WhatsApp, a voting tool, a calendar. Every new need means another app. Context gets lost, people get exhausted, and half the group stops showing up.
You can't change the tools you depend on. Your community can choose its topic, its members, its moderation style, its tone. It cannot choose how important information surfaces, how governance works, how reputation is expressed, how money moves, or how shared knowledge is organised. A subreddit is still a subreddit. A Facebook group is still a Facebook group. A Discord server is still a Discord server. Your culture gets flattened to fit their product.
Diversity is crushed for compatibility. Different tools speak different languages. Data from one community can't flow into another without conversion overhead, fragile integrations, or one side abandoning the tool that actually fits them. To connect, someone has to conform.
Builders compete when they could compound. Every new app rebuilds the same foundations — auth, identity, feeds, notifications, settings — before it can ship anything new. Then it competes for users against innovations that don't even conflict with it. Good ideas stay isolated instead of building on each other.
AI can suggest changes but can't make them. AI can write code and describe features — but it's structurally locked outside the product. It can't reshape your interface or change how your community works. It's advice you can't act on.
Six walls. They look unrelated. They're the same wall.
All six trace back to one decision nobody remembers making — that software ships as a monolithic, vendor-owned application.
The app is simultaneously the unit of ownership, of capability, of control, of data, of distribution, and of opacity. That's why the walls travel together:
| Because the app is the unit… | You hit… |
|---|---|
| someone owns the land you're standing on | renting your own community |
| every new need means another app | sprawl, lost context, exhausted members |
| it's compiled code owned by a vendor | you can't reshape it — your culture bends to fit it |
| it carries its own private data model | to connect, someone has to conform |
| shipping an idea means shipping an app | builders compete instead of compound |
| it's an opaque binary | AI can only advise from outside |
This is why the software can't live and adapt the way the community does: a community is a process, and an app is an artifact.
You can't fix these one at a time. A theme picker doesn't give you your culture back. Another integration doesn't cure sprawl. A plugin API doesn't stop you renting.
Dissolve the app as the unit, and all six dissolve together.
That's what WE does. It replaces the application with composable, inspectable, shareable structure over sovereign data — infrastructure that gets out of the way, so the tools can evolve as fast as the community using them.
Which is what the three promises mean.
Your community owns everything. Data lives in decentralised infrastructure you control, not on a platform's servers — local-first, synced peer-to-peer, with no central authority who can change the rules or switch it off.
Crucially, your data lives separately from your interface. Change your interface and your data stays. Switch tools and your history comes with you. There is no migration tax for changing your mind, because there is no landlord to leave.
This is what AD4M provides: an agent-centric layer where data, identity and meaning belong to the agent, not the app.
AD4M already makes sovereign, peer-to-peer applications possible. If the data problem is solved, why not just build lots of separate apps on top of it?
Because every old problem returns at the experience layer. Separate apps mean fragmented interfaces, duplicated effort, weak composability, and no continuity — a new workspace, a new context, a new silo for every tool your community adopts. You'd have won data sovereignty and lost everything else.
Sovereign data is the floor, not the building. What communities need on top of it is a shared environment where experiences interoperate, compose, and evolve together. That's the other two promises.
If data sovereignty is the floor, this is the point. Owning your data doesn't help much if you're still living inside someone else's idea of what the experience should be.
In WE, every experience is a template — a high-level JSON schema that defines the interface without binding it to any front-end framework. The JSON describes the interface, not the runtime. That single property is what makes everything else possible:
- Inspectable and forkable. Anyone can read a template, adapt it, and share it back.
- Safe from untrusted sources. It's pure JSON — there is no code to execute. You can read it before you run it.
- Freedom within a contract. The schema defines exactly which data, actions, and queries a component can reach. Real creative freedom, bounded by a clear contract — which is what makes a marketplace of user-made interfaces viable at all.
- Live. Changes appear in real time. No recompile, no redeploy, no app-store review.
- Never trapped. There's a ladder out of every constraint: schema props → a CSS escape hatch → drop in a custom module.
Discussion, signals, shared knowledge and coordination live together — one place, one identity, no context-switching. When your community needs something new, it grows its environment rather than bolting on a twelfth app.
Fork a tool and make it fit. Decide what a signal means in your community — what gets counted, what gets surfaced, how a decision is reached. The vocabulary of your community stops being a product decision made by strangers.
Everything speaks a shared protocol, so communities running completely different experiences can still share data, connect and collaborate — without anyone having to standardise. Your community keeps its way of working. Others keep theirs. Connection stops requiring conformity.
This works retroactively, too: an application that already exists on AD4M — Flux, for instance — can be opened directly in WE, its native data queried, and an entirely new interface rendered over the top. No migration, no export, no permission needed.
Because experiences are structured schemas rather than opaque code, AI can read them, reason about them, and generate them. Describe what your community needs and AI can build and preview it in place — working inside the environment, not beside it. A full context library gives agents the whole vocabulary; a validation system tells them when they get it wrong.
This is the difference between AI that advises and AI that can actually act.
Shaping your own environment is worth little if every community has to discover everything alone. The third promise is what makes the other two compound.
From a single design token to a complete governance system, everything is shareable through the same module marketplace. Install a theme, a block type, or an entire economics layer with the same mechanism.
Take someone's template, remix it for your community, publish it back. Remix culture is the engine of a commons — and it only works here because templates are inspectable, safe, and need no build step. What one community figures out, every community can use.
The shared foundations already exist — identity, feeds, notifications, settings, navigation. Start there, build only what's genuinely new, and contribute it back. Others fork it, improve it, build on it. Compatible innovations stop competing for the same users and start compounding into each other.
Pair that with economic signals and contribution incentives, and the ecosystem grows itself: the more people contribute, the more valuable contributing becomes.
Real interface flexibility has never been offered by platforms, and it isn't an oversight. Interface control is where the business model lives. Handing it to users is the one thing an attention-monetising platform structurally cannot do.
But the pattern is proven everywhere it has been allowed:
- Gaming → mods
- Audio software → plugins
- Web publishing → WordPress themes
Every time, the same recipe: open conventions, a compatible marketplace, and suddenly thousands of independent contributors build what no single team could have shipped. That layer has simply been missing for social tools.
WE is not a framework where developers build modules and everyone else consumes them. It's a ladder — and the widest rungs need no code at all.
| Who | Contributes | Volume | Leverage |
|---|---|---|---|
| Users & communities | Their own space's layout; templates and themes made in-browser, often AI-assisted | Highest | Local |
| Designers | Themes, token sets, visual identities | High | Aesthetic |
| Template authors | Full application shells composed from existing modules — no code required | Medium | Structural |
| Developers | Elements, components, widgets, blocks, feature modules | Lowest | Raises the ceiling for everyone above |
Most of what flows through the ecosystem will be templates and themes, made by people who never open a code editor — exactly as WordPress's ecosystem is dominated by themes rather than plugins.
That doesn't make the developer layer less important; it makes it load-bearing. Modules define the vocabulary, and the vocabulary sets the ceiling on what everyone above can express.
The flywheel: developers expand the vocabulary → communities compose it into templates and themes → those get shared and forked → more people build what they need without waiting for a developer → richer demand pulls new modules into existence.
The module stack. Templates and themes are composed from modules, each layer building on the one below:
Design tokens → Elements (buttons, inputs, cards) → Components (message bubbles, avatars, editors) → Widgets (comment threads, reaction pickers, media galleries) → Pages → Templates.
Plus feature modules that install into any community: layer systems (like the Cesium globe for geographic and location-based community mapping), governance modules (voting, moderation, consensus), economics modules (payment flows, mutual credit, resource allocation), and integration modules (bridges, imports, connectors).
Blocks are composable content units — text, image, embed, code, task, event — that users arrange freely within pages. Themes are complete visual identities: token sets plus styling, shareable across any template.
The seed system. Every deployment starts from a seed file (we-seed.json): which modules to include, how to arrange and theme them, platform settings. Want a community platform? Pick community modules. A project manager? Pick project modules. Same infrastructure, different seed.
The stack. WE is the interface layer of three:
- WE — composable design system and module marketplace (what people see, touch and shape)
- AD4M — ontological layer for data, meaning and agent coordination (how data flows and connects)
- Holochain — trust, validation, and eventually economics (how agreements are enforced)
It runs everywhere through platform adapters — Web (zero install), Electron (Linux, macOS, Windows), Tauri (lightweight Rust desktop). One codebase, one seed file, all platforms.
Don't think "build an app." Think "contribute to the commons." What that means depends on where you're standing:
If you're a community member or organiser — reshape your own space. Build a template that fits how your group actually works, and share it. This is the highest-volume and most under-served contribution in the entire ecosystem, and it needs no code.
If you're a designer — build themes. A token set and a visual identity any community can adopt in one click.
If you're a template author — compose existing modules into complete application shells. A community platform, a project manager, a marketplace — no code required.
If you're a developer — build modules. Every one raises the ceiling for everyone above you:
- A better date picker element → every app that uses dates improves
- A kanban board widget → any template can drag it in
- A new governance module → every community can install it
Start small, compose upward.
- Explore the design system — the token → element → component → widget → page → template hierarchy
- Check the schema-system for how schemas drive UI generation
- Look at Flux as the reference application built on WE
- Read the Seed System to see how modules compose into deployable apps
- See Codebase Map for how the codebase is structured
WE exists because the tools we use to connect should be as distributed and composable as the communities that use them.