website → capsule → website

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

Portable frontendUpload a static site zip and compile it into verified chunks plus a manifest.
Executable capsulePaste the capsule back into the runtime and rebuild the original site from the capsule text.
Cold authorityFor real backend/Web3 actions, keep the site cold and activate one-time capabilities only when requested.
BuildCompile a repository and package the same verified app for each platform.
RuntimeCapsules mount through a virtual Service Worker origin.
Capability relayAuthority is scoped, short-lived and replay-rejected.
Execution leasesCapability cards turn backend needs into bounded policies.
Cold Web3Signed Solana intents become transferable auth packages.
Build

Source to installer.

Choose a repository, review what cApp found, compile it, then package the same verified build.

Current stageSource

Application source

Select the repository, confirm its runtime boundaries, then compile.

waiting for source

Open a project to link one or more application directories, or choose a one-off ZIP.

Choose project source directories or a ZIP to inspect its browser entry, framework build, SDK, local services and backend demand.
No source analysed yetcApp will recommend the least destructive build path after inspection.

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.

Waiting for source
Scan the application to determine whether a runtime backend is required.
cApp SDK detection appears here.

No runtime backend attached yet.

Choose a different build method
Direct

Package existing browser output

For static sites, existing dist/out folders and cApp source assemblies.

Framework

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.

Waiting for source
Ships with app Stays hosted Needs review
The application topology appears after source analysis.

Runtime boundaries

Change these only when the detected defaults are not right.

Capsule and config policy
Design execution lease
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.

AI, billing, uploads, entitlements, admin and provider authority remain hosted.
Legacy data contract view
No data contract drafted yet.

Generated JSON

Inspect or override the generated contracts.

No generated contract selected.

Project release history

The latest compiled release for the active project loads automatically. Five releases are shown at a time.

All local apps
Version history not loaded yet.No local compiler events yet.
Open a project to enable release autoload.
0 releases

No release selected

Compile this project or load one of its local releases.

Waiting
Project releaseNot loadedThe latest active-project release will load automatically when available.

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.
backend abstraction

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.

One-time capability relay simulatorcold site · no capability minted

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.
execution lease designer

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.

Capability cardsno execution lease generated

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.
cold web3 execution

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.

Dummy Solana transaction buildercold · no intent built

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.

Actionsystem transfer + memo
Broadcastfalse by default
Bindingcapsule transcript + wallet + nonce
Local relay servicerelay not checked

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.

Confirm the hot boundary is online.The relay is separate from the capsule. Wallet connection does not need it, but capability minting/execution does.
Connect the browser wallet.Solflare, Phantom, or another Solana provider approves identity in the browser. No relay-side call is needed for this step.
Create the unsigned request.The intent binds wallet, recipient, memo, network, nonce, capsule transcript and ephemeral session seal.
Authenticate without exposing a secret.The wallet signs the human-readable intent. If no wallet exists, the demo clearly marks the pseudo-signature.
Optional transaction-object signing.This loads Solana web3.js, builds a transfer+memo transaction for the selected RPC, asks the wallet to sign it, and still does not broadcast. If Solflare is on mainnet while this app is set to devnet, the wallet may reject with a network mismatch; the signed-intent relay flow still works.
Package the signed authority.The exported package is what a relay/local executor can verify before one bounded action.
Run local consistency checks.Checks package hash, active capsule transcript, session seal, expiry, signature presence and single-use relay policy.
Ask the relay to challenge the request.The relay signs a challenge bound to this wallet/capsule/session/intent. This is where the hot boundary begins.
Convert auth into a one-time token.The relay consumes the challenge and returns a capability token with TTL/max-use limits.
Execute one known safe handler.The MVP relay dry-runs Solana submit/simulate, burns the use, writes a signed receipt, and rejects replay.
Frontend-only fallback.This proves the UX without the relay. The real product path is the local/managed relay above.
No cold Solana execution intent built yet.
Live cold transaction capsule running underneathmini capsule not mounted 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.

Capsule side
Renders its own cold transaction UI, holds no permanent backend secrets, and only sends capability requests to the host runtime.
Host side
Owns wallet/relay policy, binds requests to the active capsule transcript, returns signed packages/receipts, and can reject replay.
cApp Studio · MCP sandbox

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.

Local cApp MCP backendMCP backend not checked

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.

