Rewrite in Rust with DBus - Target AppImage for packaging

[jim3692]

After some discussion on portability to other distros, ease of installation, and also switching to an event driven architecture, we concluded that the AppImage packaging format and DBus would be the best options.

DBus

The idea is to switch from sendNativeMessage to connectNative, to daemonize the native part, and to further extend this architecture with DBus for messaging across multiple clients.

flowchart LR
    subgraph Firefox
        extension[Extension]
    end
    native_host["Native Messaging Host"]
    extension <-->|Native Messaging| native_host
    native_host <-->|D-Bus| backend
    native_controller["Native GUI Frontend"] <-->|D-Bus| backend
    subgraph Backend
        backend["Server (Rust)"]
    end
    backend <-->|pipewire-rs| pipewire["Pipewire"]

Loading

https://www.freedesktop.org/wiki/Software/DBusBindings/

The simpler way to implement a DBus service is using Python. However we need to track the names of the Python dependencies across multiple distros and ensure the correct versions are installed.

DBus API

Decisions to take:

• Should we only allow the creation of a single node or should each client decide whether they want to create a new node or manage the same node another app is using?

Features (might change based on decisions):

• Create a node
• Choose what to connect to the node:
  • All nodes matching some rule (regex maybe)
  • A specific list of node serials
• Delete the node
• Signals for output node creation/removal (for updating node list)
• Signals for virtmic node target change (to update UIs, we need to know if other clients changed the connected node)

AppImage

Since we are currently facing issues with unclear installation steps for other distros, besides Arch and NixOS, we need a unified packaging format to support as many distros as possible.

AppImage could solve both this issue and the Python dependencies one. They are easy to download and run, and contain all their dependencies in one file.

This example shows how to use appimage-builder to create an AppImage for Bash:
https://appimage-builder.readthedocs.io/en/latest/examples/bash.html

We could either use apt and check whether we can include PPAs like the one for pipewire:
https://pipewire-debian.github.io/pipewire-debian/

Or just use pacman in the AppImage.

When the AppImage first runs, it could copy itself in ex. ~/.local/share/pipewire-screenaudio and create the messaging host json in the browsers' home directories. (Issue: How could we detect, or make it easier to install for multiple browsers?)

Furthermore, the AppImage should probably be able to self update, by downloading newer versions from Github releases.

CC: @alansartorio

[alansartorio]

To know which browsers the user wants to install the native messaging host to we can show a popup when the user runs the AppImage that lets them choose.
To detect if the AppImage has been launched by the user or as the native messaging host we can check if any of CHROME_WRAPPER or MOZ_LAUNCHED_CHILD env vars are set.
I found this solution here.

They implemented it after this line.

[alansartorio]

I don't think we should automatically update the AppImage, we can let the user know if a new backend version is available from the extension popup. We can use Github releases HTTP API to check the latest version and show the download URL.
I also don't think we should copy the AppImage anywhere else. With AppImages usually it's the user who chooses where they want to place them.
When the user downloads a new version or moves the AppImage path they should run it to update the native messaging jsons.

[jim3692]

The problem is that the user may run the AppImage once downloaded, and then clear their downloads directory. We could make it more obvious that the AppImage is an installer maybe, for example, by naming it like Pipewire-ScreenAudio-v0.3.3-Installer.appimage.

Also regarding the auto-updating, I would prefer the popup to show that there is an available update, and allow the user to just click update. So the "auto-updating" would be more like the ability of "self-replacing".

[alansartorio]

If the user clears the downloads directory, they will get a "missing connector" error in the extension popup and they should be able to download it again. What I don't like about the installer is that if the user wants to remove it, they can't just delete the AppImage, they'll have to search for it in the install location.

About the update thing I agree. I found there are documented ways to update an AppImage here.

[jim3692]

Should we only allow the creation of a single node or should each client decide whether they want to create a new node or manage the same node another app is using?

We may need to consider security as well on that. My idea is that each client requests a UUID/token on first run, which is persistent. If an app aims to manage other clients, it would request "admin" access (not sudo - access to administer other apps), and show a popup to the user for validation.

This way apps will have limited scope and not conflict with others.

[alansartorio]

I like that. Do you imagine channels as being identified with a name or a generated id?

[jim3692]

We could support both. As an example, the Firefox extension could use auto-generated UUID channels for each Firefox Profile, and named channels, in case we ever add support for per-tab virtmic.

[Curve]

Maintainer of Rohrkabel here.

I've recently discovered this discussion and had a look through the pipewire related code - I'm currently working together with Vencord to support audio screen sharing and I've developed Venmic as a result of this.

Venmic currently does not cover all of the ideas presented here but I would happily extend venmic to also work as a d-bus daemon with multi-mic support - Although I'm not quite certain about the advantages of turning it into a d-bus daemon and installing a native messaging host, why not have the native backend simply run as a rest server? That will not require additional browser modifications.

In it's current form Venmic is also able to run as a Rest-Server with quite flexible patching capabilities (can list and link against nodes based on any node-property and also work in include/exclude or exclude only mode, which allows to share whole desktop audio).

Maybe we could join forces in an effort to provide the most stable experience to everyone?

[IceDBorn]

@Curve Why don't you join our matrix server?

[Curve]

@Curve Why don't you join our matrix server?

Just joined ^^