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

The first visitor to /setup claims the admin account, which is made in advance and linked to God (#1). The setup wizard then offers to import a PennMUSH database, sets the HTTP and event handler objects, and lets the admin choose the bundled packages. It stays open until the admin finishes it.

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, with a password, a passkey or a sign-in service
`/characters`	The characters this account owns
`/characters/new`	Character creation
`/character/{name}`	A public character profile
`/account`, `/settings`	Account details, passkeys and linked sign-in services, characters, theme (`/settings/theme`), notifications

Because the login is an account rather than a character, switching characters does not mean disconnecting and reconnecting. Staff reset a lost password from /admin/accounts. 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 The browser terminal address for why this path goes to the connection server and not the game server.

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. On a phone, and for the schedule in a calendar app, see Scenes on a Phone. Scenes are part of the Scene System, a bundled application a new game has unless staff remove it.

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 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. The pages are grouped as the portal’s sidebar groups them.

Build

/softcode — edit the attributes on objects you control, and try code in a console. See The softcode editor.
/admin/snapshots — capture a recovery point for an object, and restore fields from it.
/admin/jobs — run an attribute on a schedule, as your character.
/admin/diagnostics — queued and running work, and why recent work failed.

People

/admin/accounts — reset passwords, and disable, close or delete web accounts.
/admin/characters — find any character by name, account, flag or whether they are online, with a detail view for each at /admin/characters/<number>.
/admin/guests — the characters handed out to visitors who connect as a guest.
/admin/activity — when people play, who is drifting away, and which rooms are used.
/admin/roles — create roles, decide what each one allows, and assign them.

Moderation

/admin/moderation — warn, boot, ban or unlink a character, with a reason.
/admin/audit — who changed what, in the portal and in the game.

Content

/admin/wiki — publish, protect, file and bulk-edit wiki pages.
/admin/media — the image library, where staff lock a file to a permission.
/admin/suggestions — the word lists that suggest a fix for a mistyped help topic or function name.
/admin/messages — the connect screen, the messages of the day and the other texts a connection is shown.
/admin/scenes/types — how each kind of scene line reads in the portal. Listed only while the Scene System is installed.

Portal

/admin/applications — the Dynamic Applications published at /apps/{slug}.
/admin/layout — the portal’s own layout: which widgets appear on which pages, edited per scope in a layout editor.
/admin/themes — the portal’s colour themes, and which one players get. See Portal Themes.
/admin/packages — installed softcode packages, plus browse, remotes, review and author views. See Softcode Packages.
/admin/profiles — check and reset the softcode that serves character profiles.

Server

/admin/server — uptime, connections, queue, storage and backups, read live.
/admin/config — the server’s configuration, grouped into categories and rendered as typed form fields, including array and dictionary values as editable lists. Its sub-pages are /admin/config/restrictions (command and function restrictions), /admin/config/sitelock, /admin/config/bannednames (disallowed character names), /admin/config/secrets, /admin/config/mssp, /admin/config/asciitranslations and /admin/config/import.
/admin/import — bring a PennMUSH, RhostMUSH or TinyMUX database into this game. With /admin/config/import this is a staged, one-way operation; use the migration runbook, not the upload form alone, to plan rehearsal, validation, cutover, and rollback.
/admin/discord — the bot, linked channels, role mappings and linked members. Listed only while the Discord application is installed.

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