Social infrastructure
for a more cooperative world.
Own your data. Shape your environment. Grow the commons.
Communities are living systems — they grow, adapt, and discover forms of organisation no product team would design for them. WE is open, composable infrastructure that gets out of the way — build what your community needs, and share what works with the commons.
The walls every community keeps hitting.
Click a card to see the solution.
You're stuck 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.
Own your data. Protect your culture.
In WE, your community owns everything. Data lives in decentralised infrastructure powered by ADAM. Change your interface and your data stays. Switch tools and your history comes with you.
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.
Everything you need in one place.
WE is one environment where discussion, signals, shared knowledge, and coordination all live together — one place, one identity, no context-switching. When your community needs something new, it grows its environment instead of fragmenting it.
You can't change the tools you depend on.
You can pick a theme or add a bot, but the real decisions — how the interface is organised, how votes work, what signals mean — are locked by developers. Your culture gets flattened to fit their product.
Fork it, reshape it, make it yours.
In WE, every experience is built from structured templates anyone can inspect, adapt, and share. Define what signals mean for your community. Fork a tool, make it fit, publish it back for others.
Diversity crushed for compatibility.
Different tools speak different languages. Data created in one community can't flow into another without conversion overhead, fragile integrations, or one side giving up the tool that actually fits them.
Unity without uniformity.
WE is built on a shared protocol any compatible tool can speak. Different communities using different experiences can still share data, connect, and collaborate — without anyone having to standardize.
Builders compete when they could compound.
Every new app has to rebuild the same foundations before it can ship. Then it competes for users against other innovations that don't actually conflict. Good ideas stay isolated instead of building on each other.
Build what's new. Reuse what's already here.
The shared foundations already exist. Start there, build what's new, and contribute it to a growing module marketplace. Others fork it, improve it, build on it. Compatible innovations don't compete — they compound.
AI can suggest changes but can't make them.
Today's AI can write code and describe features — but it's structurally locked outside the product. It can't reshape your interface or modify how your community works. It's advice you can't act on.
AI that works inside your environment.
WE experiences are structured schemas AI can read, reason about, and generate. Describe what your community needs and AI can build and preview a template in place — working inside the environment, not beside it.
What this means for you.
WE means something different depending on where you're coming from.
For communities
Tools that adapt to your community, not the other way around.
Your community's tools should grow with you — not trap your data, resist change, or disappear when a platform pivots. WE gives you an environment you shape over time, with full continuity of history and identity.
Learn more
For builders
Build what's new. Reuse what's already here.
Identity, data infrastructure, a content system, a design system, a growing component library — already in the ecosystem. You start from those and build only what is genuinely new. Contribute it as a module and the whole ecosystem benefits, without competing for the same users.
Learn more
How it works
A shared vocabulary for community software.
WE uses structured building blocks — composable, inspectable, and AI-readable. Experiences are schemas, not sealed code. That makes them forkable, malleable, and safe to share across the ecosystem.
Learn more
See it in practice
What communities actually do with WE.
A research collective that owns their annotation layer. A neighbourhood mutual aid network with no platform dependency. A creative collective that defines what resonance means for them.
Learn more
What we've built and what's next.
WE is in active development. Here's an honest picture of where we're at.
Already built
AD4M integration
Sovereign identity, self-owned data, and peer-to-peer coordination — no central server required.
Design system
A full suite of compatible tokens, themes, primitives, components, and widgets that can be used to build experiences.
Schema system
Adaptable JSON blueprints that define how experiences look and behave — rendered live without recompiling, safe to share, easy for AI to inspect and reason about, framework agnostic.
Block system
Composable building blocks for content generation — text, images, audio, video, events, tasks, and more — that can be combined freely, from a single message to a full document.
AI template generation
AI that reads the semantic shape of your community's data and generates working interfaces from plain language — start fresh or fork an existing template, no code required.
Default explorer
A working starter template — spatial exploration of agents and communities, rich post creation, and signal management. Use it out of the box or fork it as your foundation.
Customisable signals
Allows communities to custom build signal types (likes, upvotes, flags, ratings etc.) that fit their culture and context, while maintaining compatibility across the ecosystem.
Cross-platform deployment
The same experience runs on web, desktop, and mobile from a single configuration. Communities access WE however they prefer; builders publish once.
Sub-app integration
Existing AD4M applications (including Flux) can run inside WE.
On the roadmap
Module Marketplace
Discovery and publishing infrastructure for templates, themes, components, and block types.
Starter template library
A curated set of ready-made templates covering common community patterns — discussion, knowledge base, coordination, and more — so builders have a meaningful starting point beyond the default.
Experience builder
A guided wizard for creating new experiences: pick a starter template, choose a theme, and snap in the widgets your community needs — no code, no blank canvas.
Visual interface editor
Direct manipulation of templates — drag, resize, restyle — as an alternative to AI-prompted editing for communities and builders who prefer hands-on control.
Governance and economics modules
Building blocks for community governance, moderation, and resource flows — a foundation communities can build on and adapt to their own experiments.
The full picture.
Dive deeper into what WE makes possible and how it works.
For communities
Tools that adapt to your community, not the other way around.
Most digital communities today are socially alive but structurally constrained. You can shape your culture, your tone, your norms. But the deeper layer — the software conditions you actually live inside — is almost always fixed by someone else.
- The interface is rigid.
- The feed algorithms are predefined.
- Governance and moderation aren't yours to configure.
- What counts as a signal is decided for you.
Even when a platform offers plugins or admin controls, you're still customising within a house you don't own. The foundations belong to someone else. And when their incentives shift — and they always do — you pay the price.
Own your data. Protect your culture.
Everything your community creates lives in decentralised infrastructure you control, powered by the AD4M protocol. No central server to shut down. No platform to hold your history hostage. Uninstall a template and your data stays. Switch tools and your entire history comes with you.
One persistent, portable identity moves with you across every experience inside WE — and across communities. Your reputation, your connections, your context: yours.
Tools that grow with you
WE experiences are built from structured templates — not locked code. Start from a template that fits your community today, adapt it as your needs change. Adjust how information surfaces. Define what kinds of signals matter in your context. Fork an experience that's mostly right and change the parts that aren't.
You don't need to migrate to a new platform to do this. You don't lose your history when you change.
Everything you need in one place
Discussion, shared knowledge, resource coordination, community signals — these don't have to live in separate apps. In WE, they coexist in one environment under one identity. Context doesn't get lost between tools because there's no gap to lose it in.
Design signals that mean something to your community
WE's signalling system lets communities define their own signal types — what counts as important, relevant, urgent, or well-crafted — rather than accepting the platform's one-size-fits-all defaults. Your community's values shape how attention flows.
Learn from others, contribute back
When another community builds something better, that pattern can be published and adopted. WE's growing marketplace is designed to let useful coordination patterns spread — not stay locked inside the group that discovered them.
What this looks like in practice
A local collective starts with a simple discussion and resource-sharing template. As the community grows, members want clearer ways to surface urgent needs and signal collective support. They use WE's signalling system to define exactly what those signals mean for their context — not repurposing a generic “like” button but creating something that carries real meaning for their culture.
A learning community builds not just a forum but an evolving knowledge environment — structured notes, linked concepts, multiple views over the same shared knowledge base. Newcomers see guided pathways. Experts see denser, more interconnected maps. Both are lenses over the same underlying data.
A neighbourhood group brings together discussion, local coordination, resource offers and needs, and a shared calendar — all in one environment, all connected by the same identity and memory.
WE starts from a simple conviction:
Communities should be able to evolve not just what they say, but the interfaces, incentives, and institutions through which they relate.
That means more agency over digital tools, more continuity of history and identity, and more room for communities to discover forms of organisation that actually fit who they are.
For builders
Build what's new. Reuse what's already here.
Building a new social tool usually means building everything: identity, profiles, threads, feeds, moderation, content composition, data storage. None of that is the interesting part — it is just the price of entry before you can start on the thing that is actually new.
WE changes the starting point. Identity, data infrastructure, state management, content creation, and a growing library of components and templates already exist in the ecosystem. Start from those and build only what is genuinely yours.
Collaborate instead of compete
In a traditional app, your success depends on winning the adoption game — capturing users before someone else does. In WE, that pressure dissolves. Your contribution does not need to be a complete app to matter.
A new widget, a block type, a template, a signalling pattern — each is a real addition to what every community in the ecosystem can use. A community can run your coordination module alongside someone else's knowledge base. Two experiences covering the same ground are not fighting for lock-in; they are both views over the same data, and users can run both.
The question shifts from “can I capture enough users to sustain this?” to “does this new piece solve something real?” Good contributions spread through the ecosystem, get forked and improved, and come back better.
What you can build
The ecosystem accepts contributions at different scales:
Templates
In WE, templates are the high-level blueprints that define a UI as a JSON schema — which components to include, how they are laid out, how they are styled, what interactions are possible. Templates can be forked, remixed, and AI-generated. A community adopts your template, customises it to fit their context, and publishes their fork.
Components and widgets
Reusable UI building blocks contributed to the shared ecosystem. Build once — available to every community and experience that wants them.
Themes
A theme is a complete visual identity — tokens, colours, typography, and spacing — that any community can apply to their environment. Publish a theme once and any experience built on the design system inherits it.
Block types
WE's block system is the shared vocabulary for rich content creation. New block types can be contributed to extend what every community can compose and express — not just in your experience, but across the whole ecosystem.
Signalling systems
Build reusable signalling patterns other communities can adopt and adapt. Each community then defines what those signals mean in their specific context.
Two-sided network effects
As more builders contribute templates and components, the environment becomes richer for communities. As more communities use WE, there are more real-world contexts in which your work gets tested, improved, and forked. Each side strengthens the other.
It's a different economic model entirely: contributions compound across the ecosystem instead of competing for the same zero-sum pool of users.
How it works
A shared vocabulary for community software.
Most social software bundles data and interface together inseparably. Your posts live inside the app. The app's logic decides how to display them. Switch apps and you start over.
WE takes a different approach: data and interface are explicitly separated. Your data lives in your own AD4M perspective. Experiences in WE are lenses over that data — different ways of viewing, interacting with, and organising the same underlying information.
Install a new experience and it reads your existing data. Uninstall one and nothing is lost. The interface is not the data. It is just one way of seeing it.
The AD4M foundation
Everything in WE sits on AD4M — the Agent-Centric Distributed Application Meta-protocol. This protocol layer unlocks the core capabilities that make community sovereignty possible:
Sovereign identity
Every agent has a persistent, self-owned identity that works across communities and experiences. Your profile, relationships, and reputation are not locked inside any single app.
Agent-centric data
Your data lives in your own AD4M perspective, portable across any experience or community. Switch tools without losing history or having to migrate data.
Peer-to-peer coordination
Communities run on distributed peer-to-peer networks with no central authority. No single point of control or failure.
Semantic interoperability
A shared predicate vocabulary means content created by entirely different tools can be understood and rendered by WE without prior coordination between builders.
Templates: experiences as schemas
Every experience in WE is defined as a JSON schema — a structured, human-readable description of which components to include, how they are laid out, how they are styled, and what interactions are possible. This is a deliberate architectural choice with several significant consequences:
Fork and edit live
Copy a template, edit it live, see changes immediately. No compilation, no build step — just direct manipulation of the schema. Publish your fork and it's ready to use.
AI-native by design
Structured schemas are something language models can read, reason about, and generate reliably. WE isn't bolting AI onto a legacy system — it's designed from the ground up so AI can actively work inside the environment.
Inspectable and auditable
Anyone can read a template and understand what it does before installing it. No hidden behaviours. That's a trust primitive most platforms don't have.
Safe to share
Declarative schemas can be shared, versioned, and forked without the risks of executing arbitrary code. The composability model is safe by design.
Framework agnostic
The schema system does not tie you or the ecosystem to any single frontend framework. Solid is the current default renderer, but the architecture is open.
The signalling system
Communities don't all surface information the same way. WE's signalling system lets communities define their own signal types — what counts as relevant, urgent, well-crafted, or worth amplifying in their specific context.
A research community might signal for epistemic confidence and novelty. A mutual aid network might signal for urgency and capacity to help. A creative collective might signal for craft and resonance. Each community defines what attention means for them.
Block system: what communities can create
WE's block system is the shared vocabulary for rich content creation. Any combination of block types can be composed into a single message, post, or document.
TextParagraphs, headings, lists, quotes, code
ImagePhotos, diagrams, artwork
AudioMusic, podcasts, voice memos
VideoClips, streams, tutorials
FileDocuments, binary files
EventEvents, schedules
TaskTasks, to-dos
LocationLocations, routes
TagLabels, categories
PollPolls, votes, surveys
CollectionPlaylists, albums, folders, galleries
TableData tables, spreadsheets
CodeSource code, config
LinkBookmarks, previews
EmbedExternal content
See it in practice
What communities actually do with WE.
The best way to understand WE is not the architecture, but the habit it creates: when a community needs something, they describe it, and the system helps build it.
A research collective
A group of independent researchers is tired of losing context across email threads, shared docs, and citation managers.
- They fork a literature-review template and add a confidence-rating signal type specific to their methodology.
- Papers are annotated as blocks. Signals surface what the group collectively considers well-evidenced versus speculative.
- When a member leaves, they take their data. When a new member joins, they see the full annotated history.
- An AI assistant reads the schema and helps the group run structured debates over contested claims.
A neighbourhood mutual aid network
A local network needs to coordinate offers and requests across a community of several hundred people. They don't want to depend on a third-party app that might disappear.
- They use an offer/request experience with custom urgency and capacity signals.
- Members can see who has what, who needs what, and what is being actively coordinated — without ever exposing that data outside the group.
- A fork of the experience adds a skills directory and an event board. Both share the same identity layer: one member profile, no separate logins.
A creative collective
A distributed group of musicians, visual artists, and writers want a shared creative environment that feels genuinely theirs.
- They build a custom portfolio experience using image, audio, and text blocks.
- They add a signal type for collaborative resonance — a way of saying “this connects with what I'm making” rather than just a generic like.
- When a member develops a residency context with a different community, they can install that template without disrupting their home environment.
A decentralised governance group
A group making collective decisions across time zones and disciplines needs structured deliberation without the chaos of unthreaded chat.
- They run a proposal template with defined phases: draft, discussion, amendment, and decision.
- Signals distinguish between support, concern, amendment suggestion, and blocking objection.
- Every decision has a legible history: what was proposed, what changed, why, and how the outcome was reached.
Across all of these: the community owns their environment, not the platform.
This is what cooperative infrastructure looks like in practice: not tools designed to capture communities, but tools communities genuinely control.
What this adds up to.
Most communities today are capable of growing, creating, and self-organising — but unable to evolve the software conditions they live inside. The tools shape the community far more than the community can shape the tools.
WE is an attempt to change that. Not by building a better platform, but by giving communities a shared environment where the tools themselves can be owned, adapted, and passed on.
The deeper bet: given the right infrastructure, communities will discover forms of coordination and collective intelligence that no platform team would have designed for them. And those discoveries will spread.