Can I create two-way channel communication heirarchies?

[bbosen]

HI. I want to create three channels like this:

                    __Mission1BlueTeam
                  |         
  Mission1All-----|
                  |__Mission1RedTeam

 

Players tuned to "Mission1All" should be able to communicate in both directions with people on all three of those channels, transmitting to everybody and hearing everything happening in any of the three channels.

Players tuned to either of the two subchannels (Mission1BlueTeam or Mission1RedTeam) should only be able to communicate with those tuned to the same, single channel they have entered and with those tuned to the "Mission1All" channel.

Thus those tuned to Mission1BlueTeam are isolated from those tuned to Mission1RedTeam and vice versa, but they can still be reached by anybody that needs two-way communication with the entire group.

The intent here is to make it easy for "Plumble" users (who have no facility for "whisper" or "shout" functions) to participate privately in either team (Red or Blue) or publicly in both teams, by just clicking the appropriate channel. (Plumble is a well-behaved, simple Android app supporting Mumble, but it isn't as flexible or as powerful as the standard, well-known Mumble desktop application. Think of Plumble as a "Push-To-Talk Only" application.)

[N8LHG]

HI. I want to create three channels like this:

                    __Mission1BlueTeam
                  |         
  Mission1All-----|
                  |__Mission1RedTeam

 

Players tuned to "Mission1All" should be able to communicate in both directions with people on all three of those channels, transmitting to everybody and hearing everything happening in any of the three channels.

Players tuned to either of the two subchannels (Mission1BlueTeam or Mission1RedTeam) should only be able to communicate with those tuned to the same, single channel they have entered and with those tuned to the "Mission1All" channel.

Thus those tuned to Mission1BlueTeam are isolated from those tuned to Mission1RedTeam and vice versa, but they can still be reached by anybody that needs two-way communication with the entire group.

The intent here is to make it easy for "Plumble" users (who have no facility for "whisper" or "shout" functions) to participate privately in either team (Red or Blue) or publicly in both teams, by just clicking the appropriate channel. (Plumble is a well-behaved, simple Android app supporting Mumble, but it isn't as flexible or as powerful as the standard, well-known Mumble desktop application. Think of Plumble as a "Push-To-Talk Only" application.)

 

bbosen,

That's a really cool idea, and I would love to do that on my server as well, however, I think the closest thing you will come to that is the "link" function which links two or more channels together. Assuming you have equal attributes on both channels (one can 't be private and the other public), the audio will link between the channels.

Unless there is a function I don't know about outside the normal abilities, I don't think you can do that. Lets see if kissaki jumps in there with an idea. :-)

[bbosen]

N8LHG:

Thanks for your helpful reply.

I suspected that Mumble's channel "Link" facility would be part of the solution, but I cannot find a clear definition of the purpose of that "Link" facility anywhere in the documentation, and the associated behavior of the UI is completely bewildering to me.

To test "Link" in this context, I connected to my Murmur server as the "SuperUser". Then when I right-clicked on "Mission1BlueTeam", I saw a pop-up context menu offering "Link". It seemed that I ought to click on that menu item as part of my experimenting, but as soon as I did that, I saw THREE new little "paper clip" icons appear. One of these was adjacent the "Mission1BlueTeam" channel as I had expected. The second of these was adjacent the "Mission1RedTeam" channel, which surprised me. The third was two levels higher up in the channel heirarchy, which is completely baffling, especially since the channel between the linked levels was skipped (not getting a "paper clip" icon) in the process.

After that, when I right-clicked on any of those channels and selected the offered "Unlink" option, all three little paper clip icons immediately disappeared.

Does this make sense to anybody? Can anybody offer a clear explanation of the purpose of this channel "Link" facility and/or why it pops up a trio of paper clip icons when I use it as described?

Thanks!

bbosen

[bbosen]

[...a few hours later...]

Well, I've been playing around with channel linking by right-clicking on various channel names and then on "Link" and "Unlink". I think I'm getting it figured out....

