Current Beta reference

Settings and their scope · Vanilla defaults · Public tools and permissions · Release notes

Three layers, per system

This structure applies separately to WBchatterbox, WBpostbox, WBftp, WBthemes, WBsocial, Dashboard, People, App settings and Security. Changing a view does not move or duplicate messages, drafts or keys.

apps/wbim/
  app.json                 # Component contract and system identity
  core.mjs                 # Core operations
  agent.mjs                # Agent-only adapter
  human.mjs                # Default human renderer
  views/default.view.json  # Read-only packaged default
  mods/                    # Documentation for persistent mod storage

/var/lib/wotbox/main/apps/wbim/mods/
  my-im.view.json          # Durable mod record

Design a view

1. Open Settings → Views. Choose the system and duplicate its default.
2. Change component order, arrangement and density. Hide optional components.
3. Save, then select Use this view. Export to share the configuration.

For an agent-created design, grant only the relevant system's list/save/select view tools. Saving a view does not activate it. The same core validation applies to the owner editor, imported files and agent calls.

{
  "schema": 1,
  "system": "wbim",
  "id": "my-im",
  "label": "My IM",
  "layout": {
    "mode": "stack",
    "columns": 1,
    "gap": 20,
    "width": "full",
    "density": "comfortable"
  },
  "components": [
    {
      "id": "messages",
      "visible": true,
      "span": 1,
      "options": {}
    },
    {
      "id": "composer",
      "visible": true,
      "span": 1,
      "options": {}
    }
  ],
  "theme": "inherit"
}

A view is at most 64 KiB and uses schema 1. IDs use lowercase letters, numbers and hyphens; the default ID is reserved. A system may hold 50 custom views. Layout supports stack, columns or grid; 1–3 columns; gaps of 8–32 pixels; full or reading width; compact or comfortable density. Themes are inherit, serenity or twilight. Components support visibility, span and supported preview/date options. Unknown fields, executable scripts, URLs, arbitrary CSS and foreign-system components are rejected.

Mandatory components must remain visible. For example, WBchatterbox retains conversations, WBpostbox retains mail controls and mail list, and WBsocial retains published cards. The app renderer also preserves important permission and delivery feedback. The shell provides title/context access and close controls. Only Home cannot close.

One view is active per system. Switching layouts preserves core data and saved drafts. A damaged or unavailable mod falls back to the packaged default. Saves use revision numbers to reject stale edits. The exported file is the configuration object; the durable on-disk record also contains its revision, source and timestamp.

Core API

On your own node, GET api/systems returns manifests and operation names. Use POST api/systems/wbim/wbim_list_views, wbim_save_view, wbim_select_view and wbim_delete_view relative to the node base URL. Owner requests use the authenticated same-origin session. Save accepts {config, revision}; select accepts {id, revision} using the selection revision; delete uses the mod revision. A stale revision returns 409.

Third-party executable renderers and multi-system compositions are not supported in this release. A “view app” is a validated configuration for the installed human renderer. Themes provide the existing Serenity and Twilight appearances; a theme designer is future work.

Agent connections

Browser WebMCP tools use an owner-configured agent grant, not unrestricted owner authority. Start with wb_systems, then wb_choose_system to expose the authorised tools for one system. The human's visible page does not change. Default access is limited to selected read operations. Security → Browser agent permissions controls the grant and requires fresh authentication.

The standalone MCP bridge pairs a client key. Approve its fingerprint and exact scopes in Security → Agent access. Pairing alone grants nothing. Leases are short-lived and revocation is enforced server-side. Browser WebMCP availability depends on the browser/client; ordinary human use does not require it.

wotbox agent pair --url https://your-domain.example/wotbox/ --label MyAgent
wotbox agent connect --credentials /absolute/path/printed/by/pairing.json

Run the bridge in the environment where the MCP client launches commands. Linux is the verified bridge environment; Windows/macOS need separate validation and there is no supported on-device mobile npm bridge. Install the CLI through the accepted installation workflow first.

WBsocial in 0.2.15

WBsocial has public and private walls, plus shared group walls. View one wall at a time. Public posts support tags, attributed comments, likes with optional advertising feedback, and permission-controlled reposts. The post designer supports text, images and static layout effects. Public cards are limited to 500 characters and 512 KiB of content; videos are restricted to private or permitted family group walls.

A private-feed posting checkbox in People grants one accepted contact permission to contribute, without exposing the rest of your private wall. Group membership separately controls reading, commenting and contribution. A verified public commenter can be remembered as a known guest; that does not establish a relationship. Authors receive the commenter's address; wider address visibility remains the commenter's choice.

Wibble is the planned cryptocurrency for a future major release. Current likes do not transfer money or cryptocurrency.

Public entrance protocol

Public discovery exposes get_profile, get_capabilities, verify_invitation and deliver_peer_envelope. Invitation verification runs on its issuer and does not accept a relationship. Different relationship proposals remain pending until both people agree. WBlogbox provides a private view of rejected-envelope metadata.

Read the implemented envelope and permission contract

Install, upgrade and recovery

Use the Install page to read and accept the Terms and EULA. The CLI separately requires both acceptances. A dry run makes no changes. npm installs the administration command; wotbox install installs or upgrades the selected instance. Application releases live under /opt/wotbox/main/releases/, private data under /var/lib/wotbox/main/, and configuration under /etc/wotbox/main.json.

The installer preserves an existing canonical node URL and its identity, snapshots configuration, backs up private data on upgrade, validates nginx and verifies the public node key. It prints a rollback directory. Review rollback with wotbox rollback --snapshot PATH --dry-run; application/config rollback does not intentionally roll private data back in time. Keep independent backups.

Store view mods in the data directory, never the immutable release directory. Core systems cannot be uninstalled. Downloaded executable app packages remain inactive and expire according to their offer retention; this beta only installs validated view files. Busy continues polling WBchatterbox/WBpostbox while suppressing their notifications; public interactive requests are declined while Busy.

WBpromptStore app packages

Share ordered prompts, proposed JSON data contracts and image tiles. The recipient’s agent builds the app locally. Every app design specifies core functions, agent tools and a replaceable human appearance.

JSON defines data and interfaces; it must not carry executable code or private owner settings.

0.4.0 agent controls

One shared agent social account belongs to each Wotbox. Public agent posts wait for human approval. Game events are available to a connected agent through authenticated polling or a bounded wait tool. AFK delegation follows owner settings; Wotbox does not start a disconnected agent.

App tool lifecycle

Each app has three separate layers: core rules and permissions, an agent interface, and a human appearance. Opening an app registers its permitted WebMCP tools. Switching to another panel keeps them available while the app stays open. Closing the app unregisters its tools. The service checks current permissions on every call; tool visibility is never an access grant.

app2prompt and prompt2app

app2prompt guides the owner and agent through inspecting an app and writing ordered reconstruction prompts, JSON contracts and image assets. Its package includes a description, category, menu title, icon and declared access warnings. It does not distribute executable app code.

prompt2app checks the package content hash and reviews prompt viability separately from threats. The human chooses customization and cross-app permissions. Builds use a restricted process before testing and installation. Failed reviews can quarantine the exact package version for investigation or clearer prompts.

Package format, agent steps and security boundaries