The Web Portal

Every SharpMUSH server serves a web portal from the same origin as the game. It is not an optional add-on or a separate deployment: the Blazor portal is baked into the server image, so if the game is running, the website is running.

This is where most administration happens. There is no mush.cnf to edit and no @config incantation to remember for the common cases — you change a setting in a form and it takes effect.

First run

A fresh install has no accounts. The first visitor to /setup claims the admin account and creates the God character, then the route closes.

Accounts and characters

SharpMUSH separates the account you log in with from the characters you play. One account can own several characters.

Page	What it is for
`/register`, `/login`	Account signup and login
`/characters`	The characters this account owns
`/characters/new`	Character creation
`/character/{name}`	A public character profile
`/account`, `/settings`	Account details, per-character settings, theme

Because the login is an account rather than a character, switching characters does not mean disconnecting and reconnecting, and a lost password is an email recovery rather than a staff ticket. Guest access upgrades into a real character without losing the session.

Playing in the browser

/play is a full terminal in the page — telnet-equivalent access with no MU* client installed. It connects over a WebSocket served by the connection server, and out-of-band data from the game drives the live side panes.

The terminal’s Server URI must point at the connection server’s /ws endpoint. On a deployment behind the supplied proxy config that is wss://<your-domain>/ws; see Run with Docker for why this is its own hostname and path.

Prompts

A prompt is the line a game shows while it waits for an answer: a reader’s bb: [n]ext [q]uit, or the question an @input session asks. On telnet it is simply the last line. In the browser it sits in its own row just above the input box, so it stays in view however much output arrives, and any links in it (made with cmdlink()) can be clicked or reached with Tab and Enter.

When you send a line, the prompt is copied into the output above what you typed, so a saved log reads the same as a telnet session. A prompt from an @input session stays in its row until the session ends, whether you finish it, cancel it, it times out, or you disconnect; then the row empties. A one-off prompt from prompt() or @prompt goes as soon as you send a line.

&CMD`ASK Greeter=$+ask:@input/start What is your name? (q to skip)=q,INPUT`ASK`SKIP,*,INPUT`ASK`ANSWER
&INPUT`ASK`ANSWER Greeter=@pemit %#=Hello, %0.; @input/cancel
&INPUT`ASK`SKIP Greeter=@pemit %#=Maybe later.

Output: after +ask, the row above the input box reads What is your name? (q to skip). Answer Alice and the output shows the question, then Alice, then Hello, Alice., and the row empties because INPUT`ASK`ANSWER ended the session. Answer q instead and the session ends on that line, INPUT`ASK`SKIP runs and says Maybe later., and the row empties the same way. After the prompt, @input/start takes pairs of a line and the attribute it runs. The first pair is required and ends the session, so a player always has a way out; * stands for any other line.

For anyone writing their own WebSocket client: the connection server marks a prompt frame as {"type":"markup","data":…,"prompt":true,"session":"<id>"}, and when an @input session ends it sends {"type":"prompt","clear":true,"session":"<id>"} naming the same id. Take the prompt down only when the clear names the prompt’s session, or names none (sent after a reconnect when no session is waiting). A one-off prompt has no session. A client that ignores these fields shows each prompt as an ordinary line.

For players

Wiki

/wiki — namespaced, categorised pages with full edit history and diffs. Approved characters and staff write and edit pages, a character’s own biography included; staff control who may edit what.

Mail

/mail — read and compose in-game @mail from the web.

Scenes

/scenes — browse logged scenes, and watch running ones at /scenes/active as poses land.

Help

/help — the server’s own helpfiles, searchable, with working cross-links.

Games can also publish Dynamic Applications at /apps/{slug} — forms such as chargen or job requests, defined by admins as a softcode schema rather than written as web code.

Softcode layouts also render as native portal structure: boxes become panels, fields become definition lists, columns wrap on narrow screens, and figures show real images. The same softcode still produces terminal art and accessible reading order. See Visual Layouts, Themes, and Images.

The admin panel

/admin is the staff dashboard. What a given staffer sees is governed by roles, not by a single wizard bit.

Configuration

/admin/config — the server’s configuration, grouped into categories and rendered as typed form fields, including array and dictionary values as editable lists.
/admin/config/restrictions — command and function restrictions.
/admin/config/sitelock — sitelock rules.
/admin/config/bannednames — disallowed character names.
/admin/config/import and /admin/database/import — bring a PennMUSH configuration and database across. This is a staged, one-way operation; use the migration runbook, not the upload form alone, to plan rehearsal, validation, cutover, and rollback.

People

/admin/players — the player list, with a detail view per player.
/admin/accounts and /admin/characters — the account and character sides of the same people.
/admin/moderation — the moderation queue.
/admin/roles — define what staff roles may do.
/admin/suggestions — player suggestions.

Content

/admin/wiki and /admin/wiki/assets — wiki administration and uploaded assets.
/admin/media — the image library.
/admin/profiles — character profile templates and fields.
/admin/layout — the portal’s own layout: which widgets appear on which pages, edited per scope in a layout editor.

Extensions

/admin/packages — installed softcode packages, plus browse, remotes, review and author views. See Softcode Packages.
/admin/applications — the Dynamic Applications published at /apps/{slug}.
/admin/server — server status and control.

The softcode editor

/softcode is a Monaco-based editor for attribute code, with multi-tab editing, syntax highlighting, hover help drawn from the helpfiles, and signature help for functions. It shares its analysis engine with the language server, so the diagnostics it shows are the real parser’s, not an approximation.

Next steps

Visual Layouts, Themes, and Images Design softcode displays that adapt across the portal, terminals, personal themes, and screen readers.

Migrate from PennMUSH Import through the portal as one step in a rehearsed, validated cutover.

Softcode Packages Install and upgrade global softcode from a repository.

Writing Plugins Add compiled C# commands, functions and services without forking the server.