User Settings

A Discord-style fullscreen settings dialog for message/communication preferences, kept deliberately separate from the global account/profile settings on the /user/settings route. The split follows the backend boundary: the dialog holds exactly what the userSettingsInMessage table persists; the route holds users-backed identity.

The two surfaces

The dialog is opened by the gear in MessageLeftSideBarStatusBar and mirrors the room settings pattern (SettingsType enum → list-item map → content map → Type/* panels) with its own parallel wrappers under Message/Model/User/Settings/. Unlike room settings there is no permission gating — every panel is self-scoped to the current user.

Both settings dialogs share three conventions: panels are lazy async components rendered inside <Suspense> with a shared MessageModelSettingsSkeleton fallback (shown on every tab switch); every settings mutation is optimistic (apply to the store immediately, mutate in the background, roll back + surface the error on failure — useMutation); and the sidebar section rail is StyledSlideIndicator stretched across all visible sections, pinned to the target while a click-scroll runs.

They also share the responsive shell: the sidebar drawer (MessageModelSettingsLeftSideBar) is permanent only on desktop and becomes a temporary overlay on smAndDown, opened by a mdi-menu hamburger the content header renders on mobile and closed on selection. The user dialog holds that open flag as isDrawerOpen on its dialog store; the room dialog threads it through its Dialog. See room settings for the diagram.

Sync by default, per-device by exception: preferences live in the DB and sync across devices; only hardware device IDs (mic/speaker/camera — a device chosen on one machine must not apply on another) and UI collapsibles stay localStorage.

Data model

userSettingsInMessage (packages/db-schema/src/schema/userSettingsInMessage.ts), 1:1 on userId (PK, cascade), under messageSchema:

Every column is communication-scoped — no account/profile/theme columns, reinforcing the surface split. Read returns the row or an unpersisted defaults object; the first update upserts (onConflictDoUpdate on userId).

Procedures

On the user router:

The client store (store/message/user/settings/index.ts) applies updates optimistically and reverts + alerts on failure. The read is one record for the whole session, so it goes through useCachedRead — every surface that raises the dialog asks for it, the concurrent asks join one request, and no write invalidates it because updateUserSettings stores the row it is answered with.

Navigation / scrollspy

The dialog uses a Discord-style two-level nav: a v-list-group per UserSettingsListItemMap category whose sections come from UserSettingsSectionMap (per-panel subsection enums whose values double as section title and DOM id).

• Scroll tracking is the repo-wide mechanism, not one written for this dialog: useVisibleSectionIds over the panel's section ids, bounded by the scroll container, and the StyledSlideIndicator rail stretched across every section currently on screen. What that guarantees, and why it is neither a scroll handler nor v-intersect, is section navigation.
• The panel header sits outside the scroll container (the shared shell's fixed #header slot above the flex-1 scroll div). That structural choice is what keeps the scrollspy free of offset math here: a section clipped above the scroll area is genuinely not visible, and useVGoTo lands a section title just below the header.

Key files

Notes

The Voice & Video panel's content and how each setting applies to live LiveKit calls is its own page: voice & video settings. The Appearance panel's Message Display density is covered by room UI, and per-participant call volume — which is not a column here — by per-user volume.