Apps

App Forge

App Forge creates, saves, previews, iterates, and publishes sandboxed browser tools from a connected wallet.

Apps Overview

Apps are editable browser tools generated inside Nexus. They are useful for dashboards, trackers, scanners, research workspaces, calculators, command centers, and repeatable workflows that should stay available after the first chat response.

Build

Describe the tool or dashboard. Forge creates a browser-safe manifest with separate index.html, styles.css, and script.js files.

Iterate

Open an app in the Forge workspace and ask for targeted changes without rebuilding unrelated behavior.

Publish

Save a slugged app route under /apps, then choose whether that published link is public or private.

Storage

Workspace storage

Forge saves app workspaces server-side when the Forge store is configured. Each workspace is tied to the owner wallet and includes the app manifest, files, metadata, activity log, and versions.

Local fallback

If server app storage is unavailable, Nexus can still show legacy local browser apps. Local fallback is for continuity, not the source of truth for published routes.

Deletion behavior

Deleting a Forge app removes the owner workspace, versions, and linked published slug from server storage when the server store is reachable. If only a local fallback copy exists, deletion only affects that browser copy.

Publishing

Slug route

A published app is available at /apps/{slug}. The slug is owner-controlled unless another wallet already owns it.

Public

Public apps can appear in the Forge public gallery and can be opened by other users from the published route.

Private

Private apps keep the slug blocked from other users. Only the owner wallet or owner-admin access can load the route.

Publishing stores the current app manifest in the published-app table. Re-publishing the same app updates the route, visibility, and manifest without needing a new project.

Data Bridge

Base token and wallet analysisLiquidity and pool market dataPulse market discoveryGenerated app data bridgeGitHub, web search, public JSON, and API discovery when configured

Generated apps should use window.mythosQuery(type, target, params) through the sandbox bridge. Direct browser fetches, API keys in generated code, and fabricated live metrics are not part of the Forge contract.

Quality Standards

What a good Forge app includes

A workflow-matched layout such as command center, split inspector, table and drawer, board, timeline, simulator, or editor canvas.
Useful default content, clear loading and error states, and at least three meaningful interactions.
Real source and last-updated metadata for live-data apps.
Working add, save, delete, filter, tab, drawer, modal, navigation, and quick-add controls where shown.
Professional typography, spacing, responsive behavior, and a subject-specific visual idea instead of generic card grids.

What Forge should avoid

Unknown or zero metrics shown as if they are real facts.
Direct fetches, external scripts, CDN dependencies, inline event handlers, and form actions.
Dead buttons, gray-only charts, raw [object Object] text, broken same-page navigation, or unhandled submit forms.
Hard-coded token, market, GitHub, Polymarket, or API data when a Mythos bridge exists.
One-off landing pages when the user asked for a useful tool, tracker, scanner, or dashboard.

Safety Model

Apps run in an isolated iframe. External scripts, unsafe browser APIs, cookies, service workers, private network targets, form navigation, and unapproved network access are blocked. The sandbox provides controlled bridge calls for live data and a hardened published-app runner for shared routes.