Health
Tools
Agent framework manifest
Project / creation briefsafe tool calls only

Describe what you want the local LLM to build. The MCP server turns this into concrete cApp steps, capability cards and adaptive-site plans.

cApp creation guide
Adaptive site plan
Capability cards
LLM builder prompt
Agent website builder workspacecreate · refine · audit · capsule

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.


            
            

          
Workspace editorbounded project files

Agents can use the same read/write tools. This editor is just a human-visible control surface for the workspace tools.


            
Live workspace previewserved from MCP workspace

The preview is served from /preview/<project>/index.html. It is enough for static-site refinement; browser screenshot tooling can be added later.

Local LLM bridgeOllama / LM Studio

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.


          
Project scanner inputcaller-provided file list only

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.


          
capsule loader

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.

Paste registry / capsulewaiting for input

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.

Capsule contract viewerwaiting for pasted capsule

Inspect the pasted capsule without running it. A compiler-built capsule should already contain source-reconciled contract and connection state, so this page mainly verifies and displays it.

Advanced: source ZIP override / old capsule repair

Use this only for an older frontend-demand-only capsule. New capsules should be source-reconciled at compile time.

No advanced source override loaded. Compiler-built capsules should already include safe source-reconciled contract state.

Inspection summary
Paste a capsule, then click Inspect capsule.
Source reconciliation
Compiler-built capsules usually include this already. Use advanced source override only for old capsules.
Grouped route plan
No grouped route plan yet.
Server-contract seed
No server-contract seed yet.
Binding-contract seed
No binding-contract seed yet.
Backend SDK implementation guide
Inspect a capsule to generate the backend SDK guide/spec sheet.
SDK bundle contents
No SDK bundle generated yet.
Backend SDK starter
No SDK starter generated yet.
Legacy/public leak scan
No legacy/public leak scan yet.
Capability outline
No capability outline extracted yet.
Frontend backend-contract
No frontend backend contract extracted yet.
Wallet bridgewaiting for reconstructed app

Reconstructed apps can request wallet-style actions through a controlled bridge. This keeps the runtime in charge of permissions and logging.

Ephemeral session sealno runtime session seal yet

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.
Sealed backend/operator layerlocked

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.
Developer Showcase · M9.3

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.

Select or compile a verified release, then cApp will prepare its Showcase demo.

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.

Stopped
PresentationWhat the viewer seesHide cApp's demo-sidecar dock or strip host chrome for a cleaner product view.
Quick sidecarsJump into composed servicesOnly sidecars already present in the immutable demo snapshot can appear here. The cApp-owned demo Sidecars panel stays collapsed during normal Showcase and public Showroom viewing; real browser Sidecars keep their own packaged startup behaviour.
Start the demo to see its composed sidecars.
SessionRun, reset, repeatReset recreates the immutable seeded demo state. Stop destroys the hostile cell.
Start the browser-hosted demo to control its sidecar presentation from here. Installed/native Showcase keeps the same sidecar UI inside its dedicated window.

Which project are we showing?

The active project and its verified release are the only source of Showcase truth.

Nothing analysed yet

Showcase works from the verified release graph only; it never recompiles raw source.

waiting

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.

No active Showcase projectT3 preview
Untrusted demo surfacecApp owns this frame. Product JavaScript runs below without inheriting cApp host authority.
T3 · untrusted
▶Demo preview not running

Build the active project's verified Showcase demo, then control it from the board above.

Manage the public Showroom listing.

Save drafts locally to the cApp project. Publishing writes canonical showroom/product.json to the bound public GitHub repository, retains the latest three listing revisions, and registers the current document with Showroom.

JSON authoring

Download the current editable shell, change it by hand or with an agent, then import it back. Multi-component projects include public listing copy for every published component; cApp keeps demo hashes, versions, readiness, repository authority and published media URLs bound to the real project.

Accepts capp.showroom.product-edit.v1, canonical capp.showroom.product.v1, or a saved local product draft. Legacy single-product shells remain valid.
Publication pipelineOne operation · GitHub → ShowroomDraft locally now. GitHub authentication, public repository creation, demo upload, product publication and Showroom registration happen only when you press Publish.
RepositoryDemoListingShowroomLive

Public repository

Name the public payload repository. You do not create it separately: cApp creates or reuses it automatically inside the publication transaction.

