starred/mumble-mumble-voip

Fork 0

mirror of https://github.com/mumble-voip/mumble.git synced 2026-03-03 00:46:56 -05:00

Extend the Mumble URL protocol to be able to "Listen to Channel" #3019

New issue

Open

opened 2026-02-20 22:16:44 -05:00 by deekerman · 8 comments

deekerman commented

2026-02-20 22:16:44 -05:00

Owner

Originally created by @MrWildGear on GitHub (Jun 16, 2025).

Context

Currently, Mumble’s mumble:// URL scheme only allows users to join channels as active participants. There is no way to generate or share a link that enables someone to passively listen to a channel without joining as a regular user. This restricts scenarios where listen-only access is desirable, such as for event audiences, supervisors, or content creators

Description

Introduce a new URL parameter (e.g., ?mode=listener) to the Mumble URL scheme. When a user clicks a link like mumble://server.com/Channel?mode=listener, the Mumble client connects to the specified server and channel in passive "listen" mode. The user can hear all audio from the channel but cannot speak or interact, and appears as a listener in the user list. This mirrors the existing "Listen to channel" GUI feature but makes it accessible via URLs for easier sharing and automation. Server ACLs would still control who can use this feature.

Mumble component

Both

OS-specific?

Additional information

Use cases include sharing listen-only links for live events, allowing supervisors to monitor channels, and enabling content creators to relay Mumble audio via public links. The feature should be backward-compatible, ignored by older clients, and respect all existing permissions and privacy controls

Originally created by @MrWildGear on GitHub (Jun 16, 2025). ### Context Currently, Mumble’s mumble:// URL scheme only allows users to join channels as active participants. There is no way to generate or share a link that enables someone to passively listen to a channel without joining as a regular user. This restricts scenarios where listen-only access is desirable, such as for event audiences, supervisors, or content creators ### Description Introduce a new URL parameter (e.g., ?mode=listener) to the Mumble URL scheme. When a user clicks a link like mumble://server.com/Channel?mode=listener, the Mumble client connects to the specified server and channel in passive "listen" mode. The user can hear all audio from the channel but cannot speak or interact, and appears as a listener in the user list. This mirrors the existing "Listen to channel" GUI feature but makes it accessible via URLs for easier sharing and automation. Server ACLs would still control who can use this feature. ### Mumble component Both ### OS-specific? No ### Additional information Use cases include sharing listen-only links for live events, allowing supervisors to monitor channels, and enabling content creators to relay Mumble audio via public links. The feature should be backward-compatible, ignored by older clients, and respect all existing permissions and privacy controls

deekerman added the

client

feature-request

labels

2026-02-20 22:16:44 -05:00

deekerman commented

2026-02-20 22:16:45 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Jun 17, 2025):

To me it seems that this is already achievable with current functionality by creating a channel where the Speak ACL is revoked for everyone but explicitly granted to those users (creators, moderators, etc.) that are supposed to speak. In this cases, all other users will appear as regular users in the UI but otherwise the effect will be the same.

So I'm wondering: would this be sufficient or is there a more specific scenario that you have in mind for which using ACLs is not enough?

@Krzmbrzl commented on GitHub (Jun 17, 2025): To me it seems that this is already achievable with current functionality by creating a channel where the Speak ACL is revoked for everyone but explicitly granted to those users (creators, moderators, etc.) that are supposed to speak. In this cases, all other users will appear as regular users in the UI but otherwise the effect will be the same. So I'm wondering: would this be sufficient or is there a more specific scenario that you have in mind for which using ACLs is not enough?

deekerman commented

2026-02-20 22:16:46 -05:00

Author

Owner

@MrWildGear commented on GitHub (Jun 17, 2025):

Thank you for your feedback regarding using ACLs to create listen-only channels in Mumble. I’d like to clarify why the proposed feature addresses a distinct use case that current ACL configurations cannot fully support.

Why ACLs Alone Aren’t Sufficient for My Scenario
My Use Case:

I am typically active in a "command" channel, where I need to speak and coordinate with my team.

