[classic confinement request] voxtral-linux

store-requests classic-confinement
1

  • name: voxtral-linux

  • description: Voxtral Linux is a desktop and IBus voice-input client for Mistral Voxtral Realtime. The primary purpose of the snap is to provide an IBus input method engine that can integrate with the host desktop input stack so dictated text can be committed directly into arbitrary applications. The standalone window is mainly for configuration and testing.

  • snapcraft: https://gitlab.com/lesewolf/voxtral-stt-linux/-/blob/main/snap/snapcraft.yaml

  • upstream: https://gitlab.com/lesewolf/voxtral-stt-linux

  • upstream-relation: Snap publisher working directly on the upstream project and repository

  • supported-category: none of the currently listed supported categories exactly match this use case; requesting review under the criterion that the snap requires access to resources and integration points not currently supported by snapd under strict confinement

  • reasoning: The snap’s core functionality is not the standalone desktop window but the IBus engine integration with the host desktop session. Under the current implementation, the application must integrate with the host IBus infrastructure, expose an engine definition to the host, and be usable as an actual system input method for text entry across arbitrary host applications. In practice this requires interaction with host session resources that go beyond what the existing strict confinement interfaces provide.

    More specifically:

    1. The snap needs to provide an IBus engine that the host IBus framework can discover and launch as part of the user’s desktop input-method workflow.
    2. The current application writes and registers IBus component metadata for the host environment and relies on the host IBus service and desktop input-source configuration.
    3. The actual value of the application is committing dictated text through IBus into arbitrary host applications, not only running an isolated GUI window inside the sandbox.
    4. Existing strict confinement interfaces are suitable for many desktop applications, but they do not appear sufficient for this host-level input-method integration model.
    5. A standalone strictly confined version would not represent the primary product, because the desktop UI is mainly a setup and testing surface while the intended day-to-day use is via the IBus engine.

    I understand that classic confinement is generally preferred over strict confinement. However, for this snap the required IBus host integration is the core feature, and I have not found a way to make that work under strict confinement with the currently available interfaces.

I understand that strict confinement is generally preferred over classic.

I’ve tried the existing interfaces to make the snap to work under strict confinement.

2

IBus access (as well as the full accessibility stack) should be available to strict snaps via the desktop-legacy interface, you should not need classic confinement for this:

3

Not a @store reviewer, however:

I believe being in a supported category is a hard requirement of granting classic confinement. As a result the store is highly unlikely to be able to fulfill your request in this state.

Note that you can still distribute classic confined snap via alternative channels such as GitHub Releases.

1 Like