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 22:13, 28 May 2020
, 22:13, 28 May 2020no 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? = | ||
Current MUC / server implementations do not send offline-presence packets to participants on service restart. Therefore, a client will think it is still joined to a MUC indefinitely. | Current MUC / server implementations do not send offline-presence packets to participants on service restart. Therefore, a client will think it is still joined to a MUC indefinitely, only seeing silence. | ||
There is no portable/reliable mechanism to check if the client is still joined, and no clean way to re-sync the state if it is not joined. | There is no portable/reliable mechanism to check if the client is still joined, and no clean way to re-sync the state if it is not joined. | ||
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 | This is solved by [https://xmpp.org/extensions/xep-0410.html XEP-0410: MUC Self-Ping] | ||
= MUC double join = | |||
This has been fixed in revision 1.29 of XEP-0045: | |||
It's not specified what should happen if an entity sends an initial presence when it's already joined. | It's not specified what should happen if an entity sends an initial presence when it's already joined. Server implementations should behave towards the joining entity like it successfully joined. That means, if a presence update containing an <x> element is received from a participant, the server should send back the full presence list, the requested amount of history and the room subject. | ||
= MUC PM messages are not distinguishable from other MUC messages = | = MUC PM messages are not distinguishable from other MUC messages = | ||
http://mail.jabber.org/pipermail/standards/2015-May/029819.html | http://mail.jabber.org/pipermail/standards/2015-May/029819.html | ||
= 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"/>` | |||