|
Unknown opened 4 years ago
|
|
|
Using the "closed" list managed by another entity in an open-source application? I'm not convinced that this is a good idea. As for adding a "single" field, we already had that and we split this field intentionally - many people complained that is difficult to use as it enforced knowing full JID of the room. If anyone else wants you to join the room (typical case when you want to join a room with known JID) then he can send you an invite (a lot easier than send you a JID) or when you found room JID on the website (usually should be a XMPP URI which is supported by SiskimIM). I cannot thing of any other case in which I would know a JID of a room and would like to join it and leave it frequently. |
|
|
More like offer it as an option, like Conversations "Discover" function |
|
|
You could also set up your own instance of the search. |
When joining a MUC on a different component than the one from your server you have to enter the remote servers MUC component, choose the MUC and join. This could be improved by either adding the possibility to directly enter the full JID of the MUC or (imo even better) integrating search.jabber.network.