docs: define ClawHub product vision (#3125)

2026-08-14 00:47:57 +00:00 · 2026-07-16 17:45:28 -07:00
parent 43e44a8eb6
commit 106c98fb54
1 changed files with 131 additions and 87 deletions
@@ -1,98 +1,142 @@
-## OpenClaw Vision
+# ClawHub Vision
-OpenClaw is the AI that actually does things.
+ClawHub is the app store for OpenClaw agents.
-It runs on your devices, in your channels, with your rules.
+
 Under that experience, ClawHub is the public registry and trust layer for
 OpenClaw extensions. People should be able to confidently discover what to
 install, while publishers release durable, versioned work under identities they
 control.
 ClawHub should help someone start with a useful agent, understand what it
 contains, and make it their own. Clear provenance, adoption, and security
 evidence should help users judge what to install.
 ClawHub began as a public registry for skills and plugins. That registry remains
 important infrastructure, but it is not the final product. The direction is to
 move up one level: from helping people assemble individual components to helping
 them discover and install complete starting points for personal agents.
 This document explains the current state and direction of the project.
 We are still early, so iteration is fast.
 Project overview and developer docs: [`README.md`](README.md)
-OpenClaw started as my personal playground to learn AI and build something genuinely useful:
+## Claws
 an assistant that can run real tasks on my computer.
 It evolved through several names and shells: Warelay -> Clawdbot -> Moltbot -> OpenClaw.
-The goal? A personal assistant that's easy to use, supports a wide range of platforms, and respects your privacy and security.
+A Claw is an installable personal-agent template. It combines skills, plugins,
 and agent configuration into a useful starting point that OpenClaw can install
 and run.
 Claws should make the first experience simple without making the result opaque.
 A user should be able to:
 - discover a Claw for a real use case
 - inspect its publisher, components, permissions, and security evidence
 - install it with one clear action
 - customize it as their needs and confidence grow
 The goal is not to hide OpenClaw forever. It is to let people begin with
 something useful before they need to understand every skill, plugin, agent file,
 or configuration convention.
 Claws are ClawHub's primary product object. Skills and plugins remain important
 building blocks, and ClawHub should continue helping users and publishers find,
 release, inspect, and maintain them.
 ## Discovery And Ecosystem Signals
 ClawHub should surface the best available OpenClaw building blocks whether they
 originated on ClawHub or elsewhere in the ecosystem.
 Aggregated content must keep its identity and provenance. Users should be able
 to tell who published something, where its source and artifacts live, which
 version they are inspecting, and which signals came from ClawHub or another
 source.
 Recommendations should combine two distinct kinds of evidence:
 - ecosystem signals, such as broad adoption and popularity
 - OpenClaw-specific signals, such as installs and usefulness within OpenClaw
 These signals should complement each other without being conflated. Popularity
 is not the same as trust, and OpenClaw-specific usage should not be presented as
 ecosystem-wide adoption.
 ## Identity And Authorization
 ClawHub is the ecosystem identity and authorization layer for OpenClaw
 distribution.
 It represents people and organizations as publishers, owns their public
 namespaces, and determines who may publish, manage, or distribute content under
 those identities. Accounts authenticate individual actors; publishers are the
 public ownership boundary for Claws, skills, and plugins.
 ClawHub should provide the permissions and tokens needed for registry,
 publishing, management, and distribution workflows across OpenClaw ecosystem
 services.
 This boundary does not include model-provider credentials, channel credentials,
 or local runtime secrets. Those belong to OpenClaw and the operator's
 environment.
 ## Trust And Security
 ClawHub is open to publishing, but openness does not mean abandoning security
 judgment.
 ClawHub should continue running its own security scans and applying its own
 upload gates, moderation controls, and abuse protections. It may incorporate
 external findings and trust signals, but they complement rather than replace
 ClawHub's responsibility for the experience it presents.
 Users should see provenance, scan results, moderation state, and verification
 signals in context. An Official publisher signal verifies a specific publisher
 identity; it is not inherited by related accounts and is not a blanket
 endorsement of everything that publisher releases.
 No scanner, badge, or review can guarantee that an extension is safe. ClawHub
 should make risk easier to inspect and act on without implying certainty that
 the evidence cannot support.
 ## Product Boundary
 ClawHub owns:
 - Claws and their distribution records
 - ecosystem identity, publishers, permissions, and publishing authorization
 - discovery, provenance, version metadata, and install resolution
 - OpenClaw-specific telemetry and recommendation signals
 - security scanning, moderation evidence, and trust presentation
 OpenClaw owns runtime and installation execution. Source code and artifacts may
 live in external repositories or package systems, provided ClawHub can preserve
 their identity, version, provenance, and integrity.
 ClawHub should be an open experience layer, not a walled garden. Its public
 interfaces should make it possible for OpenClaw and other ecosystem tools to
 inspect and consume the same registry records and evidence.
 ## Current Direction
 The current focus is:
-Priority:
+- make Claws a reliable one-command starting point for useful personal agents
 - make strong ecosystem skills and plugins discoverable without requiring them
  to originate on ClawHub
 - preserve provenance while combining ecosystem and OpenClaw-specific signals
 - strengthen publisher identity, permissions, and authorization
 - keep security evidence visible while improving ClawHub-owned scanning and
  moderation
- Security and safe defaults
+## What ClawHub Will Not Become
 - Bug fixes and stability
 - Setup reliability and first-run UX
-Next priorities:
+- An agent runtime or replacement for OpenClaw.
 - A source-control host that requires every project to move its code.
 - A universal package registry for every agent framework.
 - A store for model-provider keys, channel credentials, or local runtime
  secrets.
 - A guarantee that published or scanned content is safe.
 - A system that treats popularity, Official status, or any single scanner as
  sufficient proof of trust.
- Supporting all major model providers
+These boundaries are direction-setting guardrails, not a refusal to evolve.
- Improving support for major messaging channels (and adding a few high-demand ones)
+Strong user needs and clear technical evidence can change how ClawHub fulfills
- Performance and test infrastructure
+the mission without changing what it is responsible for.
 - Better computer-use and agent harness capabilities
 - Ergonomics across CLI and web frontend
 - Companion apps on macOS, iOS, Android, Windows, and Linux
 ## Security
 Security in OpenClaw is a deliberate tradeoff: strong defaults without killing capability.
 The goal is to stay powerful for real work while making risky paths explicit and operator-controlled.
 Canonical security policy and reporting:
 - https://github.com/openclaw/openclaw/blob/main/SECURITY.md
 We prioritize secure defaults, but we also expose clear knobs for trusted high-power workflows.
 ## Plugins & Memory
 OpenClaw has an extensive plugin API.
 Core stays lean; optional capability should usually ship as plugins.
 Preferred plugin path is npm package distribution plus local extension loading for development.
 If you build a plugin, please host and maintain it in your own repository.
 The bar for adding optional plugins to core is intentionally high.
 Memory is a special plugin slot where only one memory plugin can be active at a time.
 Today we ship multiple memory options; over time we plan to converge on one recommended default path.
 ### Skills
 We still ship some bundled skills for baseline UX.
 New skills should be published to ClawHub first (`clawhub.ai`), not added to core by default.
 Core skill additions should be rare and require a strong product or security reason.
 ### MCP Support
 OpenClaw supports MCP through `mcporter`: https://github.com/steipete/mcporter
 This keeps MCP integration flexible and decoupled from core runtime:
 - add or change MCP servers without restarting the gateway
 - keep core tool/context surface lean
 - reduce MCP churn impact on core stability and security
 For now, we prefer this bridge model over building first-class MCP runtime into core.
 If there is an MCP server or feature `mcporter` does not support yet, please open an issue there.
 ### Setup
 OpenClaw is currently terminal-first by design.
 This keeps setup explicit: users see docs, auth, permissions, and security posture up front.
 Long term, we want easier onboarding flows as hardening matures.
 We do not want convenience wrappers that hide critical security decisions from users.
 ### Why TypeScript?
 OpenClaw is primarily an orchestration system: prompts, tools, protocols, and integrations.
 TypeScript was chosen to keep OpenClaw hackable by default.
 It is widely known, fast to iterate in, and easy to read, modify, and extend.
 ## What We Will Not Merge (For Now)
 - New core skills when they can live on ClawHub
 - Commercial service integrations that do not clearly fit the model-provider category
 - Wrapper channels around already supported channels without a clear capability or security gap
 - First-class MCP runtime in core when `mcporter` already provides the integration path
 - Heavy orchestration layers that duplicate existing agent and tool infrastructure
 This list is a roadmap guardrail, not a law of physics.
 Strong user demand and strong technical rationale can change it.