|
1 Account based MUC joining |
|
2 ========================= |
|
3 |
|
4 Normally when joing a MUC groupchat, it is each individual client that |
|
5 joins. This means their presence in the group is tied to the session, |
|
6 which can be short-lived or unstable, especially in the case of mobile |
|
7 clients. |
|
8 |
|
9 This has a few problems. For one, for every message to the groupchat, a |
|
10 copy is sent to each joined client. This means that at the account |
|
11 level, each message would pass by once for each client that is joined, |
|
12 making it difficult to archive these messages in the users personal |
|
13 archive. |
|
14 |
|
15 A potentially better approach would be that the user account itself is |
|
16 the entity that joins the groupchat. Since the account is an entity that |
|
17 lives in the server itself, and the server tends to be online on a good |
|
18 connection most of the time, this may improve the experience and |
|
19 simplify some problems. |
|
20 |
|
21 This is one of the essential changes in the MIX architecture, which is |
|
22 being designed to replace MUC. |
|
23 |
|
24 `mod_minimix` is an experiment meant to determine if things can be |
|
25 improved without replacing the entire MUC standard. It works by |
|
26 pretending to each client that nothing is different and that they are |
|
27 joining MUCs directly, but behind the scenes, it arranges it such that |
|
28 only the account itself joins each groupchat. Which sessions have joined |
|
29 which groups are kept track of. Groupchat messages are then forked to |
|
30 those sessions, similar to how normal chat messages work. |
|
31 |
|
32 ## Known issues |
|
33 |
|
34 - You can never leave. |
|
35 - You will never see anyone leave. |
|
36 |
|
37 ## Unknown issues |
|
38 |
|
39 - Probably many. |
|
40 |
|
41 # Compatibility |
|
42 |
|
43 Briefly tested with Prosody trunk (as of this writing). |