Runtime Layer

SmartWeb starts with your own local world.

ElastOS Runtime gives you a rooted local world for chat, sharing, sites, apps, and AI. Install it, run elastos setup, then open your PC2 home to chat. Add explicit extras when you want direct share/open, and preview a site from your own rooted localhost://... space. Apps and agents use explicit capabilities instead of broad account access.

Developer Preview. Pre-release and unstable. Verified on Linux x86_64 and aarch64. Operator and runtime surfaces remain explicit. Not for production or important workloads.

Canonical install

Install from the public gateway, run setup once, then open your PC2 home. Add explicit extras when you want direct share/open, or preview a local site right away.

curl -fsSL https://elastos.elacitylabs.com/install.sh | bash

View installer Release head

What it installs: the signed elastos binary and component registry. Capsules: downloaded on demand when a command needs them. Direct share/open extras: elastos setup --with kubo --with ipfs-provider --with md-viewer Canonical publisher gateway: https://elastos.elacitylabs.com

Setup

Provision the core path once.elastos setup

Home

Open your local PC2 home surface.elastos

Chat

Start chat in one terminal after setup.elastos chat --nick alice

Add the direct share/open extras, then publish a file with stable identity.elastos setup --with kubo --with ipfs-provider --with md-viewer && elastos share README.md

Site

Stage and open a local site.elastos site stage ./website && elastos open localhost://MyWebSite

Why This Matters

Keep your local world first, then share and expose it on your terms.

SmartWeb should not start with broad account access, opaque cloud state, or public URLs as the primary identity model. ElastOS Runtime starts locally. Every capsule, tool, or agent begins with no permissions and gets precise capability tokens for precise actions.

Zero ambient authority

Capsules and agents start with no access until the runtime grants a capability.

Precise access

Read, write, network, and provider actions are scoped to explicit tokens instead of all-or-nothing account trust.

Auditable and revocable

If a valid token is missing, the action does not happen. Runtime-side validation and audit logging stay in the trust core.

Humans and AI, same model

A person using a shell and an AI agent running in the background use the same capability system and APIs.

Your First 5 Minutes

Open home, chat, share a file, and preview a site.

These are the quickest real paths for a new user after install. Chat is part of the core setup path. Direct share/open uses explicit extras. Local site preview stays rooted in localhost://MyWebSite.

Open PC2 home

After setup, elastos opens the local PC2 home surface instead of dropping you into a vague daemon story.

curl -fsSL https://elastos.elacitylabs.com/install.sh | bash
elastos setup
elastos

Start chat

Chat is the narrow one-terminal managed runtime path for the current preview.

elastos chat --nick alice

Share a file

Sharing gives you a stable elastos:// identity first, with local open and optional public transport on top. On a fresh install, add the explicit share/open extras first.

elastos setup --with kubo --with ipfs-provider --with md-viewer
elastos share README.md
elastos open elastos://<cid>

Preview a local site

Your browser-facing local root is localhost://MyWebSite.

elastos site stage ./website
elastos open localhost://MyWebSite

Update safely

The installer, release metadata, and update flow are signature-verified.

elastos update

What this preview already proves

Current proofs include install, PC2 home, chat, direct sharing, local sites, and the wider native/WASM/microVM runtime work on Linux.

How It Works

A small trusted core, with your local world and apps on top.

The runtime keeps the trusted part narrow: isolation, signatures, capability validation, local state, and routing. Providers and capsules sit above that core so your local world, apps, and agents do not need broad ambient authority.

Runtime core

Isolation, signatures, capability validation, release trust, and local state handling live here.

Providers and network

Rooted localhost://... paths, elastos://peer/, elastos://ai/, and signed content flows are exposed through provider contracts instead of ambient access.

Capsules and apps

Chat, agents, viewers, and other capsules run on top of the runtime instead of being part of the trust core.

Command surfaces

chat auto-manages a user runtime, share and update run direct, and agent, capsule, and runtime-backed WASM or microVM work use an explicit operator runtime.

Local And Network Spaces

Keep local state, shared identities, and public transport separate.

Local state

File-backed local roots such as localhost://Users/..., localhost://Public/..., and localhost://ElastOS/... stay on your own node.

Browser root

localhost://MyWebSite is the browser-facing local site root. localhost://Public/... remains the shared-files root.

Reserved special root

localhost://WebSpaces/... is the future dynamic WebSpace/AppCapsule resolver surface, not ordinary path-based storage.

Shared identity

The stable identity returned by elastos share is elastos://<cid>.

Open locally

elastos open elastos://<cid> opens that share through the local bridge.

Immediate public link

elastos share --public keeps a live public edge open while the command runs.

Gateway note

Plain gateway links are convenience transport and may take time to propagate. The CID remains the stable shared identity.

Sites

Publish sites from your local world, then choose how they are exposed.

The current model is local-first: your browser-facing site lives under localhost://MyWebSite, you stage it with elastos site stage, and public reachability is an explicit gateway choice.

Local

Use elastos site serve --mode local with your own stable IP, reverse proxy, or domain.

Ephemeral

Use elastos site serve --mode ephemeral for a temporary cloudflared edge.

Supernode / Active Proxy

Planned next: a higher-availability hosted front door that proxies or mirrors the same local/public site contract.

Humans and AI agents follow the same rules.

In ElastOS, a human using a shell surface and an AI agent running in the background are the same kind of actor. They request capabilities through the same API, receive the same cryptographic tokens, and are audited the same way. There is no separate AI backdoor.

Provider surface

The runtime includes an elastos://ai/ provider contract for model routing under the same capability system used everywhere else.

Scoped read access

An agent can be given a short-lived read token for localhost://Users/self/Documents/Calendar/* to suggest meeting times without broader access.

Scoped read and write

An agent can read localhost://Users/self/Documents/Notes/project-x/* and write only to localhost://Users/self/Documents/Drafts/*.

Scoped by area

An agent can work on localhost://Users/self/Pictures/* without being able to read localhost://Users/self/Documents/*.

Why it matters

AI never gets account-wide access. If it does not have a valid token for a specific action, the runtime does not execute it.

Current proof

A Codex-backed operator agent path is already proven on this server through the explicit operator runtime.

SmartWeb Model

One runtime, with your local world at the center.

`localhost://...`

Rooted local PC2 spaces such as Users, UsersAI, ElastOS, Public, and MyWebSite stay on your own node.

`elastos://`

Content-addressed identities, peer surfaces, provider contracts, and signed network resources live here.

WebSpaces + AppCapsules

WebSpaces are special AppCapsules that resolve named monikers dynamically, while file-backed localhost roots remain ordinary local state.

What Converges Later

Keep broader system vision separate from current proof.

PC2 and shell surfaces

Richer desktop, browser, and hosted-shell experiences can sit above the same runtime once operator and user paths are more productized.

Carrier and ecosystem convergence

Peer-native discovery, richer sharing, identity bridges, and wider ecosystem integration are planned convergence work, not current runtime claims.