cApp
A universal landing page, compiler and runtime for executable web capsules. A site can be zipped, capsuled, shared, verified and reconstructed without depending on a normal origin URL.
What this demo proves
Source to installer.
Choose a repository, review what cApp found, compile it, then package the same verified build.
Application source
Select the repository, confirm its runtime boundaries, then compile.
Open a project to link one or more application directories, or choose a one-off ZIP.
WaitingNo folders linked
Not prepared · V253 keeps folder source and analysis in local content-addressed storage instead of browser memory.Project layout & automation
Runtime backend
Online-only SDK and API routes need somewhere to go after packaging. This origin is bound into the verified release when you compile.
No runtime backend attached yet.
Choose a different build method
Package existing browser output
For static sites, existing dist/out folders and cApp source assemblies.
Build the frontend first
For Next.js, Vite, Nuxt, Svelte and other framework repositories.
Application topology
Compiler truth: what the app is, what ships locally, what stays hosted, and which immutable release the native targets consume.
Runtime boundaries
Change these only when the detected defaults are not right.
Offline data and relay policy
Plan settings for this component, then compile to include them in a release. Packaging always uses the selected release’s saved settings. Offline execution also needs a compatible runtime.
Legacy data contract view
No data contract drafted yet.
Generated JSON
Inspect or override the generated contracts.
No release selected
Compile this project or load one of its local releases.
The latest active-project release will load automatically when available.
Export release files
Release contracts and diagnostics
Connection state
No backend connection state yet.
Config/runtime report
No config/runtime boundary report yet.
Backend summary
No backend contract extracted yet.
Cold site, hot one-time capability.
This page demos the backend abstraction level. The public capsule remains cold and inert; a relay mints authority only after a signed, scoped, expiring request.
A real relay would run as a tiny backend trust-kernel. This demo simulates its lifecycle so the policy is obvious before we host the actual relay.
No capability request built yet.
Give a cold capsule temporary powers.
Pick a capability card, set expiry/usage limits, and generate the execution lease that the real relay service will verify in the next build.
These cards are product UX over the boring security bits: nonce, TTL, max uses, receipt policy, capsule hash binding, and no permanent frontend secrets.
Choose a card or build a lease.
Build a signed Solana auth package.
This page is the Web3-specific demo: the host builds/verifies a cold Solana execution package while a separate mini capsule runs underneath and requests those steps through the runtime bridge.
The demo does not broadcast. Solflare/Phantom connect and sign in the browser; the relay verifies the exported package, mints a one-time capability, burns it, and returns a receipt. Transaction-object signing is optional; the signed intent is the main relay path.
Run the separate local relay server, then use the buttons below to challenge, mint and execute one bounded capability. This is the real boundary the next managed relay would harden.
No cold Solana execution intent built yet.
This iframe is not just another paragraph on the host page. It is a separate miniature Web of verified capsule mounted through the same virtual-origin runtime. It asks the host to build, sign, export, verify and one-time-execute a dummy Solana auth package.
Renders its own cold transaction UI, holds no permanent backend secrets, and only sends capability requests to the host runtime.
Owns wallet/relay policy, binds requests to the active capsule transcript, returns signed packages/receipts, and can reject replay.
Local LLM-guided cApp creation.
This sandbox connects the browser runtime to a separate local MCP-shaped backend. The backend exposes safe cApp tools and can proxy Ollama or LM Studio without giving the model arbitrary shell access.
Run python mcp\capp_mcp_server.py --host 127.0.0.1 --port 8799. The page talks to the MCP backend over HTTP. A proper agent host can also use the backend's minimal JSON-RPC MCP surface.
Describe what you want the local LLM to build. The MCP server turns this into concrete cApp steps, capability cards and adaptive-site plans.
This is the MCP framework exposed to agents. It gives a local agent a bounded workspace and named tools for creating/refining a website, auditing it, generating capability manifests, compiling a capsule, and previewing the result. No arbitrary shell or arbitrary filesystem reads are exposed.
Agents can use the same read/write tools. This editor is just a human-visible control surface for the workspace tools.
The preview is served from /preview/<project>/index.html. It is enough for static-site refinement; browser screenshot tooling can be added later.
The browser calls the MCP backend, and the backend calls only a localhost LLM endpoint. This avoids CORS pain and keeps the model connection local.
Optional: choose files/a folder so the browser passes path names to the MCP backend. The server does not read arbitrary local disk; it only scans the list the browser supplies.
Verify and run a compiled capsule.
Runtime should mostly verify what Compiler already produced: a tiny pointer capsule plus a locally stored or imported page bundle. Source ZIP upload is now only an advanced override.
Pointer mode keeps the pasted capsule tiny and resolves the verified page bundle from this browser, an imported bundle/Babel resolver page, or a deterministic hosted page path. Full/packed capsules still work as compatibility fallbacks.
Managed backend gateway / local route proxy
Attach a local hosted backend for online-only routes such as auth, entitlement, AI, billing and uploads. Offline+ routes still use the generated local relay sidecar.
No managed backend attached. Backend-required routes will return requiresBackend until this is set.
Page/Babel bundle import for pointer capsules
Only needed when the pointer was created in another browser/device, or when the deterministic Babel page is distributed separately from the pointer.
Pointer capsules compiled in this browser resolve automatically. Import a page bundle or deterministic Babel page only when using a pointer from another device/browser.
Reconstructed apps can request wallet-style actions through a controlled bridge. This keeps the runtime in charge of permissions and logging.
Every reconstructed run now selects a random runtime page/key commitment. This binds one-time capabilities to this exact execution session without shipping a permanent key inside the capsule.
Paste or load a capsule to create an ephemeral session seal.
Demo only: unlock fake backend config to prove the model. In production, decrypt real DB/API secrets only in a trusted builder/backend environment, not a public browser.
No sealed layer unlocked.
Open a project to set up its demo
Build the verified project demo, shape how it is presented, and test the real product inside the isolated Showcase runtime. Deep diagnostics stay out of the way until you ask for them.
Shape the demo without changing its authority.
These controls affect the current Showcase presentation and ephemeral session only. They never promote T3 content or mutate the verified release.
Which project are we showing?
The active project and its verified release are the only source of Showcase truth.
Project component demos
Showcase detects every application component in the active project. Compiled surfaces can be previewed independently and Publish walks every available component into one canonical Showroom project.
Nothing analysed yet
Showcase works from the verified release graph only; it never recompiles raw source.
Run the product here before you publish it.
The actual verified Showcase browser payload runs below inside the M3/M4 hostile cell—not a screenshot or Build-page preview.
Build the active project's verified Showcase demo, then control it from the board above.
Info & advancedCompatibility, exact artefact internals, local/remote verification, network policy and runtime diagnostics.⌄
Release internals
Manual analysis/export controls and the exact compatibility/materialisation facts used by Showcase.
What stays, what goes.
Service contracts remain visible while embedded service source, native artefacts and source maps are excluded from the public demo.
Exact materialisation.
M2 stores runtime-reachable browser files at their original paths and verifies every declared file before download.
Open the exact file before you publish it.
The downloaded .capp-showcase is the same byte-for-byte artefact a future provider will host.
M6.1 local verification diagnostics
Choose or drop a local .capp-showcase file. No local bytes are trusted yet.
Load the same demo from any HTTPS provider.
Provider-neutral descriptors stay separate from the Showcase runtime. GitHub can become one adapter later without becoming protocol authority.
M6 remote verification diagnostics
Paste a remote descriptor or descriptor URL. No remote bytes are trusted yet.
Choose authority explicitly.
The same deterministic demo can stay browser-local or use an explicitly brokered release/demo backend. Direct guest networking remains off.
M5 policy diagnostics
Build the deterministic artefact to derive the verified public backend/route allow-set.
fetch, cookies, Authorization, Tauri HTTP authority or arbitrary destinations. capp.showcase.capability-grant.v1 remains exact-release and provider-verified.
Environment resolution.
Unavailable requirements are explicit rather than silently failing inside a public demo.
Hostile-cell state
Security/broker facts and recent runtime events for debugging only.
Preview security / broker events
No hostile-runtime events yet.
Raw capp.showcase.v1 manifest
Raw capp.showcase.compatibility.v1 report
Discover software, sidecars and the publishers behind them.
Explore published software and cApp sidecars from independent publishers, studios and teams. Review verified demos, availability and terms, or open a publisher profile for portfolio and project context.
Showroom
Discover products, sidecars and their publishers.
Explore software products
Browse published applications, tools, services and platforms by type, platform and availability. Sidecars have their own catalogue.
Explore cApp sidecars
Discover focused additions for cApp applications. Sidecars listed here are free additions for now; direct Library installation and a formal licensing model are future platform work.
Publishers
Browse publishers, studios, teams and organisations behind Showroom listings. Publisher pages collect products, sidecars, updates, focus and public project activity.
Profiles appear here when a publisher registers a Showroom identity. Existing showroom/developer.json documents remain compatible.
Advanced · open a public demo URL
Open a published demo URL.
Paste a public cApp demo descriptor or latest URL to verify and open it directly.
Actual published demo
No Build-page shortcut and no publisher credential. The selected public bytes must survive M6 verification before M3/M4 sees them.
The demo loads only when you ask to run it.
Two configs, same codebase.
cApp should not split into two apps. It should generate different manifests/configs from the same compiler and runtime.
Trustless full-surface capsule
Best for games, docs, archives, static demos and open Web3 frontends. Everything safe and public goes into the capsule. It runs without backend authority.
trustProfile.mode = trustless-full-surface includes: frontend files public assets public chain config contract ABIs excludes: backend secrets private keys
Cold capability capsule
Best when the site needs to do something real. The frontend remains portable and public; authority arrives as a short-lived capability from a relay.
trustProfile.mode = cold-capability includes: relay URL allowed scopes expiry policy replay policy activation: wallet/runtime signature one-time key receipt
The honest secret rule
If the public browser can decrypt or use a secret, the user can extract it. So cApp capsules should carry frontend code and public config. Real backend secrets live behind relays, sealed operator layers, or threshold/MPC-controlled services.