It seems that the UI's efforts to advertise channel links with those little "paper clip" icons is dominated by at least three important rules as follows:

1 of 3: Although there may be MANY links active on the server, the UI supresses display of any links not relevant to your current channel. You never see any link icons while you are in a channel that isn't somehow linked to any other channel.

2 of 3: When you enter a channel that is linked elsewhere, all of those "elsewhere" links show up with little "paper clip" icons.

3 of 3: The UI never shows a "paper clip" icon for your current channel, even when it has a link to other channels that ARE displayed. It's as if the UI is saying "YOU OBVIOUSLY KNOW WHAT CHANNEL YOU HAVE ENTERED. IT IS LINKED TO ALL OF THE OTHER CHANNELS THAT ARE NOW MARKED WITH PAPER CLIP ICONS.

The mysterious behavior I described in my prior post may have been caused by my own prior experimenting, through which I may have unwittingly created a few pre-existing links that were hidden because (when I commenced that experiment) they had no relationship with the channel on which I was creating my experimental, new link. But once I created a new link in a previously unlinked channel, it instantly had a linking relationship with some other linked channels so all of the other, pre-existing links instantly showed up.

Further experimenting indicates that somehow it is possible to create two or more distinct groups of links. That's great, because if link relationships were always global across the entire server, the effect would be just to accumulate one single, massive, linked group that would just get bigger and bigger, consuming more and more channels as links are added. Much better to have a little group in one area for a few people that work together, and another separate little group on some other area for some other relationship/purpose, etc.

For clarity in this discussion, I will call this concept "Link Communities".

I still haven't figured out what behavior isolates one "Link Community" from another.

Is there any tutorial documentation explaining these concepts anywhere?

[bbosen]

[...still later...]

Well, I've continued to play around with the channel "Link" pop-up menu and its associated "paper clip" icons. Somehow I have succeeded in creating three separate "Link Communities" and I can live with the result. It isn't what I had hoped for, but it's better for my community of mixed Mumble/Plumble users than what I had before all of this experimentation. The result compromises Mumble users a bit in order to make it appropriately similar and fair to Plumble users.

My server actually supports three missions, each of which can have two teams. So my actual channel hierarchy looks like this:

                   __Mission1BlueTeam
                  |         
  Mission1All-----|
                  |__Mission1RedTeam

                   __Mission2BlueTeam
                  |         
  Mission2All-----|
                  |__Mission2RedTeam

                   __Mission3BlueTeam
                  |         
  Mission3All-----|
                  |__Mission3RedTeam

 

For clarity in subsequent use of this discussion, let's clarify some terms in the context of my channel arrangement. I like the following terms and definitions:

Parent Channel: "Mission1All", "Mission2All", and "Mission3All" are Parent Channels. Each has two "Child Channels".

Sibling Chanel: "Mission1BlueTeam" and "Mission1RedTeam" are "Sibling Channels" to one another. So are the other BlueTeam/RedTeam pairs associated with each mission.

I'm not sure how I did it, but by mindlessly slogging through Mumbl's channel linking UI in a bewildering sequence of repeated attempts, I now have all of the "Mission1" channels linked together into one isolated Link Community. All of the "Mission2" channels are linked together into a second isolated Link Community, and all of the "Mission3" channels are linked together into a third isolated Link Community.

As a consequence, Plumble users (who have no "whisper or shout" key) can just join any of the three channels associated with their chosen mission, and they can talk to and hear from anybody else in any of the three channels used for that mission. Mumble users can do the same. Because so many of my players like Plumble, this compromise is an improvement, even though Mumble users can no longer speak privately on their associated team channels (like "Mission1BlueTeam"). Within each of the three missions, everybody always hears everybody else. At least everybody is treated equally....

The process of setting this up was confusing. I'm not exactly sure what I did to separate the three "Link Communities" from one another. Perhaps it was because I was disconnecting and reconnecting between setting up each of those three Link Communities, but I'm not sure. Perhaps it has something to do with the depth of the channel hierarchy from which I commence linking?

