Status: local-alpha dogfood path.
This path installs release binaries. It does not launch Vite, Cargo, or
tauri dev when MindCanary starts.
From the repository root:
./scripts/build-arch-package.sh
sudo pacman -U packaging/arch/mindcanary-0.1.6-1-x86_64.pkg.tar.zstThe package installs the desktop app at /usr/bin/mindcanary, the daemon and
native-message host under /usr/lib/mindcanary, and a matching Plasma desktop
entry and icon.
The package uses the same app.mindcanary.desktop identity for Tauri's GTK
application ID, its desktop entry, and its installed icons. This gives the
packaged window the MindCanary icon on the tested CachyOS Plasma/Wayland setup.
Install and enable the per-user daemon once:
/usr/lib/mindcanary/mindcanaryd \
--install-user-service \
--daemon-path /usr/lib/mindcanary/mindcanaryd \
--enable-nowCheck the installed service and KDE adapter without reading journal content:
mindcanaryctl health
mindcanaryctl capabilities
mindcanaryctl source-status
systemctl --user status mindcanaryd.serviceOn KDE Plasma/Wayland, os.active_idle_duration should report available.
Only complete aligned 15-minute buckets are stored, and each OS signal still
has to be explicitly enabled.
MindCanary asks the desktop Secret Service for its database key. KDE should
provide org.freedesktop.secrets through KWallet (ksecretd). If both
KWallet and GNOME Keyring are installed and GNOME Keyring claims that D-Bus
name first, the existing encrypted database can appear to have no key.
Check the active provider without printing any secret:
busctl --user status org.freedesktop.secretsFor a KDE-only session where GNOME Keyring is incorrectly winning, use a
per-user D-Bus activation override for /usr/bin/ksecretd and mask the
GNOME Keyring user service/socket. Back up the database and KWallet before
changing providers; never create a replacement key for an existing database.
The easiest path is the desktop app: open Sources and use Connect Firefox under Local sources. It installs or repairs the same user-level manifest through the packaged helper, so no terminal step is required. The equivalent manual command is:
/usr/lib/mindcanary/mindcanary-native-host \
--install-manifest \
--browser firefox \
--channel development \
--host-path /usr/lib/mindcanary/mindcanary-native-hostThe channel must match the add-on ID of the installed extension: the
development channel allowlists development@mindcanary.local, and a future
Mozilla-signed release build uses the release channel and its permanent
add-on ID instead.
The development add-on ID is development@mindcanary.local. Mozilla release
Firefox removes temporary add-ons on restart and requires Mozilla signatures
for persistent extensions. Use a Mozilla-signed XPI for ordinary Firefox, or
an isolated Developer Edition/Nightly/ESR dogfood profile with
xpinstall.signatures.required=false for the unsigned development XPI.
Build that XPI with:
./scripts/build-firefox-development-xpi.shThe result is target/firefox/mindcanary-development.xpi.
The CachyOS dogfood workstation keeps the unsigned add-on isolated in Firefox
Developer Edition's mindcanary-dogfood profile. Its XPI is installed as
extensions/development@mindcanary.local.xpi, and the profile's user.js
contains only these development-install preferences:
user_pref("xpinstall.signatures.required", false);
user_pref("extensions.autoDisableScopes", 0);Launch it from the application menu as Firefox Developer Edition — MindCanary. The ordinary Firefox release profile is left untouched. Browser aggregates are collected only while this dedicated Firefox instance is open; after rebuilding the XPI, close that instance before replacing its installed XPI and then restart it.
Firefox and Chrome profiles can collect concurrently. Each profile appears in Sources with independent signal settings; overlapping active/idle duration is deduplicated per aligned period. Give each connection a local label you recognize; labels never leave the device.
To follow several Firefox profiles, install the extension once per profile:
run firefox -P to pick the profile, open the MindCanary XPI with that
instance, and repeat for the next profile. The native-host manifest is shared,
so no extra terminal steps are needed after the first profile. History charts
and daily summaries always show all connected profiles combined.