diff --git a/inbox/muc-selfping.xml b/inbox/muc-selfping.xml new file mode 100644 index 00000000..16cd2284 --- /dev/null +++ b/inbox/muc-selfping.xml @@ -0,0 +1,178 @@ + + +%ents; +]> + + +
+ Schrödinger's Chat + This protocol extension for XEP-0045 Multi User Chat allows clients to check whether they are still joined to a chatroom. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + XEP-0001 + Etc. + + + + muc-selfping + + Georg + Lukas + georg@op-co.de + georg@yax.im + + + 0.0.1 + 2018-07-31 + gl +

First draft.

 + +
+ +

The &xep0045; protocol was + not designed to handle s2s interruptions or message loss well. Rather + often, the restart of a server or a component causes a client to believe + that it is still joined to a given chatroom, while the chatroom service + does not know of this participant.

+

Existing approaches for re-synchronization are either inefficient + (presence updates and "silent" messages are reflected to all participants, + totalling to O(N²) stanzas per time unit), or mask message / + presence losses (the implicit join performed via the deprecated GC1.0 + protocol).

+

This specification aims to provide the most efficient, albeit not the + most elegant, way for clients to periodically check whether they are still + joined to a chatroom.

+ + +

This specification only makes sense in the context of &xep0045; + chatrooms. It makes use of &xep0199; to perform periodic self-pings.

+

Server support for this extension is optional, but will significantly + improve the reliability with Multi-Session Nicks and mobile clients.

+ + +

A typical connection between a client and a Multi-User-Chatroom (MUC) + goes through the client-to-server link, possibly a server-to-server link + and a typically local server-to-component link. If one of the involved + servers or the MUC component is restarted, or one of the links is + disturbed for some time, this can lead to the removal of some or all + participants from the affected MUCs, without the clients being informed.

+

To a participant, this looks like the MUC is silent (there is no chat + activity and no presence changes), making it hard to realize that the + connection was interrupted.

+

To prevent the bad usability effect (message loss, lack of reaction from + people in a chatroom), a client needs to actively check whether it is + still joined to a MUC.

+ +

There are multiple alternative approaches for a client to test whether + it is still joined to a MUC:

+
    +
  1. Silent message (e.g. &xep0085;): this message will be reflected to + all MUC participants, causing unwanted traffic and potentially waking + up mobile devices without reason. If implemented by all clients, this + will result in O(N²) messages to the MUC.
    2. +
  2. Presence update: if the MUC service implements the legacy GC1.0 protocol, + this will be treated as a join attempt, and the MUC will return the + full list of participants and full room history. The user's client + will however miss partial history (other participants leaving, + potentially also messages), and this has the same drawbacks as the + first solution.
    3. +
  3. Private message to self: the client can send a MUC + private message to itself. However, not all MUCs support / allow + private messages, and there is no way to differentiate that from the + error responses.
    4. +
  4. Private IQ to self: the client can send an IQ to + its own participant JID. MUCs typically do not forbid those, and + reflect the IQ request to the client (or another client of the same + user). Once that client responds to the reflected IQ, the response is + delivered to the initiating client as a sign of still being joined. +
    5. +
  5. Dedicated MUC IQ: a new type of IQ can be deployed + to let the client explicitly check whether it is still joined to a + MUC. However, this needs to be supported by the server, and the client + needs to implement a fallback solution.
    6. +
+

The private IQ is the most robust and traffic-efficient solution, and + it does not rely on server support. The &xep0199; protocol is + appropriate to use for this use case.

+ + +

After an adequate amount of silence from a given MUC (e.g. 15 minutes), + or from all MUCs from a given service domain, a client should initiate a + self-ping. If Juliet is joined as JuliC in the + characters@chat.shakespeare.lit MUC, her client will send the following + ping IQ:

+ + + +]]> +

If Juliet's client is not joined, the MUC service will respond with a + <not-acceptable> error. Thus, her client can automatically attempt + a rejoin.

+ + + + + +]]> +

If her client is joined, the IQ request will be forwarded to any one of + Juliet's joined clients.

+ + + +]]> +

Depending on the other client implementation and its connection status, + the IQ will be responded to eventually, in one of these ways, as + delivered to the "client" resource:

+
    +
  • Successful IQ response: the client is still joined.
    • +
  • Error (<service-unavailable> or + <feature-not-implemented>): the client is joined, but + the pinged client does not implement &xep0199;.
    • +
  • Any other error: the client is probably not + joined.
    • +
  • Timeout (no response): the MUC service (or another + client) is unreachable. The client may indicate the status to the user + and re-attempt the self-ping after some timeout, until it receives + either an error or a success response.
    • +
+ + +

The normal routing rules of the self-ping impose two round-trips: first + the initial ping from the client to the MUC, then the reflection of the + ping and its response (possibly to another client), and finally the + response to the initial IQ. If the other client is experiencing network + connectivity issues, which is often the case with mobile devices, the + ping request might never be responded to.

+

Therefore, a MUC service supporting this protocol may directly respond + to a participant's Ping request to the participant's own nickname, as + opposed to routing it to any of the participant's clients.

+ + + +

A MUC service implementation should not allow a non-participant to obtain + information about participants. This is however true irregardless of + implementing this specification.

+ + +

REQUIRED.

+ + +

REQUIRED.

+ + +

REQUIRED for protocol specifications.

+ +