Am I the only person who is struggling to understand the subtleties of the UI when channels are grouped?

I don't now if this channel grouping will ever expire without my explicit superuser intervention. I hope not.... it was too painful to set it up. I hope I don't have to do this every week!

Edited August 16, 2019 by bbosen

[bbosen]

Can anybody suggest an improvement on this system that will re-establish the separation of voice comms between sibling channels while retaining the full ability of parent channels to communicate with their children?

[kissaki]

Hello,

The channel link feature will make them share context for talking.

For the following consider a single, unlinked channel a link community with just one channel in it.

To join another channel into your link community, you join the channel community and then open the context menu on the link you want to join into the group, and activate the Link action. The channel is then part of the community.

The channel names of channels in your current link group are always italic. This includes the channel you are currently in, which does not have the link icon like the other channels.

So to link the parent with its children into a community, you join the parent and on both children activate the Link action.

This is also the first step to your desired behaviour.

From the Speak docs:

 

For linked channels, only players with Speak privilege in the destination channels will be heard.

 

So what we want to do not is when in the parent channel allow speak in it and the children, but when in a child channel allow speak in the parent and current channel, but not in siblings.

I am having difficulty to do this as well, but the tools we want to use are the in, out, sub, ~in, ~out, ~sub rules with "apply in this channel" and "apply in sub channels" attributes.

These are described in the intro tutorial ACL Tutorial and in more detail on the ACL and Groups page.

The difficulty is wrapping the head around the logic. It is very capable, but also very complex.

Rules defined in one channel can be inherited in child channels, and can then apply in that channel, or the original defining one (the ~ prefix). The in rule is for inside the channel (and sub channels if inherited), and out for outside the channel. The sub rule has three (optional) parameters and can make the rule apply to channels with a common parent, starting at a specific min depth, and stopping at a specific max depth (mix this with the inherit here or there and apply here or there and it gets very confusing).

So, the question now is: How do we apply speak in parent and child in the parent, but in the child allow speak in itself and the parent, but not the other child = sibling.

I am thinking:

1. Deny sibling.

2. Then allow common ancestor.

3. Then allow self.

The rules:

1. in parent apply to sub channels @~sub,0,1 deny speak.

2. in parent apply here and sub channels @in allow speak

Hah, that finally worked! And as usual it is much simpler than I expected/tried stuff out in the end.

[kissaki]

I created an elaborative documentation example for this at https://wiki.mumble.info/wiki/ACL_and_Groups/English#Channel_Group_-_Speak_to_children_but_not_siblings

Please take a look for any issues and if it is well explained. Feel free to improve if you have a wiki account, or give your feedback here.

[bbosen]

I created an elaborative documentation example for this at https://wiki.mumble.info/wiki/ACL_and_Groups/English#Channel_Group_-_Speak_to_children_but_not_siblings

Please take a look for any issues and if it is well explained. Feel free to improve if you have a wiki account, or give your feedback here.

 

Kissaki:

Thank you for your authoritative response. Your assurance that what I want to do is somehow possible is very comforting. Your explanation of the behavior of Mumble's "Link" process has helped me understand it much better.

Now that I have a good understanding of Mumble's channels, their associated hierarchies, channel linking, and "Link Communities, I will be better able to follow on with more advanced concepts like Mumble's "groups" and "ACLs". I will need some time to assimilate all of that.

I do not have a wiki account but I would like to help out. I will attempt to setup myself up with a wiki account and if I can be of service documenting what I learn I will be happy to participate. Mumble deserves more attention from the world!

[bbosen]

I created a Wiki account and inserted new introductory material focusing on the basics and on basic Mumble access control vocabulary. All of that work went into this page:

https://wiki.mumble.info/wiki/ACL_and_Groups/English

However, when I access that page as a regular user, I never see that new content. I'm not sure if I am doing something wrong in my attempt to get it published. To prevent loss of this work, I insert a copy here:

