@wojtek As I've looked into this, it looks like the implementation of this limit would be problematic.

In MIX, if you are allowed to create a channel, the MIX component should advertise to you following feature urn:xmpp:mix:core:1#create-channel. This way client may decided which MIX component should be used for channel creation. And that is great.

However, we have two kind of a channels:

• public - visible in service discovery
• adhoc - invisible in service discovery

I suppose that we would like to block only creation of public channels, while we would like to allow users to created adhoc channels (for private conversation between people).

(The same distinction is in the MUC AFAIR)

I'm not convinced that we want to "force" people to use "testing" component for "adhoc" channels...

On the other hand, I have no problem with limiting creation of public channels - as those are visible to everyone in service discovery.

I suppose that we may want to allow adhoc channels creation on the main MIX component, but block creation of public channels. If that is correct, then we should validate that during channel creation and block it by returning "not-authorized" or "forbidden" with appropriate message, but we would need to keep returning this feature, so that people would be able to use it for creation.

I wonder, if we should "add" a custom feature allowing our software to know that only "adhoc" channels may be created at this component (but not public channels).

I suppose that we may want to allow adhoc channels creation on the main MIX component, but block creation of public channels. If that is correct, then we should validate that during channel creation and block it by returning "not-authorized" or "forbidden" with appropriate message, but we would need to keep returning this feature, so that people would be able to use it for creation. @andrzej.wojcik Given that this would be configured on VHost level then maybe add multiple-choice option: allow none/private/public? (very IMHO)

If we would go for on/off then simply announcing feature (or not) would be sufficient. If we are after more granularity (not sure) then maybe we could extend MIX specification in that regard (It's still WIP) instead of creating something custom)?

@wojtek But here you assumed it will be on per vhost, while in the "description" you considered that as "component or vhost" option. Should then it be on a vhost basis or component? Should we make it more PubSub option? (most likely we would like to control who can create pubsub nodes)? Should we have different "actions" allowed for different kind of users? (ie. local, remote, etc?) It starts to look like you want to push ACL into VHost and I'm not sure if placing everything in vhost is a good idea (it will be huge soon).

You are right. Let's follow KISS:

• keep it to the component configuration in TDSL
• use ACL (so admins will still be able to create channels)
• no distinction for channel type - either you can create channel (and it's advertised) or not - let's not complicate something that should have been simple.

@wojtek Yes, but... this way you will diable MIX for the users on our installation if you will not allow creation private (adhoc) channels. Is this a way we want to go? If so, then what was the point of implementing MIX?

The idea, as outlined in #servers-320 was to have two instances of components - one "official" and the second one for test purposes.

After our discussion during the call, we come to the conclusion that having 2 settings would be probably the best idea.

I'll add 2 ACL config fields to MIX component:

1. Will control creation of public channels
2. Will control creation of ad-hoc (private?) channels

I've added configuration with two properties:

• publicChannelCreationAcl which allows creation of public channels (default DOMAIN_ADMIN)
• adhocChannelCreationAcl which allows creation of adhoc channels (default DOMAIN)