Myna: request for auto-connection

name: myna

description: Myna push-to-talk dictation for Ubuntu Desktop - the client that
captures the microphone, streams it to a local speech-to-text inference snap
over a Unix socket, and injects the transcript into the focused application

snapcraft: https://github.com/canonical/myna/blob/integration-220627/myna-snap/snap/snapcraft.yaml
upstream: https://github.com/canonical/myna
upstream-relation: the publisher is the upstream (Canonical); this snap is built
from that repository

plugs:
  pipewire:
    request-type: auto-connection
    reasoning: |
      Myna is a push-to-talk dictation client; capturing the microphone is its
      entire function. The myna app is a supervised user daemon started at
      login that holds a GlobalShortcuts portal binding and opens a PipeWire
      capture stream only while the shortcut is invoked. The audio is pushed over
      a Unix domain socket to a local inference snap and never leaves the machine:
      no snap in the fleet plugs network, and the model weights ship as snap
      components so there is nothing to fetch at runtime.

      Without an auto-connection every user must run snap connect myna:pipewire`
      before the application does anything at all. The precedent we are matching is
     the audio-record auto-connection granted to snaps whose declared purpose is capture
      (browsers, media and conferencing apps).

Notes for the reviewer

  • pipewire is the only interface on this snap that does not auto-connect from the base declaration. desktop, desktop-legacy, gsettings, home and network-bind all already do.

  • desktop-legacy is what reaches the IBus daemon’s private socket, which is how the transcript is injected into the focused application. network-bind is only there because snapd’s seccomp template gates bind(2) behind it even for the AF_UNIX control socket.

  • The snap slots dictation (interface dbus, session bus, name org.myna.Dictation) for the GNOME Shell indicator. The consumer is an unconfined Shell extension, so there is no plug side and no declaration is needed - it is listed here only so the picture is complete.

  • If the board would rather see this as audio-record than pipewire, say so and we will change the plug; pipewire was chosen because the client speaks the PipeWire API directly for low-latency streaming capture, not through PulseAudio compatibility.

This request has been added to the queue for review by the @reviewers team.

Hello @charles05!

This is a +1 from me for granting auto-connect for the pipewire interface to the myna snap, given the described context and functionality this is reasonable access.

Reasoning makes sense and +1 from me as well to grant auto-connection for the pipewire interface to the myna snap.

Thank you for the reviews @shishirsub10 and @elisehdy !

Hello again @charles05,

+2 votes for, 0 votes against, granting auto-connect of interface pipewire to snap myna. This request is approved. Please let me know when you have published a revision of the snap and I will grant this access. Thank you!

Hi there, I tried to publish revision 1 to lastest/edge, but seems I missed some review requests:

declaration-snap-v2:slots_connection:dictation:dbus
declaration-snap-v2:slots_connection:hud:dbus
     declaration-snap-v2:slots_connection:dictation:dbus

Requesting a declaration for the two session-bus dbus slots:

  • dictation, name com.canonical.Myna.Dictation - the daemon’s control interface, consumed by the GNOME Shell indicator.
  • hud, name com.canonical.Myna.Hud - the HUD’s own service, used by the daemon to drive the on-screen recording indicator.

No snap plugs either name. Consumers are the unconfined GNOME Shell extension and an app inside this same snap, both of which the permanent-slot policy already covers. So this is a slot-side declaration only.

1 Like

Hello again @charles05,

Apologies for the delay here, the well-known dbus names listed are approved and have been granted. Auto-connection has also been granted for pipewire. This is now live!