# Console The [console](https://console.dev.bitskiff.com) is where you create a project, mint the keys a host signs in with, and watch the sessions that project has open. It reads one project over the same routes the CLI calls. Every panel loads on its own, so one slow read greys one panel and never the page. ## Install the CLI Every `bitskiff` command on this page comes from `@bitskiff/cli`, installed from its tarball on the [downloads page](/docs/downloads/): `npm install` takes a URL as well as a name. ```sh npm i -g https://docs.dev.bitskiff.com/downloads/0.3.0/bitskiff-cli.tgz bitskiff config set endpoint https://api.dev.bitskiff.com bitskiff login ``` The [CLI page](/docs/packages/cli/) has the endpoint each environment answers on. ## First sign-in Enter your email address in the console, and we send you a sign-in link. Open it on the same device and you are signed in. On your first sign-in you accept the terms, and the console creates your **organization**. There are no passwords. Every link works once, it expires, and it has to be opened on the device that asked for it. A link only signs in the address it was sent to. Every project, key and session belongs to an organization. To work in a team's organization rather than your own, ask an owner or admin of it to add your address -- [`bitskiff members invite`](/docs/packages/cli/#bitskiff-members) from the CLI, or the console's [Members panel](#members-and-invitations) -- and open the link that arrives. Once you are in, the browser holds the sign-in and refreshes it, so a reload keeps you signed in. Signing out ends it and sends you back here. The CLI signs in with an organization key instead, which you make in the console's Keys panel. [Install the CLI](#install-the-cli) first. ## Organizations and projects The organization is a switcher in the header, because one person is often in several. A project sits under it and holds your keys, your limits and your sessions. Create a project with a name; the slug comes from the name and the id is the platform's. A project has no delete. From the CLI: `bitskiff projects list` and `bitskiff projects create`. ## Keys One table for the project's keys, each with its scope and its permissions. A publishable key goes in the page your clients open and is bounded by its origin allowlist. A secret key stays on your backend or on a device you control, and carries an explicit permission list. Create one and the console asks for the type, a label, an expiry and any limits this key should carry below the project's. A secret key adds one question, where the key will live, and fills the permissions in from the answer. The full key string appears once, on the page that created it, and is gone when you close it. `Revoke` asks which of two things happened. A key that may have leaked stops now, and the sessions it opened end with it. A key you are replacing stops now, and its sessions run out on their own. Rotation is a CLI verb: `bitskiff keys rotate `, beside `bitskiff keys list`, `bitskiff keys create` and `bitskiff keys revoke`. The organization's own keys are a second table, under Keys on the organization. That is the key `bitskiff login` takes; revoking it stops the CLI on the machines holding it and ends nothing that is running. ## Limits Every limit the project has, with its effective value, whether the project or a key set it, and the counter behind it. The `concurrentSessions` and `concurrentClients` rows show what is in use now; the metered rows show this period's consumption and when it rolls over. `Change` on a row takes a new value. Every row but one takes a count; the `tokensMaxTtl` row takes a [duration string](/docs/guides/limits/#durations). That row shows the length you set -- `1h`, and never `3600` -- and its field takes the same spelling back: a bare number is refused before it is sent. Lowering applies at once and never ends live work. A raise applies at once too, and binds the next open or join; see [Raises](/docs/guides/limits/#raises). From the CLI: `bitskiff limits` reads the same numbers. ## Live sessions The sessions this project has open, polled while you watch: the session, its state, its label, how many clients are connected, its capacity, and how long ago it opened. A row opens the session page. `Close` ends a session: every client is disconnected, the host is told, and the confirmation names how many clients that costs. For a host that reopens by itself, closing is not a stop: it opens another session about a minute later, with **a new join code**. The wait is the loop's `reopenAfterClose`, `1m` by default; see [Unattended hosts](/docs/guides/unattended-hosts/). The code on the host changes, and anyone holding the old one has to scan again. From the CLI: `bitskiff sessions list` and `bitskiff sessions close `. ## The session page Three parts. **The session** is its state, its label and metadata, when it opened, the config it was opened with (each duration as the host wrote it), and the deadlines counting down: host grace left, the idle limit, the longest this session may run, and when the join code next changes. **The roster** is one row per client: what it joined as, its number and its grants, its state and presence, the path its connection took, and the SDK it is running. A client's grants are what it may do inside this session -- `sendInput`, `receiveInput`, `broadcast`, `receiveBroadcast`, `manage` -- and the host is the one that sets them. **This session so far** is the meters: connected time, messages and bytes by channel and direction, joins attempted, accepted and refused, reconnects and grant changes. `Boot` on a roster row removes one client and gives its place back, and the session carries on. `Close session` confirms once and leaves you on a page that now names the reason the session ended. ## Usage The meters this project has recorded, by day or by month, over this month or last. There is no currency amount and no tier here. Usage appears the day after a session runs, because this panel reads the frozen daily and monthly totals rather than live counters. What is live is on Limits, and each panel says which it is. From the CLI: `bitskiff usage`. ## Settings The panel shows the project's join URL, whether end-to-end encryption is off or required, and restricted mode. It writes two of the three: the join URL and restricted mode. Encryption, and every other setting, changes from the CLI with `bitskiff settings set`; `bitskiff settings get` reads them all. The join URL is the page a client lands on after scanning a join code. A new project starts on our sample client page, and this field is where you point it at a page of your own. Warnings appear under it when the URL will not work: when it is `http`, when the sample client page is close to the bound past which new clients are turned away, or when no publishable key allows that origin. Restricted mode is a switch: publishable keys stop opening new sessions while it is on, a host opens with a secret key or a token or resumes what it had, and nothing running stops. Encryption is shown here and not written here. The project's setting holds every session the project opens; one host can also require encryption for itself with `e2ee: 'required'` on its constructor ([host package](/docs/packages/host/)), and the stricter of the two is what a session runs under. ## Webhooks One `https` URL per project, and the signing secret your receiver checks deliveries with. The secret comes back when you set the URL. To read it again, send the same URL to `PUT /v1/project/webhooks`: the value is derived from your project, so re-reading it hands you the secret your receiver already has and breaks nothing. The row in the console afterwards says only which signing key is in use. Set the URL here. A URL that is not `https`, carries credentials, or does not point somewhere public is refused here rather than dialed later. What the deliveries contain and how to verify one is the [Webhooks](/docs/guides/webhooks/) guide. ## Audit Every key, limit and webhook action on this project. Filter by action, by actor or by a time range, and page from there. An actor renders as the person or the key it was. Nothing here can be edited or deleted, from this panel or anywhere else. From the CLI: `bitskiff audit`. ## Members and invitations The organization's invitations: who was invited, to what, when the offer expires and what became of it. The panel lists offers rather than people. Invite someone with an email address and the roles they get when they accept. No row ever shows the link or the token -- that went to the inbox and exists nowhere else, which is why re-inviting mints a fresh one. From the CLI: `bitskiff members invite`, `bitskiff members list` and `bitskiff members revoke`. ## Next steps - [Credentials](/docs/guides/credentials/) - [Limits and capacity](/docs/guides/limits/) - [Webhooks](/docs/guides/webhooks/)