====== BEGIN COPY OF NEW WIKI INSERTION =======

Mumble Access Control Vocabulary

Mumble has a rich and powerful set of tools for controlling access. In order to understand those tools, it's essential to understand certain fundamental terms as follows:

Channel: The most basic tool for separating Mumble conversations is the "Channel". In its most basic configuration, Mumble servers create just one Channel, and all users communicate with one another simultaneously by entering and speaking within that channel. As simple Mumble servers attract more users, it is commonplace for them to be expanded with several distinct Channels, allowing different groups of people to isolate their conversations within those distinct Channels. In these simple situations, conversations within one Channel are not heard in any of the other Channels.

Channel Hierarchies: Related Mumble Channels can be organized Hierarchically, like members of a family. Channels can have "Children", "Parents", and "Siblings". This can go on for several "Generations", so that one Channel can be the Child of its Parent and it can also be the Parent of its own Children. The depth of this Parents/Children hierarchy can continue to grow. In large Mumble Channel Hierarchies, we might refer to a channel's "Ancestors" and "Descendants", and we might refer to the common ancestry between two related Channels according to the number of "Generations" back to a common Ancestor. Here is a picture of a very simple Channel Hierarchy:

 

              ----Team1
            |
   Mission1-|
            |
             ----Team2

 

In that example, the Channel named "Mission1" has two Children, named "Team1" and "Team2". The Channel named "Team1" has one Parent ("Mission1") and one Sibling ("Team2"). Following the same pattern, the Channel named "Team2" has one Parent ("Mission1") and one Sibling ("Team1"). Even though all three of these Mumble Channels have an obvious Hierarchical relationship, conversations within one of them are still isolated from the others unless additional Mumble tools are put into place.

Channel Links: After a Mumble server grows enough to support several channels, it is sometimes desirable for two or more channels to be "Linked" so that their conversations can be shared. For example, suppose that the simple Channel Hierarchy shown in the prior example grows into a larger Channel Hierarchy like this:

 

              ----Team1
            |
   Mission1-|
            |
             ----Team2

             ----Team1
            |
   Mission2-|
            |
             ----Team2

 

In this larger situation supporting two different Missions, it might be desirable for everybody participating in Mission1 to communicate with one another in one large group, without interfering with conversations associated with Mission2, and vice versa. Mumble allows this through a tool that it calls "Channel Links". By joining a Mumble Channel and then right-clicking on the name of one of its Children or Descendants, a Mumble Administrator is presented with a menu option that can be used to "Link" them. Two or more Linked Channels of this type are known as "Link Communities". Within one of these Link Communities, all conversations are heard by everybody in any of the Linked Channels. Referring to the diagram immediately above, it would be easy for a Mumble Administrator to create one Link Community for Mission1 with its Children, and a second Link Community for Mission2 with its Children, so that players participating in those missions can communicate within their own mission, regardless of the team they have joined, without interfering with the other mission.

Channel Links of this type are, however, unsophisticated; they merge ALL conversations within the Link Community. As a Mumble server attracts more and more users for more and more advanced use, it can sometimes become desirable to restrict this merging of a Link Community's conversations. For example, suppose players of Mission1's "Team1" want to put together a secret plan, unknown to "Team2". In fact, in situations like that illustrated in the diagram above, it is commonplace for team-oriented players to want to speak in private on their own channel some of the time, while preserving the option to speak to the entire Link Community at other times. Mumble provides various different kinds of tools to help with this.

Access Control Lists ("ACLs"): Use of every Mumble Channel is restricted by a list of rules known as its "Access Control List" or "ACL". Upon initial creation of a new Channel, its ACL is populated with default rules that allow sensible access with few restrictions. Usually those rules are simply "inherited" from the Channel's Parent. However, authorized Mumble Administrators that right-click on the name of a Mumble Channel will see a pop-up menu allowing them to modify its ACL by eliminating or modifying existing rules, or by adding new ones.

