libspiel in a sandboxed world [apps]

[sonnyp]

This issue is about discussing what's needed for apps to make use of libspiel without punching hole in the sandbox with "--socket=session-bus".

That particular static permission is considered unsafe. See for example Bustle on Flathub

In the Flatpak world we solve this with portals https://flatpak.github.io/xdg-desktop-portal/ ; we would need a new one, for example org.freedesktop.portal.Speech.

Since libspiel architecture doesn't use a service - I 'm not exactly sure how the portal would work but here is an idea to get the ball rolling

• have GetProviders and SetProvider methods
• implement the same interface as org.freedesktop.Speech.Providerl and forward to the currently selected provider

[sonnyp]

Actually libspiel has a concept of default voice so the method Speech on org.freedesktop.Portal.Speech could be called without specifying a provider.

But providers should still be discoverable by apps so users can choose the appropriate one for this app.

[sonnyp]

provider_id will need to be added to the relevant methods on the Speech method of the portal interface

@eeejay confirmed that the voice id is only unique by provider

[sonnyp]

@eeejay said

It would be cool if the portal could have ActivatableServicesChanged/NameOwnerChanged and ListActivatableNames/ListNames that are prefiltered to only show speech providers

https://matrix.to/#/!LvngxCrIPJosbdQjGY:gnome.org/$7iC5jeADFfDwe3ZLHRDpiQPZU8q9GWQ2Y8Xh9BjfdUg?via=gnome.org&via=matrix.org&via=matrix.tait.tech

So we need to keep in mind the portal needs an APIs to notify of new providers available etc

[swick]

Dbus allows to export different objects implementing the same interface, so we can expose one object per provider and an object for the default provider.

[eeejay]

Dbus allows to export different objects implementing the same interface, so we can expose one object per provider and an object for the default provider.

Yup that's a good way to go.