Request for interface auto connection for Buzz Captions

Buzz (buzz) is a popular speech transcription and translation application loved by more than 10K users on GitHub (GitHub - chidiwilliams/buzz: Buzz transcribes and translates audio offline on your personal computer. Powered by OpenAI's Whisper.). It provides convenient and user friendly interface for subtitle generation and speech transcription improving information access to people with special accessibility needs or for content in non-native languages. Requesting auto connect of the following interfaces:

  • audio-record and pulseaudio - to enable live recording transcription
  • password-manager-service - to enable ability to store OpenAi API access token
  • removable-media - to enable transcription and subtitle generation of files on removable media

All these interfaces are required for Buzz snap to function properly to improve lives and app usability for Linux users.

For password-manager-service - it allows to grab all passwords, so it’s rather advised to try to use portals whether possible to just interact in smallest way possible.

pulseaudio is deprecated in favour of audio-record and audio-playback and so should not be needed.

audio-record seems reasonable since the snap clearly states that it translates audio. +1 from me for auto-connect of audio-record.

The use of password-manager-service is not recommended as it provides access to the entire users keyring and so exposes any secrets stored by a snap to any other snaps with such access (and to any other applications on the system as well). Instead, as mentioned by @KhazAkar, if you use something like libsecret to access the keyring and plug the desktop interface then your snap should automatically store the secret locally via the secret portal without needing access to the system keyring.

Finally, as per the Process for aliases, auto-connections and tracks, auto-connect of removable-media is appropriate for applications that are media editors etc - and I think buzz likely fits into this category. Then the other question is the following criteria:

  • the application itself is a mature, well-known application
  • the snap’s (vetted) publisher is a mature, well-known entity
  • the snap’s (vetted) publisher is the upstream of the software

if the snap is published by someone other than upstream, the publisher must be vetted and either be an established committer to the upstream or the wider snap ecosystem (eg, an established well-known contributor to the software itself, a member of the snapcrafters group, etc)

  • if the publisher doesn’t meet these criteria, other options may or may not be considered such as the publisher joining snapcrafters, snapcrafters becoming a collaborator on the snap, auto-connection granted conditional on the snap packaging being accepted upstream, upstream stating they trust the publisher with the packaging, etc.

Can you please let me know which of these you fit into as the publisher of this snap? Thanks (I am guessing you are the upstream author based on your username but it would be good to get explicit confirmation and then we will need to verify that as well).

2 Likes

Hey @chidiw

I also find the auto-connection of audio-record and removable-media reasonable. Could you please respond @alexmurray question? If I’m right, you (the publisher) are the upstream of the software, is that right?

Regarding password-manager-service interface, we don’t grant auto-connection to it in most cases. In newer OS systems your snap can rely on libsecret using the secret-portal as @alexmurray said. Considering that Buzz upstream looks properly maintained, I will also support manual connection to the password-manager-service (unless other @reviewers oppose) to keep compatibility with older releases that may not implement the secret-portal.

Thanks

@chidiw - ping, can you please provide the requested information @jslarraz mentioned?

A non-reviewer -1 for granting auto-connection to the removable-media interface. You should instead detect the connection at runtime and inform the user to manually allow its access.

This application seems to be generating captions from existing media files instead of editing the media files themselves. IMHO it does not fit into that category.

Thanks for the feedback, all.

@alexmurray, @jslarraz, cav:

  • audio-record, audio-playback, removable-media, and libsecret for the keyring all sound reasonable.
  • Correct, I am both the upstream author and publisher of the snap.

Lin-Buo-Ren: The removable media guide seemed to suggest media players/viewers are also appropriate for auto-connect of removable-media, but I’m happy to pass on that.

1 Like

@chidiw there is no libsecret interface - do you mean password-manager-service? If this is the case, then this would only be able to be granted use-of this interface, not auto-connect due to the sensitive nature of it.

Ping @chidiw - this request is still waiting on your input - it cannot proceed without it. Thanks.

@chidiw - ping, this request cannot proceed without the requested information.

@chidiw - since we’ve not heard back from you, we are removing this request from our review queue. When you have more time to respond, simply do so here and we can add the request back to the queue. Thanks