数以百万计的私人 MUC 房间或 ejabberd 中的动态 XEP-0033 对话：什么是最好的？
Millions of private MUC rooms or dynamic XEP-0033 conversations in ejabberd: what is the best?
需要
我有以下场景：
- ~10万玩家
- 50 位管理员
每个玩家可以与每个管理员进行 1:1 对话；玩家甚至可以在单独的对话中同时与所有管理员进行 1:1 对话。
但在任何时候，其中一个对话的管理员可能会邀请另一个（或许多）管理员加入这数千个对话中的一个。
附加：
- 使用 MAM 存储的所有消息
default:always
- 使用
resend_on_timeout:true 进行流管理。
- 一个玩家不能给另一个玩家发消息
示例：
- 假设玩家 1 有 3 个活跃的独立对话
P1:Admin A, P1:Admin G, P1:Admin H
- 然后管理员 A 邀请管理员 H 进入
P1:Admin A 对话（事实上，管理员 H 被邀请进入管理员 A 的对话不会关闭活动的 P1:Admin H 对话），然后玩家将拥有这些活跃对话：
P1:Admin A + Admin H、P1:Admin G、P1:Admin H
解决方案 #1：Muc 房间
我正在考虑将所有对话都变成私人不可发现的 MUC 房间（当用户想与管理员聊天时，客户端将发出自定义 IQ，ejabberd我将开发的模块将处理和创建房间，将玩家和管理员自动加入这个新房间的白名单)。
对于可能意味着 500 万个 MUC 房间的示例场景。我知道 500 万个普通聊天是很常见的情况，但是有这么多房间可以吗？
解决方案 #2：XEP-0033 扩展节寻址
对于此解决方案，我正在考虑将消息标识为具有扩展元素 channel 的房间的一部分。这样收件人就可以进入并进行对话。
但是这个没有MUC房间的安全控制，只有白名单用户才能在一个频道里说话。有没有办法用这种方法来克服隐私问题？
使用 channel 元素的示例：
P1:Admin A + 管理员 B，房间 1
<message to='header.org' from='player1'>
<addresses xmlns='http://jabber.org/protocol/address'>
<address type='to' jid='adminA'/>
<address type='to' jid='adminB'/>
</addresses>
<channel xmlns='chanel:namespace' id='1'>
<body>Hi admin A and admin B!</body>
</message>
管理员B离开，P1:AdminA，还有房间1
<message to='header.org' from='player1'>
<addresses xmlns='http://jabber.org/protocol/address'>
<address type='to' jid='adminA'/>
</addresses>
<channel xmlns='chanel:namespace' id='1'>
<body>Hi admin A only on the same room!</body>
</message>
最终解决方案？
考虑到客户端和服务器定制不是问题...考虑到所有要求，哪种解决方案最好？还是有其他最优解？
我有一个类似的设置，这就是我的处理方式：对话从 1:1 聊天开始，因为他们中的大多数总是 1:1，但是如果管理员想邀请另一个管理员甚至另一个用户，我将聊天转换为 MUC 会议 as described in XEP-0045。
这些会议室是 hidden and members only，但它们不是永久性的（在最后一个居住者退出后被摧毁）。
如果您只打算使用自定义客户端，则多播策略 (XEP-0033) 也可以。如果您使用的是现有客户端，您将无法控制房间。
需要
我有以下场景：
- ~10万玩家
- 50 位管理员
每个玩家可以与每个管理员进行 1:1 对话；玩家甚至可以在单独的对话中同时与所有管理员进行 1:1 对话。
但在任何时候，其中一个对话的管理员可能会邀请另一个（或许多）管理员加入这数千个对话中的一个。
附加：
- 使用 MAM 存储的所有消息
default:always - 使用
resend_on_timeout:true进行流管理。 - 一个玩家不能给另一个玩家发消息
示例：
- 假设玩家 1 有 3 个活跃的独立对话
P1:Admin A, P1:Admin G, P1:Admin H - 然后管理员 A 邀请管理员 H 进入
P1:Admin A对话（事实上，管理员 H 被邀请进入管理员 A 的对话不会关闭活动的P1:Admin H对话），然后玩家将拥有这些活跃对话：P1:Admin A + Admin H、P1:Admin G、P1:Admin H
解决方案 #1：Muc 房间
我正在考虑将所有对话都变成私人不可发现的 MUC 房间（当用户想与管理员聊天时，客户端将发出自定义 IQ，ejabberd我将开发的模块将处理和创建房间，将玩家和管理员自动加入这个新房间的白名单)。
对于可能意味着 500 万个 MUC 房间的示例场景。我知道 500 万个普通聊天是很常见的情况，但是有这么多房间可以吗？
解决方案 #2：XEP-0033 扩展节寻址
对于此解决方案，我正在考虑将消息标识为具有扩展元素 channel 的房间的一部分。这样收件人就可以进入并进行对话。
但是这个没有MUC房间的安全控制，只有白名单用户才能在一个频道里说话。有没有办法用这种方法来克服隐私问题？
使用 channel 元素的示例：
P1:Admin A + 管理员 B，房间 1
<message to='header.org' from='player1'>
<addresses xmlns='http://jabber.org/protocol/address'>
<address type='to' jid='adminA'/>
<address type='to' jid='adminB'/>
</addresses>
<channel xmlns='chanel:namespace' id='1'>
<body>Hi admin A and admin B!</body>
</message>
管理员B离开，P1:AdminA，还有房间1
<message to='header.org' from='player1'>
<addresses xmlns='http://jabber.org/protocol/address'>
<address type='to' jid='adminA'/>
</addresses>
<channel xmlns='chanel:namespace' id='1'>
<body>Hi admin A only on the same room!</body>
</message>
最终解决方案？
考虑到客户端和服务器定制不是问题...考虑到所有要求，哪种解决方案最好？还是有其他最优解？
我有一个类似的设置，这就是我的处理方式：对话从 1:1 聊天开始，因为他们中的大多数总是 1:1，但是如果管理员想邀请另一个管理员甚至另一个用户，我将聊天转换为 MUC 会议 as described in XEP-0045。
这些会议室是 hidden and members only，但它们不是永久性的（在最后一个居住者退出后被摧毁）。
如果您只打算使用自定义客户端，则多播策略 (XEP-0033) 也可以。如果您使用的是现有客户端，您将无法控制房间。