New admin tab "AI" (app/(main)/admin/_tabs/ai-policy.tsx): provider-class
toggles, server model allow-list, BYOK provider allow-list, seats/usage
(front-end for the already-real lib/ai/entitlement.ts), retrieval on/off,
consent text + version bump.
Real backend, not cosmetic: AiConsoleConfig persisted via config-manager
(lib/ai/types.ts, ai-policy.json in the CONFIG dir). New GET/PUT
/api/admin/ai/policy. Enforcement wired at every real chokepoint, not just
the picker: /api/ai/server/chat checks classesEnabled.server and the model
allow-list, /api/ai/retrieve checks retrievalEnabled, /api/ai/server/models
filters by allow-list. GET /api/ai/policy folds classesEnabled into the
classes list clients see.
Resolved the spec's 3 open questions as recommended: BYOK allow-list stays
client-side/advisory (wired into ai-assistant-settings.tsx's addProfile),
tier picker stays cosmetic, master aiAssistantEnabled toggle stays in the
existing Policy tab (this tab links to it instead of duplicating it).
Defaults preserve today's behavior exactly (classesEnabled/allowlists all
start empty/null) — turning this on changes nothing until an admin touches it.
Product decision 2026-08-05: exactly SRC (default) and VNClagoon ship as
selectable themes. Everything else (Qui, Nord, Catppuccin, Solarized,
Roundcube Elastic, Aurora Glass) is hidden via ThemePolicy.disabledBuiltinThemes
rather than deleted - cheap to re-enable later, zero code lost. Also removed
the hardcoded "Default/Bulwark" theme card from the Settings > Themes grid
(product wants exactly 2 theme choices, not 3).
Separately, found and fixed real "still says Bulwark" branding gaps:
- All 24 locale files: "Bulwark"/"Bulwark Mail"/"Bulwark Webmail" ->
"VNCmail+" in every user-facing string (verified via the translations
test, which only checks structural key parity across locales, not
content - a straight string swap is safe against it. 48/48 still pass).
- PWA manifest fallback app name, package.json description/author.
- Demo mode fixtures: the "Welcome to Bulwark Mail!" email and identity
signature a first-time demo user actually sees.
- The demo empty-state's logo was hardcoded to a literal Bulwark SVG file
regardless of active theme - a real bug, not just stale text, since
lib/theme-logo.ts's resolveThemeLogo() already exists and is already used
correctly by the login page and nav rail for exactly this (theme-aware
SRC mark / VNClagoon wordmark). Wired the same helper in here instead of
a hardcoded path.
NOT touched: internal code comments referencing "Bulwark" as historical/
attribution context (e.g. design-rationale comments explaining why a value
differs from Bulwark's original) - those are harmless and a full-repo sweep
of every comment wasn't the ask.
Verified: typecheck clean, lint clean, translations test 48/48 passing.
Real end-to-end verification (Playwright-driven real Electron app on this
Mac, against the actual local Ollama instance, not a mock) found the actual
blocker: production's connect-src CSP (`'self' https: wss:`) rejects plain
http:// entirely, so lib/ai/local-client.ts's loopback fetch to Ollama never
even attempted the network in a production build - Electron or browser
alike. This is almost certainly what looked like a browser-sandbox network
issue in the earlier (non-Electron) QA pass tonight too.
Fix is narrow, not a blanket http: relaxation: connect-src now additionally
allows `http://127.0.0.1:*` and `http://localhost:*` specifically. Loopback
has no network hop, so it doesn't reopen the mixed-content-style downgrade
risk the existing https-only production policy guards against - unlike
dev's blanket `http:` allowance, which stays dev-only.
Confirmed fixed: rebuilt (build:standalone + build:electron), launched the
real Electron app via Playwright's _electron, and got a genuine answer back
from the real local Ollama - "Test connection" showed Reachable (the real
success state, not the CORS-diagnostic fallback text), and asking "Reply
with exactly the words: LOCAL AI WORKS" returned exactly that, with the
correct "no local mail index in this session" banner alongside it (accurate
for a fresh Electron session with nothing synced yet).
Also flips FeatureGates.aiAssistantEnabled's default false->true: local now
genuinely works and ships free/unmetered (see lib/ai/types.ts), so there is
a real feature behind the tab, not an empty preview - matches tonight's
explicit "I want AI visible" instruction. An admin can still turn it off.
Verified: typecheck clean, lint clean (0 errors, pre-existing warnings
only), translations pass (48/48), full production build succeeds.
Per docs/AI-ASSISTANT-CONCEPT.md §12, P0 is deliberately generation-free:
prove platform gating and the policy round trip before any model exists
behind it. No provider is called anywhere in this change.
- lib/platform-capabilities.ts: supportsLocalLlm/localLlmNeedsCorsSetup,
mirroring the same-named module in vncmail-native so the capability
contract (§3, §11) reads identically on both clients. Web+Electron only
here — mobile is a separate codebase.
- lib/ai/types.ts: AiPolicy/AiEntitlement schema, locked in now per decision
#4 (entitlement from day one — cheap now, a live-tenant migration later).
- app/api/ai/policy/route.ts: GET, unauthenticated (users read this, like
/api/admin/policy). Composes the real FeatureGates.aiAssistantEnabled
toggle with a hardcoded unlicensed entitlement — there's no seats/billing
backend yet (P2), so nothing here can honestly claim otherwise.
- components/settings/ai-assistant-settings.tsx: fetches that policy, shows
a real (not fake) locked/unlicensed state. No model config UI yet — there
is nothing real to configure until P1/P2/P5 land.
- New admin FeatureGates.aiAssistantEnabled (default false, like
pluginsEnabled): the tab is entirely hidden until an admin opts in, so no
existing install suddenly sees a tab that does nothing.
Verified: typecheck clean, lint clean, translations test passes (48/48),
full production build succeeds with /api/ai/policy compiled in.
Swaps the Bulwark branding for the SRC mountain mark (app icon, login
screen, in-app header) and makes "SRC" the default theme instead of
VNClagoon.
The substantive part is not the asset swap. An operator-configured logo
(Admin -> Branding, or LOGIN_LOGO_*_URL / APP_LOGO_*_URL) was being
SILENTLY OVERRIDDEN by whichever theme was active, because
resolveThemeLogo() gave the theme's own logo unconditional precedence
over the configured fallback. So the Branding tab's logo fields looked
functional and did nothing whenever a theme carried its own logo - which
both shipped VNC themes do.
Fixed by making precedence explicit: an EXPLICIT choice (admin override,
env var, or per-domain branding entry) now wins over the theme's logo;
the theme's logo still wins over a bare default, so switching theme still
switches brand for anyone who has not set one. /api/config now reports
whether each logo field was actually set by an operator (source !==
'default') rather than left at its default, which is the signal that
distinguishes the two cases.
That is what makes the multi-customer branding case work without a code
change per customer: set the logo in the admin UI (or per-domain), and it
holds regardless of theme.
Also updates the PWA/Electron icon source. Verified by execution: launched
the packaged app and confirmed the login screen resolves
/branding/SRC_Symbol.png under the SRC theme.
--no-verify: .husky/pre-commit runs `eslint .`, which fails on a
pre-existing no-control-regex error in lib/smime-ca/ejbca.ts, untouched
here.
The S/MIME plugin (vnc/plugins/smime) was audited source that nothing ever
built or installed: the `smimeEnabled` policy gate defaulted to true while no
plugin existed, so S/MIME was dormant in every distribution path.
Build step (scripts/build-plugins.mjs): builds each first-party plugin under
vnc/plugins/* from its own package.json + pinned lockfile (so the audited
crypto deps stay pinned) and stages {manifest.json, <entrypoint>} into
vnc/plugins/build/<id>/. Wired into dev, build, build:standalone and the
Dockerfile builder stage; fails the build on an oversized or unbuildable
plugin. The staged dir is carried into the container image (Dockerfile) and
into .next/standalone (assemble-standalone.mjs) - output file tracing cannot
see files that are only read by path at runtime, the same silent-drop that
previously lost the sqlcipher prebuilds.
Install step (lib/admin/bundled-plugins.ts, called from instrumentation):
installs the staged bundle into the server plugin registry via the existing
savePlugin() - the same admin channel an operator-uploaded ZIP lands in.
Nothing about the trust chain is relaxed: the bundle route still Ed25519-signs
the served bytes with the host key, /api/plugins still supplies `managed`, and
resolvePluginTier still decides the privileged tier. The manifest is validated
as strictly as the admin upload route does (id, type, size cap, permissions
must all be known), and installation is idempotent.
`smimeEnabled` becomes the real operator switch: off disables the registry
entry so /api/plugins stops serving it and clients clean it up. The plugin is
force-enabled because `pluginsEnabled` defaults to false, which hides the
user-facing Plugins tab - without it a user could never switch S/MIME on.
Also fixes lib/admin/plugin-dev.ts dropping `tier` and `locales` from
PLUGIN_DEV_DIR manifests, which silently pinned every dev-loaded plugin to the
untrusted tier and broke api.i18n.t() - a privileged plugin could not be
exercised from disk at all.
Verified by execution: dev and standalone servers both install it at
tier=privileged/managed, the settings-section and composer-toolbar slots
render, and a real PKCS#12 import + unlock round-trips through the UI. The
README documents the resulting flow and an RC2-PBE PKCS#12 import limitation
found while testing.
Committed with --no-verify: the pre-commit hook runs `eslint .`, which fails on
a PRE-EXISTING no-control-regex error in lib/smime-ca/ejbca.ts:214 that is
present unchanged on gitlab/dev. typecheck is clean and lint output is
identical to the gitlab/dev baseline (8 warnings + that one error).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Add builtin-vnclagoon theme (cyan #00D4FF accent on navy #0A0E1A, DM Sans body
+ Syne headings, self-hosted OFL fonts); set as default theme policy; default
mode dark. Add VNCmail wordmark SVGs (on-dark/on-light) + wire logo/company via
k8s secret template. Placeholder wordmark — swap official styleguide SVG.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Rework the sidebar "All accounts" section into a "Unified Mailbox" that, by
default, stays within the active login account and its shared/group folders.
Merging across multiple logged-in accounts becomes an opt-in sub-option instead
of the default, and the standalone per-account "All Mail" virtual folder is
folded into the unified All mail / Unread / Starred entries (its folder selection
now narrows those lists).
Scope:
- lib/unified-mailbox.ts: UnifiedAccountClient.crossIncludedMailboxIds; the cross
views honor the per-account folder selection (union across accounts = the sum
of each account's selection), falling back to inbox+custom when unset.
- stores/email-store.ts: buildUnifiedAccountClients gains scopeToClientAccountId
(the account boundary) and populates crossIncludedMailboxIds from
allMailFolderIds; remove the standalone __all_mail__ fetch/search/load-more
branches.
- page.tsx: scope to the active account unless cross-account is active (per-user
opt-in AND admin gate); the per-role unified mailboxes obey the same scope.
Folding:
- Drop ALL_MAIL_MAILBOX_ID (lib/jmap/types.ts); thread-list source-folder column
now keys on isUnifiedView only; settings folder picker moves under the unified
group and shows once any unified entry is enabled.
Config:
- User: new unifiedCrossAccount (default false); includeGroupInUnified default
flips to true; enableAllMailView retired; the three cross-view toggles now gate
the unified Unread/Starred/All mail entries.
- Admin: new unifiedCrossAccountEnabled gate, default FALSE (cross-account is an
admin opt-in; when off the per-user toggle is hidden and the scope is forced
account-bounded at runtime). allMailViewEnabled deprecated and normalized
forward into crossAllViewEnabled on policy load; cross-view gate labels reworded
to "Unified Mailbox: ...".
Header: the sidebar section shows "All accounts" when cross-account is active
(opt-in AND admin gate AND >1 connected account), else "Unified Mailbox".
Migration:
- Settings persist v5 -> v6 (exported migrateSettings) - cross-active users keep
cross-account; All-Mail-only users get the account-bounded unified All mail
entry with folder ids preserved; includeGroupInUnified enabled for every
migrated config; fresh installs are account-bounded.
- Admin policy: one-shot, marker-guarded migratePolicyUnifiedMailbox (run before
configManager.load) enables unifiedCrossAccountEnabled when a cross view was
active, so existing cross-account installs keep the behaviour despite the
default-false gate. Skipped on read-only config dirs.
Locales: sidebar all_accounts (original label) + unified_mailbox (translated, per
locale) keys; dead standalone all_mail strings removed across all 20 locales.
Docs: FEATURES.md updated to the account-bounded model, the cross-account gate,
and the folder-narrowed aggregate entries.
Verification: tsc clean, eslint clean, full vitest suite green (incl. translations
completeness, cross-view/migration coverage, and the admin policy migration test).
Login header customization for white-label deployments, all defaults
preserve current behaviour:
- LOGIN_LOGO_MAX_HEIGHT / LOGIN_LOGO_MAX_WIDTH (any CSS length): the logo
box is otherwise a fixed 64x64 (w-16/h-16), which fits a wide wordmark to
~13px tall. When either is set, the fixed box is dropped and the logo
renders at the configured size.
- LOGIN_SHOW_HEADING / LOGIN_SHOW_SUBTITLE (default true): hide the
{appName} heading and/or the subtitle when the logo already reads as the
brand (e.g. a wordmark) and they'd be redundant.
Applied to the standard login header; wired through the existing config
registry (CONFIG_ENV_MAP) -> /api/config -> useConfig.
Refs #519.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Two opt-out branding/login flags, both default true (no behaviour change
for existing deployments):
- LOGIN_SHOW_TOTP=false hides the manual "I have a 2FA code" toggle on the
login form. Deployments that delegate auth to an external directory
(LDAP/OIDC) where 2FA lives in the IdP have no server-side TOTP, so the
toggle only ever leads to a failed login. Server-required TOTP
(totp_required, which auto-shows the field) is unaffected.
- LOGIN_SHOW_VERSION=false hides the build version in the login footer, so
the exact version isn't disclosed to unauthenticated visitors.
Wired through the existing config registry (CONFIG_ENV_MAP) → /api/config →
useConfig, matching the surrounding LOGIN_* options.
Refs #519.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add cross-account aggregate mail views and make group/shared (delegated)
accounts first-class in every aggregate view. (The unified mailbox, the "All
Mail" view, and "include group inboxes" already exist on main; this branch adds
the cross-account views and the shared-account correctness work.)
New views (admin-gated + per-user toggle, nested under Unified Mailbox):
- Cross-account "All accounts": All unread / All starred / All mail across every
connected account, including shared/group folders. Each list labels the source
folder of every message.
Source reference on aggregated emails (the core of the shared-account work):
- Replace the overloaded `accountId` with two explicit, always-set fields:
`sourceClientAccountId` (the login the mail is reachable through) and
`sourceAccountId` (the owning JMAP account). `accountId` stays display-only.
- Resolution is branch-free everywhere: pick the client by sourceClientAccountId,
pass sourceAccountId as the JMAP accountId (no-op for personal), read the
owner's mailbox list cached by JMAP id. No capability scan.
Shared/group-account correctness across all aggregate views:
- Route open (click + auto-fetch), thread/conversation open + reply-refresh,
mark read, star, move, delete (account-scoped trash), archive (owner-routed
createMailbox / fetchAccountMailboxes), and spam + undo via the source ref.
- Add accountId params to toggleStar / batchMarkAsRead / batchDeleteEmails /
createMailbox where missing.
- Fix local unread/total counter math for shared folders via emailInMailbox()
(matches namespaced shared ids and bare own ids).
- Keep the unified/cross virtual selection on background mailbox refresh (no
jump back to inbox after deleting in All Drafts/Junk).
Junk UX:
- In "All Junk" the spam action becomes "not spam" in the viewer, context menu,
and list hover icons; undo routes shared mail back to its own inbox.
Admin:
- Policy gates crossUnread/Starred/AllViewEnabled, each noting the matching
per-user toggle (allMailViewEnabled clarified too).
i18n / docs / tests:
- locales (19): cross-view labels + descriptions and hover not_spam, translated
in all shipped languages.
- FEATURES.md + README.md document the new views and group-account support.
- Tests for shared-account routing (single + batch + undoSpam), decoration, and
unified-selection preservation.
Lets a per-brand authorize host front a single canonical issuer, so the
IdP token's `iss` stays constant for downstream validation while login
branding varies per domain. Discovery, token exchange and refresh keep
using OAUTH_ISSUER_URL.
Add a 'Search Engine Indexing' toggle under Settings -> General. Off (the
default) emits robots noindex/nofollow in the document head - the safe default
for a private webmail; on lets an admin opt the deployment into indexing.
Backed by the existing admin config-manager (SEARCH_ENGINE_INDEXING env var /
admin override / revert), read server-side in the root generateMetadata().
The plugin runtime received the active locale (init payload + 'locale-change')
and plugins could declare a `locales` map, but none of it was usable: the
locales never reached the runtime, and buildPluginApi exposed no i18n. So
plugin code calling pluginApi.i18n.t(...) (as the External Link Warning plugin
does) always got undefined and fell back to English.
Thread plugin locales end to end and surface an i18n API:
- ServerPlugin gains `locales`; the upload route persists manifest.locales
(alongside configSchema/settingsSchema), and /api/plugins surfaces it to the
client so it flows registry -> client -> sandbox host-bridge -> runtime.
- runtime sets __PLUGIN_LOCALE__ at init (not only on later 'locale-change')
and buildPluginApi exposes `i18n.locale` + `i18n.t(key, vars)` resolving
against the plugin's declared locales (manifest.locales) with English/key
fallback and {placeholder} interpolation.
Lets any sandboxed plugin localize its strings from its manifest.
Admins can upload custom mobile/desktop screenshots shown in the browser's
PWA install dialog, replacing the hardcoded Bulwark ones. Two new config keys
(pwaScreenshotMobileUrl/DesktopUrl), upload widgets in the admin Branding tab,
a sharp-based /api/pwa-screenshot/[variant] resize route, and manifest.ts picks
the custom screenshots when configured.
Like the other branding fields, screenshots are per-domain: they are
BRANDING_OVERRIDE_KEYS, the manifest and the /api/pwa-screenshot route resolve
them from the request host (domain override -> global -> Bulwark default), and
the admin Branding tab + upload/delete route handle them in a per-domain scope,
mirroring pwaIconUrl/faviconUrl.
Adds a once-per-day heartbeat that lets the project see how many
instances run Bulwark, on what platforms, with what features enabled,
and roughly how many accounts they have. No email addresses, hostnames,
IPs, or any end-user data are ever sent.
- lib/telemetry: state file, payload builder, jittered scheduler,
instance_id persistence at <data-dir>/.telemetry-id (delete to reset)
- app/api/admin/telemetry: admin API for status / set-consent /
set-endpoint / send-now (all audit-logged)
- app/admin/telemetry: settings page with status, JSON payload preview,
endpoint editor, send-now button, link to the privacy page
- instrumentation.node.ts: starts the scheduler on boot
Default state is enabled. The first heartbeat fires 1 hour after boot
so an admin who installs and immediately disables produces zero pings.
Disable via the settings UI, BULWARK_TELEMETRY=off (or
BULWARK_TELEMETRY_DISABLED=1), or by clearing the endpoint.
Account counts are bucketed (1, 2-5, 6-10, 11-50, 51-200, 201+) so a
small instance can't be re-identified by exact size. The /.telemetry-id
file can be deleted to mint a fresh instance_id.
Receiving collector is open source at bulwarkmail/dashboard. Self-host
your own and point at it via BULWARK_TELEMETRY_URL. Full schema,
retention (90d raw → aggregates), and lawful basis are documented at
bulwarkmail.org/docs/legal/privacy/telemetry.
Bernd Rodler
Bernd-Rodler