At times, I also need to listen in on another command channel—perhaps to monitor parallel operations or gather situational awareness—while still being able to speak in my own channel.

Limitations of the ACL Approach:

If I join the second command channel (even with "Speak" revoked via ACLs), I can no longer actively participate in my original channel unless I disconnect and rejoin, or run multiple clients, which is cumbersome and not user-friendly.

All users who join the listen-only channel via ACLs appear as regular participants, not as passive listeners. This can clutter the user list and doesn’t distinguish between true participants and passive listeners.

The ACL method does not allow a user to simultaneously talk in one channel and passively listen to another. Mumble’s "listen to channel" feature (available in 1.4+) does allow this, but it’s not accessible via URL or automation.

Why a Dedicated "Listen Mode" URL Parameter is Needed
Simultaneous Participation: I want to be able to talk in my primary channel while listening to another, without switching channels or running multiple clients.

Clear User Roles: Passive listeners should be visually distinct from regular participants, which is not possible with ACLs alone.

Ease of Access: A URL parameter or scheme for "listen mode" would allow quick, user-friendly access and automation, especially for event organizers or supervisors who need to monitor multiple channels dynamically.

Example Scenario
I am in "Command Channel A" (able to speak and coordinate).

I need to listen to "Command Channel B" for updates but not speak there.

With current ACLs, I must either leave my channel or run a second client.

With the proposed feature, I could remain in "Command Channel A" and passively listen to "Command Channel B"—all from a single client, using a simple URL or menu action.

Conclusion
While ACLs can restrict speaking rights, they do not enable the simultaneous, passive listening across channels that my workflow requires. The proposed "listen mode" via URL would fill this gap, improving flexibility and usability for scenarios like command-and-control, event moderation, and multi-channel monitoring.

If you’d like additional use case examples, I’m happy to elaborate further.

@MrWildGear commented on GitHub (Jun 17, 2025): Thank you for your feedback regarding using ACLs to create listen-only channels in Mumble. I’d like to clarify why the proposed feature addresses a distinct use case that current ACL configurations cannot fully support. Why ACLs Alone Aren’t Sufficient for My Scenario My Use Case: I am typically active in a "command" channel, where I need to speak and coordinate with my team. At times, I also need to listen in on another command channel—perhaps to monitor parallel operations or gather situational awareness—while still being able to speak in my own channel. Limitations of the ACL Approach: If I join the second command channel (even with "Speak" revoked via ACLs), I can no longer actively participate in my original channel unless I disconnect and rejoin, or run multiple clients, which is cumbersome and not user-friendly. All users who join the listen-only channel via ACLs appear as regular participants, not as passive listeners. This can clutter the user list and doesn’t distinguish between true participants and passive listeners. The ACL method does not allow a user to simultaneously talk in one channel and passively listen to another. Mumble’s "listen to channel" feature (available in 1.4+) does allow this, but it’s not accessible via URL or automation. Why a Dedicated "Listen Mode" URL Parameter is Needed Simultaneous Participation: I want to be able to talk in my primary channel while listening to another, without switching channels or running multiple clients. Clear User Roles: Passive listeners should be visually distinct from regular participants, which is not possible with ACLs alone. Ease of Access: A URL parameter or scheme for "listen mode" would allow quick, user-friendly access and automation, especially for event organizers or supervisors who need to monitor multiple channels dynamically. Example Scenario I am in "Command Channel A" (able to speak and coordinate). I need to listen to "Command Channel B" for updates but not speak there. With current ACLs, I must either leave my channel or run a second client. With the proposed feature, I could remain in "Command Channel A" and passively listen to "Command Channel B"—all from a single client, using a simple URL or menu action. Conclusion While ACLs can restrict speaking rights, they do not enable the simultaneous, passive listening across channels that my workflow requires. The proposed "listen mode" via URL would fill this gap, improving flexibility and usability for scenarios like command-and-control, event moderation, and multi-channel monitoring. If you’d like additional use case examples, I’m happy to elaborate further.

deekerman commented

