[Bug]: [platform.matrix] Matrix gateway blocked on macOS arm64 with E2EE off — _is_satisfied() ignores the [encryption] extra, so a mautrix pin-drift forces an unneeded python-olm build

[mr-penner]

Bug: Matrix gateway unusable on macOS arm64 with E2EE off — lazy-dep pins mautrix[encryption]==0.21.0, forcing a python-olm build that isn't needed

Repo: NousResearch/hermes-agent
Version: Hermes Agent v0.18.2 (2026.7.7.2), commit 5e849942
Platform: macOS 15 (Apple Silicon / arm64), Python 3.11, install method pip
E2EE: off (MATRIX_E2EE_MODE unset → resolves to off)

Summary

On Apple Silicon, the Matrix gateway cannot be brought up even when E2EE is disabled, because the lazy-dependency group for platform.matrix unconditionally pins mautrix[encryption]==0.21.0. The [encryption] extra pulls python-olm, which has no macOS arm64 wheel and fails to build from sdist against clang (const-qualified 'other_pos'). Since E2EE is off, python-olm is never imported at runtime — the requirement is spurious for this configuration.

There are three distinct defects that combine to produce this:

Defect 1 — platform.matrix requires the encryption extra unconditionally

tools/lazy_deps.py:

"platform.matrix": (
    "mautrix[encryption]==0.21.0",   # <-- [encryption] pulls python-olm always
    "aiosqlite==0.22.1",
    "asyncpg==0.31.0",
    "aiohttp-socks==0.11.0",
    "aiohttp==3.14.1",
),

The runtime adapter only imports mautrix.crypto / olm behind if self._encryption: (plugins/platforms/matrix/adapter.py:1278), and _check_e2ee_deps() (adapter.py:489) already degrades gracefully when olm is absent. So plain mautrix is sufficient with E2EE off — but the lazy installer never lets you get there.

Defect 2 — _is_satisfied() never actually checks python-olm, only the bare mautrix version

tools/lazy_deps.py:509 _is_satisfied("mautrix[encryption]==0.21.0"):

• _pkg_name_from_spec() strips the extra → checks package mautrix only.
• The [encryption] extra (i.e. whether python-olm is present) is never verified.

Two consequences:

1. Over-eager reinstall on patch drift. With mautrix==0.21.1 installed and the pin at ==0.21.0, Version("0.21.1") in SpecifierSet("==0.21.0") is False, so the group is reported "missing" and a reinstall of mautrix[encryption]==0.21.0 is triggered — which is what invokes the olm build. The failure is thus gated on a version-pin mismatch, not on any real encryption requirement.
2. Under-checking. Because the satisfaction check ignores olm entirely, mautrix[encryption]==0.21.0 reports "satisfied" as soon as bare mautrix==0.21.0 exists, even with no olm installed. The [encryption] intent is simultaneously enforced at install time and unverified at check time.

Defect 3 — matrix_pkg in the setup wizard is cosmetic

plugins/platforms/matrix/adapter.py:4480:

matrix_pkg = "mautrix[encryption]" if want_e2ee else "mautrix"   # computed…
...
_lazy_ensure("platform.matrix", prompt=False)                    # …but ignored

matrix_pkg is only used for log/print strings and an ImportError fallback. The primary path calls _lazy_ensure("platform.matrix"), which uses the hardcoded LAZY_DEPS entry with [encryption] regardless of want_e2ee. So answering "no" to "Enable E2EE?" in hermes gateway setup still tries to install the encryption extra and still fails on olm.

Reproduction

1. Apple Silicon Mac, pip install of Hermes 0.18.2.
2. hermes gateway setup → Matrix, answer No to E2EE.
3. hermes gateway run.

Observed (logs/errors.log):

WARNING matrix_platform.adapter: Matrix: required packages not installed (mautrix[encryption]==0.21.0).
ERROR gateway.run: Platform 'matrix' is registered but adapter creation failed
WARNING gateway.run: No adapter available for matrix

Impact

Matrix is effectively unavailable on macOS arm64 for the common E2EE-off case. The docs/gating only exclude Matrix on Windows (_unsupported_feature_reason, lazy_deps.py:465); macOS hits the same olm-build wall with no gate and no non-E2EE escape hatch.

Workaround (verified working)

Install the pinned mautrix without the extra so every platform.matrix spec is satisfied and no olm build is attempted:

<venv>/bin/pip install 'mautrix==0.21.0'

After this, feature_missing('platform.matrix') is empty, hermes gateway run reports ✓ matrix connected / logged in as @…, and the gateway runs on plain mautrix with E2EE off. No compiler is invoked.

Related issues (not duplicates — different function / platform)

