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
- Launch-on-login now starts the app with `--autostart`. With "Start
minimized" on (the default), that launch begins "settled", so neither
the page-load reveal nor the 8 s failsafe shows the window: it stays in
the tray with sync and notifications running. The tray, a second launch
or a deep link reveals it.
- The choice is a file in the app config dir (`start-minimized`), read
before the web client loads; `get_start_minimized` / `set_start_minimized`
back the new Settings switch.
- Existing registrations made without args are rewritten at startup
(re-enable), so current launch-on-login users get `--autostart` too.
- window-state no longer restores VISIBLE: it show()ed the window at
creation whenever it was last closed visible (or on first run), before
the page painted and even on a login start. Visibility is owned by the
page-load reveal + failsafe.
Verified on Linux under Xvfb with the debug build:
normal launch → shown; --autostart → hidden (past the failsafe) and still
running; --autostart with the setting off → shown; --autostart after
quitting visible → hidden; normal launch after quitting visible → shown;
a second launch reveals the hidden instance; an existing autostart entry
gets `--autostart` added.
Bump cinny (the Settings switch and the SW protocol guard).
Closes#3
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
`set_taskbar_progress(status, progress)` drives Tauri's window progress
bar (Windows taskbar button; launcher/dock elsewhere where supported):
none / normal (0-100) / indeterminate / error. Uses Tauri's built-in
ITaskbarList3 wrapper rather than more hand-written COM.
Bump cinny (the aggregation, throttling and error hold).
Closes#10
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
`set_tray_call_state({active, muted, deafened})` adds a small ringed dot
to the tray icon's bottom-left: green in a call, amber muted, red
deafened (deafened implies muted). The unread dot stays bottom-right.
The tooltip spells it out ("Lotus Chat — in call, muted · update ready").
Unread, call state and the pending update (#6) now live in one
`TrayIndicators` and re-render together, so none of them overwrites
another. The unread painter is generalised to `draw_dot(left, color)`.
Unit tests cover the tooltip text and dot placement.
Bump cinny to 25fa0f6e (the web half, plus the stale-state fix that
removed a "muted + deafened" flash at every join).
Closes#4
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
`set_tray_update_ready(version | null)` inserts a "Restart to update
(vX)" item at the top of the tray menu and sets the tooltip to "Lotus
Chat — update ready"; null removes both. The item only exists while an
update is pending. Clicking it reveals the window and emits
`lotus-tray-install-update`, and cinny runs its normal install flow
(progress, retries, failure toast). No icon dot: the unread dot already
uses that corner.
Bump cinny to 6edfe700 (the web half).
Closes#6
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
A friend's in-app update failed ten times ("error sending request for
url (…nsis.zip)") against a busy Gitea before the 11th worked.
- check_for_update / install_update retry transport errors (Reqwest,
Network, ReleaseNotFound) with 3 s / 8 s / 15 s backoff — four tries
per click. Signature or install errors fail at once, never masked.
- Every request gets a 600 s timeout; reqwest has none by default, so a
stalled connection could leave the UI on "installing" forever.
- Download and install are separate steps so a retry never re-installs.
- `lotus-update-progress` events (downloading %, retrying + wait,
installing) drive the new progress text in Settings.
- Errors are prefixed `check:` / `download:` / `install:` so the UI says
which step failed (it used to call a failed download "Update check
failed").
- Adds tokio (time feature only; already in the tree via tauri).
- Bump cinny to 568f218f (the matching UI).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
Toasts with a room id get a Mark as read action next to Send; it emits
`lotus-notification-mark-read {roomId}` without raising the window, and
cinny marks the room read through its existing markAsRead path. Invite
toasts (no room id) get neither button.
Bump cinny to 23649f12.
Closes#9
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
The updater launches the NSIS installer with /UPDATE and then exits the
app, but a WebView2 app takes a moment to die and the template only
sleeps 500 ms after its own kill before copying — so the copy raced the
old process ("Error opening file for writing: cinny.exe"), and Ignore
left the old exe in place.
A NSIS_HOOK_PREINSTALL now, on /UPDATE only, polls until cinny.exe can
really be opened for writing (every 250 ms, up to 15 s), then lets the
template carry on. Checked under Wine with a real running exe: without
the hook the copy fails; with it the installer waits out the remaining
~2.8 s and copies; a manual install (no /UPDATE) doesn't wait; a stuck
process hits the 15 s cap and falls through to the template's own
running-app handling.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
- Rich toasts set a WinRT Tag (hash of the web notification tag, since
room:thread tags exceed the 64-char limit) in a fixed Group, so a newer
toast for the same room/thread replaces the older one instead of
stacking; the replaced toast's keep-alive entry is dropped (#16).
- The bridge passes tag, roomId and threadId separately. The reply target
is the real room id (+ thread), never the coalescing tag, which was
`room:thread` for threads and `lotus-invites` for invites, so those
replies failed silently. Toasts with no room id (invites) get no reply
box (#17).
- New `get_focus_assist` command serves the latest Focus Assist poll so
the web hook can hydrate on mount; the setup-time first emit was lost
before the page listened (#15).
- Bump cinny to 3b6de2fd (the matching web-side hooks).
Closes#15, #16, #17
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
Lotus CIandClaude Opus 5.5