2026-02-20 22:16:46 -05:00

Author

Owner

@Hartmnt commented on GitHub (Jun 17, 2025):

I agree with @Krzmbrzl this should be achievable using ACLs. And I would like to additionally mention the context menu action "Link". That can be used to let spectators hear any linked channel without joining them or otherwise interacting with the UI.

So it would come down to:

Create a spectator channel where people are not allowed to talk
Link it with every channel that spectators should be able to hear
Prevent guests from leaving the spectator channel
Create an URL that allows users to join the spectator channel

That should be exactly what you are describing in your original post. I did not bother reading your AI slop though.

@Hartmnt commented on GitHub (Jun 17, 2025): I agree with @Krzmbrzl this should be achievable using ACLs. And I would like to additionally mention the context menu action "Link". That can be used to let spectators hear any linked channel without joining them or otherwise interacting with the UI. So it would come down to: * Create a spectator channel where people are not allowed to talk * Link it with every channel that spectators should be able to hear * Prevent guests from leaving the spectator channel * Create an URL that allows users to join the spectator channel That should be exactly what you are describing in your original post. I did not bother reading your AI slop though.

deekerman commented

2026-02-20 22:16:46 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Jun 17, 2025):

To me it sounds like what you're after is not the ability to join a channel as passive listener but rather to join a given channel while also configuring listeners for a specified set of channels. Does that sound about right?

@Krzmbrzl commented on GitHub (Jun 17, 2025): To me it sounds like what you're after is not the ability to join a channel as passive listener but rather to join a given channel while _also_ configuring listeners for a specified set of channels. Does that sound about right?

deekerman commented

2026-02-20 22:16:46 -05:00

Author

Owner

@MrWildGear commented on GitHub (Jun 17, 2025):

Current setup when we send out a fleet, we ping out the fleet's information a URL to join that fleets voice coms. as you know trying to join ca channel as people are joining in mass can be a pain in the ass.

In this setup as you get more fleets running at the same time the hard it is to find the op channel to use the "listen to Channel".
we also already make use of quite channel (you can hear the command channel but not the sub channels)

My ideal would be if the current system URL function was able to support both the "Join" and the "listen to Channel" function

this would make it so just like we already do when we send out the fleet's info base on the link you could "join" or "listen to Channel"

hopefully that makes sense. I'm also hopefully that this would be something relatively easy to code.

@MrWildGear commented on GitHub (Jun 17, 2025): **C**urrent setup when we send out a fleet, we ping out the fleet's information a URL to join that fleets voice coms. as you know trying to join ca channel as people are joining in mass can be a pain in the ass. In this setup as you get more fleets running at the same time the hard it is to find the op channel to use the "listen to Channel". we also already make use of quite channel (you can hear the command channel but not the sub channels) **M**y ideal would be if the current system URL function was able to support both the "Join" and the "listen to Channel" function this would make it so just like we already do when we send out the fleet's info base on the link you could "join" or "listen to Channel" hopefully that makes sense. I'm also hopefully that this would be something relatively easy to code.

deekerman commented

2026-02-20 22:16:46 -05:00

Author

Owner

@Hartmnt commented on GitHub (Jun 18, 2025):

Alright, so the actual feature request would be an extension to the Mumble URL protocol to be able to "automate" the "Listen to Channel" action.

That sounds reasonable, I guess.

For anyone interested in picking this up, there are still some considerations to make:

Do we want to be able to join a server AND listen to a channel with one URL? Alternatively, a mode switch could decide if a given URL joins or just listens
- If we use a mode switch, do we require the user to be already connected to the target server in order to work?
Do we want to be able to listen to an arbitrary number of channels with one URL?
What happens if the URL is only partially valid
Where and how (if at all) do we let the user "generate" or "copy" the URL for listeners in the UI