• lazy_deps: shared aiohttp pin marks never-enabled backends active; matrix refresh then fails on Windows (python-olm needs make) #58458 (open, Windows) — also in lazy_deps.py + platform.matrix, but its root cause is
  active_features() false-positiving on the shared aiohttp==3.14.1 pin, and its build failure is
  the Windows make/olm path. This report is a different code path (_is_satisfied() ignoring the
  [encryption] extra → a mautrix version-pin drift forces a reinstall) on macOS, for a user who
  has enabled Matrix and wants it E2EE-off. The two share a theme (lazy-dep group pulls olm when it
  shouldn't) and a fix would likely be coordinated.
• [platform.matrix] Lazy backend refresh fails on Windows: python-olm source build incompatible with CMake 4.x #58063 (open, Windows) — python-olm source build vs CMake 4.x on Windows. Same olm-build wall,
  different trigger/platform; the E2EE-off cases here would sidestep olm entirely under fix Terminal tool #1 below.
• Matrix/E2EE extra does not resolve cleanly on macOS/Python 3.11 #6931 (closed, implemented-on-main) — the old matrix-nio[e2e] packaging/h11 conflict on
  macOS. Superseded by the current mautrix-based stack; listed only to pre-empt "isn't this Matrix/E2EE extra does not resolve cleanly on macOS/Python 3.11 #6931?".

Suggested fixes (any of)

1. Make encryption conditional. Split the group: platform.matrix → mautrix==0.21.0 + aiosqlite/asyncpg/aiohttp-socks/aiohttp; add platform.matrix.e2ee → mautrix[encryption]==0.21.0 (i.e. python-olm). Only ensure() the e2ee group when the resolved E2EE mode is optional/required. This matches the intent already encoded by want_e2ee / matrix_pkg.
2. Fix Defect 3 by routing the wizard through the E2EE-aware group (or actually using matrix_pkg) so "no E2EE" never pulls olm.
3. Relax the pin from ==0.21.0 to e.g. >=0.21,<0.22 so a patch bump (0.21.1) doesn't force a reinstall — mitigates Defect 2's over-eager path.
4. Optionally, have _is_satisfied() verify the [extras] too (check python-olm presence when the spec carries [encryption]), so the check matches what install enforces.

[mrojas54]

Independent confirmation on macOS (Apple clang 17.0.0 / clang-1700.6.4.2, Python 3.11.11, hermes checkout 7acaff5ef), reached via the #58458 path (backend never enabled, false-activated by the shared aiohttp pin) — the olm build failure is byte-identical to this report. Adding some evidence that the python-olm build wall is permanent, which affects which of the suggested fixes are viable:

1. It's a genuine upstream libolm bug, not packaging corruption. The python-olm-3.2.16 sdist's SHA256 matches PyPI's published digest (a1c47fce…43c9), and the bundled libolm/include/olm/list.hh is identical to the upstream 3.2.16 tag at gitlab.matrix.org. List::operator= reads:

T * const other_pos = other._data;   // const pointer — transposed const
while (other_pos != other._end) {
    *this_pos = *other;              // also wrong: should be *other_pos
    ++this_pos;
    ++other_pos;                     // ← the diagnosed error
}

It shipped for years because member functions of class templates are only type-checked on instantiation; Apple clang 17 now rejects it, older toolchains (which built the manylinux wheels) never looked.

2. No version pin escapes it. python-olm==3.2.15 fails with the identical list.hh:106 error.

3. Installing cmake/gmake does not help. The error is a hard error, not -Werror promotion: compiling src/account.cpp directly with -Werror removed fails under both -std=c++11 and -std=c++17. All three olm_build.py paths (cmake → gmake → make) compile the same translation unit, so they all hit the same wall.

4. No upstream fix is coming. libolm is archived/deprecated (matrix.org moved to vodozemac); 3.2.16 is the final release on PyPI.

5. The fix is two transposed tokens, verified. With T const * other_pos (line 102) and *this_pos = *other_pos; (line 104), account.cpp compiles clean under -Wall -Werror -std=c++11 with Apple clang 17 — relevant only if hermes ever wants to vendor/patch python-olm rather than gate the extra.

Net: the [encryption] extra is uninstallable on any current-Xcode Mac forever, so conditional-extra gating (suggested fix 1) or a darwin _unsupported_feature_reason carve-out is the right direction — waiting out upstream isn't an option.

Also confirming the workaround: pip install 'mautrix==0.21.0' 'aiosqlite==0.22.1' 'asyncpg==0.31.0' 'aiohttp-socks==0.11.0' (all wheels, no compiler) makes feature_missing('platform.matrix') empty and the updater reports the backend current.

[mkoby]

This also prevents Matrix E2EE for MacOS on arm64 because the same dependency stops the mautrix[encryption] from getting built.

As stated previously in another comment, libolm is deprecated so there needs to be another route for building E2EE stuff for Matrix. I'm currently having to run the Matrix connection without encryption until this gets resolved.