Groups: Mumble's "Groups" serve as a convenient way to define or limit the scope the rules in an "Access Control List" or "ACL". Because each rule in each Access Control List operates on some group of users in order to grant or limit what can be done in a Mumble Channel, it's important to understand Mumble's Groups before creating any of those rules.

Whenever a Mumble Channel is created, Mumble automatically gives it several specially named Groups, each with a descriptive name and purpose. They are:

all: Everybody using this channel by any means.

admin: People with administrative authority for this channel.

in: Everybody tuned to this channel

out: Everybody NOT tuned to this channel.

sub: Everybody in a channel with parent or ancestor in common with this channel. Optional parameters designate maximum and minimum parental separation

~in:

~sub:

~out:

Those names suggest the purpose of each group and the scope of any rule written for that group. For example, any rule written for the "all" group of any channel will apply to everybody using the channel in any way, even if they have some kind of access to the channel without actually being tuned to it (such as access through a Mumble "Link"). Any rule written for the "in" group of that channel will apply only to everybody that is currently tuned to that channel. The tilde ("~") character limits the associated group to the channel in which it is defined, eliminating any effect of inheritance or links. In addition to those predefined groups, appropriately authorized users can create additional ones, assigning descriptive names to help clarify their purpose. These allow specific groups of people, referenced by their Mumble usernames, to enjoy defined privileges or protection as defined by rules referencing those new groups.

Continuing our discussion of Groups, ACLs, Links, and Channels, let's return to our first little Channel Hierarchy diagram:

 

              ----Team1
            |
   Mission1-|
            |
             ----Team2

 

Suppose we want to isolate the two Siblings "Team1" and "Team2" from one another so that they can hold private conversations, but we DON'T want that isolation to apply to the Parent channel "Mission1". That way, it's easy to share mission-wide conversations by hopping into the "Mission1" channel. Anybody lurking in "Mission1" can hear and interact with every conversation throughout that Mission1 Link Community, but when team members want a private conversation they can all gather in their own team channel and share secrets. After setting up the Link Community across all three of those Channels as described above, the desired Sibling isolation can be achieved by appending two new Rules onto the end of the Access Control List for the Parent Channel ("Mission1"). Those rules are:

New Rule 1 of 2: For group "~sub 0,1": deny speak, operating only on Children of "Mission1"

New Rule 2 of 2: For group "in": allow speak, operating on "Mission1" and its Children ("Team1" and "Team2").

The first of those two new rules, expressed as "~sub 0,1" denies speaking privileges into the first-generation Children. Because it is propagated only to the Children of "Mission1", this prevents those tuned to the "Team1" channel from speaking to "Team2" and vice versa.

The second of those two new rules, expressed as "in", allows permits speaking privileges to those tuned in to "Mission1". Because it is propagated to Mission1 and its children, it permits those tuned in to the "Mission1" channel to converse freely with "Team1" and "Team2".

====== END COPY OF NEW WIKI INSERTION =======

[kissaki]

Thank you for your efforts! (I haven’t read through it yet.)

The public-facing page is cached and should update/become updated after a few minutes. If you open the editor/edit page you should always see the updated page content though.

[bbosen]

Thank you for your efforts! (I haven’t read through it yet.)

The public-facing page is cached and should update/become updated after a few minutes. If you open the editor/edit page you should always see the updated page content though.

 

Something is wrong. It's been about 3 days now and I still cannot see my edits on the public-facing page, but I DO see my edits on the editor page as you describe. The cache logic must have failed.

-bbosen-

[kissaki]

I just edited the 1.3.0 page (or rather a template it uses) and it showed up after just a few minutes just fine.

I can also see your changes on the ACL page you edited just fine.

Can you check again? And if you still do not see it, can you please check if your webbrowser serves the webpage from local cache - if you know how to do that?

[bbosen]

Thanks. It synchronized somehow. Now I see my edits on the wiki page here:

https://wiki.mumble.info/wiki/ACL_and_Groups/English

: )