216
edits
Difference between revisions of "XEP-Remarks/XEP-0045: Multi-User Chat"
Jump to navigation
Jump to search
m
XEP-Remarks/XEP-0045: Multi-User Chat (view source)
Revision as of 16:49, 26 December 2023
, 16:49, 26 December 2023no edit summary
Neustradamus (talk | contribs) m |
|||
| (11 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{remarks}} | |||
= Ban time period = | |||
As of 2020, there is no the specification of the ban time period. | |||
It is needed to add the feature in the [https://xmpp.org/extensions/xep-0045.html XEP-0045]. | |||
- https://logs.xmpp.org/xsf/2020-05-25#2020-05-25-7e5712f062e33e68 | |||
- https://logs.xmpp.org/xsf/2020-05-26#2020-05-26-26d63c58841f2085 | |||
= Stable Message IDs = | = Stable Message IDs = | ||
| Line 26: | Line 37: | ||
(this mechanism doesn't cover MUCs which don't reflect the message ID and do autopastebin. Screw them!) | (this mechanism doesn't cover MUCs which don't reflect the message ID and do autopastebin. Screw them!) | ||
= Mediated MUC Invitations = | |||
The default mechanism to invite somebody into a MUC is [https://xmpp.org/extensions/xep-0045.html#invite-mediated §7.8.2 Mediated Invitation], where the MUC service will invite your friend on your behalf. | |||
* Some MUC services will not invite a JID that is already a MUC member, thus breaking the invitation UX. | |||
* With Mediated Invites, a malicious MUC can send an invite in the name of a user's contact, tricking the user's client into auto-joining. | |||
* [https://xmpp.org/extensions/xep-0249.html XEP-0249: Direct MUC Invitations] is a potential solution to those issues. | |||
= Am I still there? = | = Am I still there? = | ||
| Line 34: | Line 54: | ||
Sending a "silent" message or presence update to the MUC will lead to O(N²) complexity (if every client does so), killing all our batteries. | Sending a "silent" message or presence update to the MUC will lead to O(N²) complexity (if every client does so), killing all our batteries. | ||
This is solved by [https://xmpp.org/extensions/xep-0410.html XEP-0410: MUC Self-Ping] | |||
= MUC double join = | = MUC double join = | ||
| Line 56: | Line 65: | ||
http://mail.jabber.org/pipermail/standards/2015-May/029819.html | http://mail.jabber.org/pipermail/standards/2015-May/029819.html | ||
= Why do I need to host my MUC component on subdomain.domain.tld? = | |||
You don't. You don't even need to host it on "domain.tld", you can host it on any bare JID you want (without a resource, with or without a node). | |||
Not all clients will be able to join, because this isn't how it's always been done but technically nothing prevents it. | |||
You also can have a room directly on subdomain.domain.tld, or domain.tld. | |||
Clients will generally expect to be able to create rooms on the address that is given to them in disco#items on the host (the "MUC component"). | |||
[https://xmpp.org/extensions/xep-0045.html#disco-rooms disco#items on a component] will get you a list of rooms hosted on it, while [https://xmpp.org/extensions/xep-0045.html#disco-roomitems disco#items on a room] should get you a list of occupants, even though servers generally don't disclose the occupant list this way. It is possible to get the occupant list (presences) by joining the room. This seems to be the only possibly conflicting feature, if a room and a component were to be used on the same address. | |||
Maybe a more explicit disco feature should be added to say "You can create rooms off here". Without this, it isn't possible to say whether room creation is actually possible other than trying and reading the error. It would also probably look very awkward for a client to try to create a room off a "component"/"room" hosted at "foo@domain", trying to create "bar@foo@domain" which isn't a valid JID. | |||
= Joining Cisco Jabber Rooms = | |||
Cisco Jabber will not set `<status code='110'/>` on the joining occupant's self-presence. Therefore, clients will probably not detect the completion of a join. | |||
A possible workaround (looks like all Cisco Jabber rooms are non-anonymous): match on the JID inside the provided `<item role="participant" jid="full-JID" affiliation="none"/>` | |||