Configuration

DM ships defaults for ordinary use, so most deployments set only the secrets and URLs below. Change a setting explicitly when your machine or deployment needs something else. The service reads its settings from the environment at start and refuses to start, naming the variable and the reason, when one is missing, malformed or unsafe; .env.example at the repository root lists every service setting with its default.

The dm command

DM records no telemetry.

Plain http URLs are accepted only for this machine (localhost, *.localhost, loopback addresses). Keep the state directory on a durable local disk: it holds the sign-ins and the outgoing queue. One relay serves every state directory of the operating-system user.

dm accounts --json shows the values in effect without signing in. Setting SILICON_DM_TEST or DM_TEST_APP_SECRET (test environments, retired) makes every networked command refuse with testing_environments_retired, so a home that still selects a test environment never reaches the live service.

Installing and updating

Silicon Apps installs and updates the command: silicon-apps install dm (development releases: silicon-apps install 'dm>dev'). DM never replaces its own executable. A running relay keeps serving after an update; the next dm command from the new version replaces an older relay, and queued requests survive. Rust programs manage silicon-dm-client as an ordinary dependency.

The service

Sign-in

Sign-in is Silicon Accounts only:

DM's sign-in setup at Silicon Accounts needs device_flow and public_client turned on for the command, and requires no account details (email and timezone are optional).

The server and the database

Plain http is accepted only for this machine.

Speech

Speech (voices, spoken messages, listening, transcription) goes through Deepgram from the service only; the key never reaches a client:

Plain http:// and ws:// Deepgram URLs are accepted only for this machine (tests and local stand-ins). The audio cache lives in PostgreSQL (speech_audio): it is derived data, never an upload, and any row can be evicted and rendered again. Voices and speech explains the choices.

The default voices (DM_VOICES unset):

Changing the catalog changes the default voice of accounts that never chose one (the default is an index into the list); a stored choice whose key is no longer listed falls back to the default. Spoken messages keep the voice they were sent in either way.

Delivery through Ting, presence and GIFs

Attachments are external links; no upload credentials are required by the service.

Bug report notifications

Set DM_POSTMARK_SERVER_TOKEN on the API service to send report notifications. The default DM_POSTMARK_EMAIL_URL is https://api.postmarkapp.com/email. Verify dm@teamofsilicons.com as a Postmark sender. Reports notify saketdev12@gmail.com, shubhastro2@gmail.com and bugs@teamofsilicons.com. Each account may submit DM_REPORTS_PER_HOUR new reports an hour (default 10, at most 100000); the next one is 429 rate_limited, whose Retry-After says when one fits again. Retries with the same idempotency key do not create another report.

The API returns 202 once the report is stored. Its worker retries Postmark failures with backoff, up to an hour between attempts. A process crash after Postmark accepts but before the transaction commits can deliver a duplicate notification; the report id identifies it. Outside production, without a Postmark token, reports are stored and marked simulated. No mail token is distributed in the client or the command.

Settings DM no longer reads

The settings of the sign-in and installer services DM used before Silicon Accounts and Silicon Apps, of the retired test environments and of telemetry are ignored. The service names any that are still set once at start, so an operator can remove them.

The website

The website's server (Next.js) reads these at request time; none of them reaches the browser:

The DM service never handles files: uploads are the website's job, done as DM acting for the Carbon at Silicon Briefcase with User verification proofs. The website's server passes each file's bytes through to Briefcase as they arrive and keeps none of them, so it needs no disk for uploads and its memory does not grow with a file's size; what sits in front of it must not limit or buffer the upload's body (the website's ingress). Production needs Briefcase to accept DM's proofs for its upload scopes (the Briefcase side). web/README.md in the repository covers running and deploying the website.

When uploads are off

When uploads cannot work, the website tells Carbons only that, in their words: GET /api/uploads/config answers {"enabled": false, "reason": …}, the + menu says the reason under its switched-off Upload a file and offers links and GIFs instead, a file pasted or dropped is answered with the same reason (a dropped link still attaches), /upload and ⌘⇧U say it too, and the microphone offers dictation only. Which setting is wrong is the operator's business, so the website's server writes it to its log, once per process, as a line that starts dm: Uploads are off:. What each one means:

Once uploads are on, a refusal by Silicon Accounts or Briefcase reaches the Carbon as the upload's own error (Errors). 503 briefcase_not_allowed means Briefcase does not list dm in its BRIEFCASE_PROOF_ISSUERS for a scope an upload needs: before anything is saved, or after the file is saved when only briefcase.link_access.update is missing (the Carbon then reads that the file was saved but its link could not be opened, and where the copy is). 503 uploads_misconfigured means the website's APP_ID or APP_SECRET is wrong. For these, and for every other failure that points at Briefcase or Silicon Accounts (a 5xx), the website's server logs one line with Briefcase's own code, never a file's name: upload failed: briefcase_not_allowed (proof_scope_missing). A cancel Briefcase refuses is logged as upload: Silicon Briefcase did not cancel an unfinished upload (…): that upload stays pending there until it expires, within a day.

Ting receiver origin on the website

TING_BROWSER_ORIGIN is optional. Set it to the exact Ting origin that issues its browser cookie, for example https://ting.teamofsilicons.com. It accepts HTTPS, or HTTP on loopback for local testing, with no path, credentials, query, fragment or wildcard. Leaving it unset keeps DM's HTTP recovery reader.

Also allow the website's exact PUBLIC_URL in Ting's browser-origin settings. The site adds only that Ting origin and its corresponding wss: origin to CSP; DM API calls and mutations stay on the website's own origin. Both sites must support Ting's SameSite cookie policy; a CORS allowlist alone cannot enable a cross-site cookie. The Carbon signs into Ting as the same account separately.