One button owns the transaction. If GitHub succeeds but registration is interrupted, cApp resumes at registration instead of creating another repo or re-uploading the whole project.

Listing identity

Classification & availability

Availability is a discovery signal, not a binding offer. Open to discussion welcomes proposals across purchase, licensing, partnership, services or other arrangements.
Platforms

Availability & terms

Publisher

Public media

Selected files and configured Showcase captures are decoded and re-encoded as WebP before upload, stripping original image metadata. SVG/GIF are refused.

Configured Showcase capture navigatorSingle products can explore rendered safe states deeply. Canonical projects cycle every published component and capture its landing surface at Wide, Compact and Mobile sizes. Raw release files and hidden website crawlers are not capture inputs.
Showcase preview idleOpen the product editor or start the preview to materialise the configured Showcase demo.
Automatic capture is on. Capture-only Showcase cells may temporarily open the composed demo Sidecars panel before a screenshot so Sidecar presentation can be included in generated media; normal Showcase and public Showroom previews stay collapsed unless the product/user opens them. Single products explore rendered safe states; canonical projects visibly cycle each published component and capture Wide, Compact and Mobile landing frames when component media is missing.
Configured Showcase capture previewM3 demo · compatibility + demo seed + current backend policy
Preparing configured Showcase demo…
Safe targets visible nowClick one to watch cApp focus/open it inside the demo
Start the Showcase preview to inspect the UI currently rendered by the demo.
No captured frame selected yet.
No Showcase captures queued.
Edit and save the product page before first publish, or reload an existing published listing.

Build the profile behind the products.

One public profile can represent an individual, studio, or team across every Showroom listing. Share what you build, what changed, what you are looking for, and the evidence an investor, acquirer, partner, customer, or future teammate actually needs.

JSON authoring

Use the portable profile shell for agent-assisted or external editing, then import it here. cApp keeps the selected GitHub owner/repository and existing published media authoritative rather than trusting those values from an import file.

Accepts capp.showroom.developer-edit.v1, canonical capp.showroom.developer.v1, or a saved local developer draft.

Public identity

cApp keeps this profile in a dedicated public repository so it can follow you across projects without belonging to any one app.

Publisher identity

What you build

Opportunity signal

This is deliberately explicit. It lets the right people know whether to approach you for customers, capital, acquisition, licensing, partnerships, or talent — without turning the profile into a job board.

Worth contacting me about

Proof, traction & credibility

One signal per line. Use Label | Value | Note | https://... or simply Label: Value. Keep it verifiable and useful rather than vanity-heavy.

Public links & media

Images are decoded and re-encoded as WebP before publication to strip original metadata.

Updates & goings-on

Publish small durable signals: what shipped, what changed, what you are building next, or what kind of person/deal you are looking for. Product releases also appear automatically in the public activity feed.

Connect GitHub to edit your public publisher profile.
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.

Showcase M2Not materialisedAnalyse the selected release, then build the deterministic local artefact.

Open the exact file before you publish it.

The downloaded .capp-showcase is the same byte-for-byte artefact a future provider will host.

Drop a .capp-showcase hereLocal disk does not imply trust. cApp re-verifies archive shape and every declared payload hash.
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.
Remote mode never hands the guest ambient 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.
Browser cApp uses the opaque M3 cell. Installed Tauri cApp uses the dedicated broker-only M4 WebView. Local and remote bytes enter the same verifier/runtime boundary.
Raw capp.showcase.v1 manifest

            
Raw capp.showcase.compatibility.v1 report

            
cApp Showroom

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.

Loading Showroom…
Products

Explore software products

Browse published applications, tools, services and platforms by type, platform and availability. Sidecars have their own catalogue.

0/0
Tags appear here as product pages are published.
Advanced · open a public demo URL
Direct demo

Open a published demo URL.

Paste a public cApp demo descriptor or latest URL to verify and open it directly.

cApp Showroom publisher
cApp Showroom listing
Viewer runtime

Actual published demo

No Build-page shortcut and no publisher credential. The selected public bytes must survive M6 verification before M3/M4 sees them.

Nothing loadedSelect Run demo to open a product.Demo files are fetched directly from the publisher.
▶Choose a product demo

The demo loads only when you ask to run it.

trust model

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.