Step 2 mirrors the tokens, reads them back, then strips them from
localStorage in the same boot. The check stopped at the first "mirrored"
sighting, so a step-2 build could be reported as "before step 2" (n/a).
Wait up to 30 s for tokensIn === keychain; only call it n/a if it is still
mirrored-only after that.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
With Tauri 2.12 every app command was refused ("Command … not allowed by
ACL"): the app is served from http://localhost:44548 (tauri-plugin-
localhost), which Tauri treats as a remote origin, and since the
GHSA-7gmj-67g7-phm9 fix app commands need an explicit capability. The
Windows smoke test caught it (keychain, hotkeys, tray/taskbar/thumbbar,
token migration all failed).
build.rs now declares the 35 commands as an app manifest, and
capabilities/migrated.json (scoped to http://localhost:44548 only) grants
allow-<command> for each. The call page (http://127.0.0.1:44548) and any
remote frame still get no IPC. gen/schemas regenerated by tauri-build.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
The Tauri update brought wry 0.57, which uses webview2-com 0.39 / windows
0.62. Our Windows-only permission handler (lib.rs) still used webview2-com
0.38, so its handler type did not satisfy wry's ICoreWebView2 bound (E0277
on the Windows build).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
A full session in localStorage (pointed at an unreachable server) must
move to Credential Manager on boot, leaving a token-less shell, and the
app must still be signed in after a restart. Builds without cinny #105
step 2 report n/a. Cleans up the fake session and keychain entry.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
Without Explorer the tray icon, taskbar overlay badge and thumbnail toolbar
can't exist (E_FAIL / E_NOTIMPL). On a runner without an interactive
desktop only those calls may fail, and the app must still respond.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
Call each with what cinny sends (badge, unread, call state, thumbbar,
SMTC, taskbar progress, jump list, update-ready, flash), then reset;
every call must succeed and the app must still respond.
Refs #4, #7, #19
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
The windows runner can't show a hidden window or inject keys (no
interactive desktop: even a direct show() leaves it hidden). Check that
first; the deep link must still reach the page and un-minimise, but window
visibility and the global-hotkey round trip are n/a on such a runner.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
Hide the window (then minimise it), open matrix:r/lotus-smoke-*:example.org
through Windows (protocol handler -> second cinny.exe -> single-instance),
and require the window to come back and the URL to reach the page as
lotus-deeplink.
Refs #8, #19
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
After the smoke test, start the installed app, run the installer in
passive update mode (/P /UPDATE) while it runs, and only stop the app 3 s
later. Passes when the installer finishes by itself (no "Error opening
file for writing" dialog), exits 0, and has rewritten cinny.exe.
Refs #1, #19
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
The .deb and .pkg.tar.zst are not signed packages, and the in-app
update prompt has users install them by hand, so nothing checked them.
A new checksums job hashes the Linux downloads into SHA256SUMS.txt,
signs it with the updater's minisign key (tauri signer) and uploads
SHA256SUMS.txt + SHA256SUMS.txt.minisig. The README shows the
verify-then-install command.
Refs #36
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
On stock GNOME there is no StatusNotifier host, so choosing "Keep
running in the tray" hid the window with no icon to bring it back.
Expose whether org.kde.StatusNotifierWatcher has an owner on the
session bus (always true off Linux); cinny's dialog then defaults to
Quit and words the other option as "running in the background".
Refs #37
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
The README was upstream's: its download buttons and minisign key pointed
at cinnyapp releases, so following it installed upstream Cinny and
verified it against the wrong key. Point downloads at this repo's
releases (NSIS exe, .deb, pacman package, AppImage), publish Lotus'
updater key, and list the desktop features.
Fixes#35
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
The desktop CSP listed only known embed hosts in frame-src, so every
room widget that is not one of them (Jitsi, Etherpad, Grafana, bots)
showed a blank frame; the web deploy allows https: frames (#205).
Match it. Widget frames are sandboxed by cinny and same-origin widget
URLs are refused (isWidgetUrlSafe), so this does not widen what a
widget can do to the app.
Fixes#33
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
On CachyOS the in-app update failed with "Permission denied (os error 13)
at path /usr/bin/tauri_current_app…": the app was installed from the
Arch package, and Tauri's Linux updater can only replace an AppImage — for
anything else it tries to write next to the binary in /usr/bin.
- update_install_kind command: "in-app" on Windows and for an AppImage
($APPIMAGE set); on Linux package installs "pacman" (ID/ID_LIKE arch:
Arch, CachyOS, Manjaro, EndeavourOS…), "deb" (debian/ubuntu and
derivatives) or "manual". The web UI shows the matching update command.
- install_update refuses up front on a package install
("install: package-managed (…)") instead of downloading the whole
update and failing at the last step.
Tests: CachyOS/Arch → pacman; Ubuntu/Debian/Mint → deb; Fedora/unknown →
manual; AppImage and Windows → in-app.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
The example.com check could pass vacuously if the runner can't reach the
internet (goto failed silently, the mic request then came from the app's
own page). Serve a page on http://localhost:9333 instead, confirm the
navigation happened, and fail on builds that should refuse it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
The CI VM has no microphone (getUserMedia → NotFoundError). With
LOTUS_WEBVIEW2_DEBUG_PORT set the app also passes
--use-fake-device-for-media-stream; permission requests still go through
the real PermissionRequested handler.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
WebView2's WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS is ignored because the app
sets its browser arguments explicitly (seen on the runner: the WebView2
command line had only the app's arguments). The app now appends
--remote-debugging-port only when LOTUS_WEBVIEW2_DEBUG_PORT holds a valid
port (>= 1024); otherwise the arguments are exactly as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
Adds the same `statusPages` entry the web app uses, so the desktop app
shows the status banner for matrix.lotusguild.org too (Kuma status page
https://isitup.lotusguild.org/status/matrix). The desktop CSP already
allows https: connections; no other change is needed. Inert until the
bundled cinny includes the banner (cinny PR #255).
Tested on a Linux release build: with a local fake Kuma reporting calls
down, the desktop app shows "Voice calls are down right now. Messages
still work." and polls both endpoints; from inside the desktop app the
real Kuma page answers 200 on both (CSP and CORS allow it).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
Commands for the web client to keep a copy of the login tokens in the OS
keychain: secure_session_supported / _set / _get / _clear.
- Windows: Credential Manager via the keyring crate (3.6, windows-native),
entry "session" in service "Lotus Chat". Only the secrets are stored
(userId, deviceId, accessToken, refreshToken); the serialized value is
capped at 1200 chars (Windows' limit is 2560 bytes).
- Other platforms: supported = false and the other commands answer "not
supported on this platform" (Linux Secret Service can prompt to unlock a
wallet at startup; that needs its own testing). No new Linux dependency:
without a platform feature the crate only has its mock store.
- Keychain calls run on the blocking pool, off the main thread.
Step 1 is a mirror only (the web client still reads its session from
localStorage); see the cinny PR.
Tests: round trip + clear, clearing an empty keychain, incomplete and
oversized sessions rejected with nothing written, the JSON shape the web
client sends, a realistic OIDC session fits (keyring's mock store). Linux
release build: commands answer as designed and login is unaffected.
Windows: type-checked only.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
The bundled Element Call page ran on the app's own origin
(http://localhost:44548), so the call frame could read the app's storage
(login token) and DOM. Serve it from http://127.0.0.1:44548 instead: the
same local server and bundle, a different origin.
- The local server binds 127.0.0.1 explicitly. The app is still loaded as
http://localhost:44548 (its storage stays where it is; the engines try
127.0.0.1 for `localhost`). Binding the name `localhost` could pick ::1
only (Windows lists it first), and then 127.0.0.1 wouldn't answer.
- config.json: desktopCallOrigin = http://127.0.0.1:44548. cinny loads the
call page from there only when this is set (cinny #43 PR).
- CSP frame-src allows http://127.0.0.1:44548.
- Permissions (on top of #22): the call page's origin gets microphone/
camera/screen only; nothing else.
- The call page gets no IPC: the capability only matches
http://localhost:44548.
Tested (Linux release build): the server listens on 127.0.0.1:44548 and
the app loads as http://localhost:44548; the call page loads from
127.0.0.1 inside the app under its CSP; from that frame parent.localStorage
and parent.document are SecurityError, while a same-origin frame (the old
setup) reads the app's storage. The call itself was tested in a simulated
desktop (Chromium, the WebView2 engine) against a local Synapse + LiveKit;
see the cinny PR. Rust tests 17 passed; Windows code type-checked.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
Linux (WebKitGTK) allowed every permission request of every kind; Windows
(WebView2) auto-allowed mic/camera/notifications without checking who asked.
Now (src-tauri/src/webview_permissions.rs, unit-tested):
- Linux: microphone/camera/screen, device labels, notifications and location
are granted when the page in the window is the app
(http://localhost:44548; debug builds also the bundled/dev page).
Everything else is denied (WebKitGTK has no prompt of its own). WebKitGTK
doesn't say which frame asked; frames are gated earlier by the Permissions
Policy (cinny gives microphone/camera only to the same-origin call frame).
- Windows: the same grants (minus location, which keeps WebView2's prompt),
checked against the origin of the frame that asked (args.Uri()). Other
origins are denied mic/camera/notifications/location; other kinds keep
WebView2's default handling.
- Denials are logged ("webview: denied …").
Tested on Linux with a release build under Xvfb + PulseAudio (no WebDriver:
WebKit's automation mode bypasses the handler), before/after:
- app page: mic, device labels, location allowed (unchanged)
- same-origin call frame: mic allowed (unchanged)
- cross-origin frame without allow=: blocked before the handler (unchanged)
- foreign top-level page: mic, device labels, location now denied (were
allowed)
Real cinny build: boots, logs in, no denials. Windows code type-checked
(x86_64-pc-windows-gnu).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
The 4.12.343 workaround (WEBKIT_DISABLE_DMABUF_RENDERER=1 + GDK_BACKEND=x11)
made the app launch but pushed every frame through shared memory under
XWayland: noticeably laggy at 3840x2058. The reporter's WAYLAND_DEBUG trace
showed the real cause on native Wayland:
wl_display#1.error(wp_linux_drm_syncobj_surface_v1#51, 4,
"explicit sync is used, but no acquire point is set")
Gdk-Message: Error 71 (Protocol error) dispatching to Wayland display.
An explicit-sync bug, not a GBM format/modifier one. Their test matrix
(RTX 3070, driver 615.71.09, webkit2gtk 2.52.6, KDE Wayland):
- __NV_DISABLE_EXPLICIT_SYNC=1 alone: clean, GPU (DMA-BUF) renderer, smooth;
- WEBKIT_DISABLE_DMABUF_RENDERER=1 alone on Wayland: clean (no X11 needed);
- WEBKIT_DMABUF_RENDERER_DISABLE_GBM=1: same explicit-sync error on Wayland,
"Failed to import DMABuf" under XWayland;
- X11/XWayland with the DMA-BUF renderer: "Failed to create GBM buffer".
New defaults when the NVIDIA driver is loaded:
- native Wayland: __NV_DISABLE_EXPLICIT_SYNC=1, GPU renderer kept;
- X11 session or user-forced GDK_BACKEND=x11: WEBKIT_DISABLE_DMABUF_RENDERER=1;
- never force X11 any more;
- LOTUS_GPU_SAFE_MODE=1: opt-in shared-memory rendering on Wayland too;
- LOTUS_NO_GPU_WORKAROUNDS=1 / user-set values: untouched.
One stderr line says what was set. 9 unit tests.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
NVIDIA + Wayland (reported on CachyOS/KDE, driver 615.71, webkit2gtk
2.52.6): no window. GDK dies with "Error 71 (Protocol error) dispatching to
Wayland display"; forced onto XWayland, WebKit's DMA-BUF renderer then fails
with "Failed to create GBM buffer … Invalid argument". The reporter's
workaround, WEBKIT_DISABLE_DMABUF_RENDERER=1 GDK_BACKEND=x11, runs fine.
gpu_workarounds::apply(), first thing in main() (before GTK/WebKit init):
when the NVIDIA driver is loaded (/proc/driver/nvidia/version or
/sys/module/nvidia), set WEBKIT_DISABLE_DMABUF_RENDERER=1, and on a Wayland
session that has XWayland (DISPLAY set) also GDK_BACKEND=x11. Values the user
already set win; LOTUS_NO_GPU_WORKAROUNDS=1 turns it all off. Logs what it
set to stderr. Non-NVIDIA systems are untouched. Unit tests for the decision.
config.json: webAppUrl = https://chat.lotusguild.org, used by the web client
(cinny `calls-open-in-browser`) to send calls this WebKitGTK build can't make
to the web app in the browser.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
The web deploy serves a config.json kept on the server (not in git), which
is where the Giphy key lives. The desktop app bundles the repo's
config.json, whose gifApiKey is empty, so on desktop the GIF button never
appeared even with Settings → GIF Picker switched on.
scripts/sync-web-config.mjs copies an allow-list of deployment-only keys
(just gifApiKey) from https://chat.lotusguild.org/config.json into
cinny/config.json before the Windows and Linux builds. The key is public
already (served to every web visitor; Giphy keys are client keys). A fetch
failure is a warning, not a build failure.
Tested locally: sets the key, is a no-op on a second run, and skips cleanly
on a 404.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
Closing the window (OS close button or the custom title bar's ×) now
goes through one handler:
- in a call → always hide to the tray (a close must never drop a call);
- saved "tray" → hide; "quit" → exit the app;
- "ask" (the default until chosen) → emit `lotus-close-requested` so the
web client shows the one-time dialog; if the page isn't listening yet,
fall back to the tray.
The choice lives in `close-behavior` in the app config dir;
get_close_behavior / set_close_behavior / resolve_close_request back the
dialog and the Settings select.
Verified on Linux under Xvfb + openbox with real WM close requests
(wmctrl -c): tray → hidden, still running; quit → exits; unset with no
page listening → hidden; ask with the page listening → window stays,
page receives the event; quit during a call → hidden, still running.
Bump cinny (the dialog + Settings control).
Closes#5
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
Lotus CIandClaude Opus 5.5