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.

Build an app Try cold Web3 See backend abstraction

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
Source

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.
Release binding

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.

Analysis

Application map

See what ships, what stays hosted, and what needs review.

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

Runtime boundaries

Change these only when the detected defaults are not right.

Capsule and config policy
Design execution lease
Offline data and relay policy
AI, billing, uploads, entitlements, admin and provider authority remain hosted.
Legacy data contract view
No data contract drafted yet.
Contracts

Generated JSON

Inspect or override the generated contracts.

No generated contract selected.
Releases

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
Selected release

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.

              
preview not generated yet

              
            

          


          

            
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 · GitHub required
              
Sign in before you start.

              
Showcase publishes products into the cApp Showroom through your public GitHub repository. cApp verifies your GitHub identity and c-App showcase installation first, so you never build or edit a publication only to discover at the end that publishing is unavailable.

            

            
Checking GitHub publication authority…

            

              
              
              
            

            Owner-browser Showcase signs in through the hosted cApp Showcase API at c-app.uk. The GitHub Client Secret stays server-side and never enters this page. Distributed installs may use GitHub device flow.
          

        


        

          

            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.


        

          

            
Demo control board
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.

              
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.
        


        

          

            
Demo target
Which project are we showing?
The active project and its verified release are the only source of Showcase truth.

            
Change projectChoose release

          

          

          

          

            
Selected compiled release
Nothing analysed yet
Showcase works from the verified release graph only; it never recompiles raw source.

            waiting
          

        


        

          

            
Demo preview
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.

          

        


        
          

            

              
M9.2 · Showroom publication
Publish this product to the cApp Showroom.
GitHub is the public storage and delivery layer; the cApp Showroom registry stores only the verified product pointer. Visitors fetch product metadata, media and demo bytes directly from GitHub rather than through cApp's site.

              
            

            

              

                
1 · GitHub publication authority
Showcase now verifies this before the workbench opens. Owner-hosted localhost uses normal browser OAuth when the platform server has CAPP_GITHUB_CLIENT_SECRET; distributed installs use GitHub device flow as the secret-free fallback. The resulting user token is still limited by both your GitHub rights and the GitHub App installation.
Disconnected

                
                

                  Sign in first; cApp will then check where the GitHub App is installed.
                  
                

                
                

                  Developer fallback
                  

                    GitHub App: c-App showcase · bundled public Client ID Iv23lioRiuebreom0ZMi. No client secret or private key is shipped in downloadable cApp. The hosted Showcase API holds the Client Secret server-side only.
                    

                      
                      
                    

                  

                

                OAuth access tokens stay in trusted cApp memory and never enter project state, Showroom JSON or published demo bytes. The localhost OAuth broker exchanges the authorization code server-side; device flow remains available without a Client Secret. Viewer pulls remain anonymous GitHub HTTPS.
              


              

                
2 · Create or choose a public repository
The normal cApp path is one public payload repo per project, for example chefspecials-public. Viewer-side pull intentionally has no GitHub credential, so private/unlisted access remains a separate access-control design.

                

                  Create a project Showcase repository
                  

                    
                    
                    
                  

                  cApp creates an initialized public repository through the GitHub App user session so main exists immediately. GitHub automatically grants the installed app access to repositories it creates, including when the installation otherwise uses selected repositories. The project record stores only public pull metadata—never the GitHub token.
                

                
or use an existing repository

                

                  
                  
                  
                

              


              

                
3 · Safety gate + publish to Showroom
The exact verified .capp-showcase is audited again, uploaded to the bound public GitHub repository, then its showroom/product.json pointer is registered with cApp. Publication is refused if high-confidence credentials, sensitive/private paths, source maps or native/service implementation material are detected.

                
Publication safety gateBuild the current demo first. Browser code is necessarily inspectable by viewers, so secrets must never be in the browser closure.

                

              


              

                
4 · Direct-viewer delivery proof
The pull button deliberately goes through the existing provider-neutral M6 verifier using the public commit-pinned descriptor URL. No GitHub token is sent. That is the path the Showroom will use.

                
Nothing published in this cApp session yet.

              

            

          

        

        
          

            

              
M9.2 · Showroom product editor
Design the buyer-facing product page.
Save drafts locally to the cApp project. Publish updates showroom/product.json in the same public GitHub project repo, keeps the latest three product revisions, and registers the current pointer with the cApp Showroom.

              
            

            

              

                
Identity

                
Buyer filters
Platforms

                
Commercial

                
Publisher

                
Public media
Selected files are decoded and re-encoded as WebP in cApp before upload, stripping the original image metadata. SVG/GIF are refused.

              

              
            

            
Open a published project to edit its product page.

          

        

        
          

            

              
M9.3 · Developer identity
Build the profile behind the products.
One public profile can represent you, a studio, or a team across every Showroom product. Share what you build, what changed, what you are looking for, and the evidence an investor, acquirer, partner, customer, or future teammate actually needs.

              
            

            

              

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

                
Who are you?

                
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 developer profile.

          

        

        

          Info & advancedCompatibility, exact artefact internals, local/remote verification, network policy and runtime diagnostics.
          

            

              

                
Build & compatibility tools
Release internals
Manual analysis/export controls and the exact compatibility/materialisation facts used by Showcase.

                

                  
                  
                  
                  
                

              

              

              

              
Thin materialisation estimate
What stays, what goes.
Service contracts remain visible while embedded service source, native artefacts and source maps are excluded from the public demo.

              

              

              
Deterministic artefact
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.

            


            

              

                
M6.1 · Local Showcase file
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.

            


            

              

                
M6 · Remote descriptor / fetch
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.

              

                
                
              

            


            

              

                
M5 · Backend / network policy
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.
            


            

              

                
Runtime requirements
Environment resolution.
Unavailable requirements are explicit rather than silently failing inside a public demo.

              

              

            


            

              
Preview diagnostics
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
              

            

          

        

      

    


    

      

        

          

            Showroom · M9.3 products + builders
            
Discover the product. Then try the real thing.

            
Discover products and the builders behind them. cApp stores only small public discovery pointers; product pages, developer profiles, media and interactive demo bytes stay publisher-owned in public GitHub repositories and travel directly to this device.

          

          

            Download cApp Alpha
            Developer Showcase
            
          

        


        
Loading published products…


        

          
Buyer catalogue
Published products
Search and filter structured capp.showroom.product.v1 pages fetched directly from each project repo. The hosted cApp index stores discovery pointers only; canonical product content stays with the publisher.
0/0

          

          
Tags appear here as product pages are published.

          

        


        

          
Builder network
Developers & studios
Follow the people behind the products: recent shipping activity, technical focus, portfolio, opportunity status and credible traction. Product ownership links are derived from the same public GitHub identity rather than maintained as a second hand-curated portfolio.
0

          
◌No public developer profiles loaded yet
Profiles appear here once a builder publishes their showroom/developer.json.

        


        
Info & advanced · direct public URL

          
Already published?
Try the exact public URL now.
Paste a public GitHub latest.json / immutable descriptor URL. This remains a developer proving tool rather than normal market UI.

          

        


        
cApp Showroom developer


        
cApp Showroom product


        

          

            
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 fetch directly from the public provider.The cApp site is not a payload proxy.

          
▶Choose a public demo
Descriptor and payload download happen only after you press Run demo.

        

      

    


    

      

        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.