@Hartmnt commented on GitHub (Jun 18, 2025): Alright, so the actual feature request would be an extension to the Mumble URL protocol to be able to "automate" the "Listen to Channel" action. That sounds reasonable, I guess. For anyone interested in picking this up, there are still some considerations to make: * Do we want to be able to join a server *AND* listen to a channel with one URL? Alternatively, a mode switch could decide if a given URL joins or just listens * If we use a mode switch, do we require the user to be already connected to the target server in order to work? * Do we want to be able to listen to an arbitrary number of channels with one URL? * What happens if the URL is only partially valid * Where and how (if at all) do we let the user "generate" or "copy" the URL for listeners in the UI

deekerman commented

2026-02-20 22:16:46 -05:00

Author

Owner

@MrWildGear commented on GitHub (Jun 18, 2025):

Ui wise where the copy URL is I would Chage it to a sub menu. Copy Join URL and Copy Listen URL.
This makes it easier to know with URL you're copying while keeping them separated.
I would also keep it to one channel per URL though the idea is neat to join multiple channels with one URL.

"Do we require the user to be already connected to the target server in order to work?"
90% of my team that would be using this would already be connected but if they were not, they would just join the root or the last channel they were connected to in the default join mode.

hopeful you find this input useful.

@MrWildGear commented on GitHub (Jun 18, 2025): Ui wise where the copy URL is I would Chage it to a sub menu. Copy Join URL and Copy Listen URL. This makes it easier to know with URL you're copying while keeping them separated. I would also keep it to one channel per URL though the idea is neat to join multiple channels with one URL. "Do we require the user to be already connected to the target server in order to work?" 90% of my team that would be using this would already be connected but if they were not, they would just join the root or the last channel they were connected to in the default join mode. hopeful you find this input useful.

deekerman commented

2026-02-20 22:16:46 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Jun 18, 2025):

Do we want to be able to join a server AND listen to a channel with one URL? Alternatively, a mode switch could decide if a given URL joins or just listens

By the very nature of the URL it has to specify a server (unless we drastically change the protocol) so I think it would always be join and listen. If not, current understanding of the workings of these URLs would be violated, I think.

Do we want to be able to listen to an arbitrary number of channels with one URL?

I don't see a reason why we would want to restrict it to only a specific number of channels.

What happens if the URL is only partially valid

By that I assume you mean something like the server address being correct but a channel for listening is not found? I'd handle it similarly to how joining a specific channel by URL is handled. That is, there is a fallback option which for joining is to just join the root channel and for listening I'd say that just not creating a listener in the given channel seems like a reasonable generalization.

Where and how (if at all) do we let the user "generate" or "copy" the URL for listeners in the UI

I see the following options:

Not at all - users who want to use this feature will have to manually edit the channel listeners
Add an option to the "create URL for joining this channel" to "mirror the currently configured listeners". That is, you would place listeners yourself and then copy the URL to a channel which would then contain instructions for setting up the same listeners that you just placed manually.
A full-blown URL creation UI accessible via the server dropwdown menu

@Krzmbrzl commented on GitHub (Jun 18, 2025): > Do we want to be able to join a server AND listen to a channel with one URL? Alternatively, a mode switch could decide if a given URL joins or just listens By the very nature of the URL it has to specify a server (unless we drastically change the protocol) so I think it would always be join and listen. If not, current understanding of the workings of these URLs would be violated, I think. > Do we want to be able to listen to an arbitrary number of channels with one URL? I don't see a reason why we would want to restrict it to only a specific number of channels. > What happens if the URL is only partially valid By that I assume you mean something like the server address being correct but a channel for listening is not found? I'd handle it similarly to how joining a specific channel by URL is handled. That is, there is a fallback option which for joining is to just join the root channel and for listening I'd say that just not creating a listener in the given channel seems like a reasonable generalization. > Where and how (if at all) do we let the user "generate" or "copy" the URL for listeners in the UI I see the following options: - Not at all - users who want to use this feature will have to manually edit the channel listeners - Add an option to the "create URL for joining this channel" to "mirror the currently configured listeners". That is, you would place listeners yourself and then copy the URL to a channel which would then contain instructions for setting up the same listeners that you just placed manually. - A full-blown URL creation UI accessible via the server dropwdown menu