From 11bf5c82fba0f46eb6e5560213d508fea4941396 Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Mon, 30 Jul 2018 14:03:36 +0200 Subject: [PATCH 01/16] XEP-0045: first and early attempt at removing GC1.0 --- xep-0045.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xep-0045.xml b/xep-0045.xml index 311d278a..048675d9 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -515,7 +515,7 @@ -

Traditionally, instant messaging is thought to consist of one-to-one chat rather than many-to-many chat, which is called variously "groupchat" or "text conferencing". Groupchat functionality is familiar from systems such as Internet Relay Chat (IRC) and the chatroom functionality offered by popular consumer IM services. The Jabber/XMPP community developed and implemented a basic groupchat protocol as long ago as 1999. That "groupchat 1.0" (GC) protocol provided a minimal feature set for chat rooms but was rather limited in scope. This specification (Multi-User Chat or MUC) builds on the older groupchat 1.0 protocol in a backwards-compatible manner but provides advanced features such as invitations, room moderation and administration, and specialized room types.

+

Traditionally, instant messaging is thought to consist of one-to-one chat rather than many-to-many chat, which is called variously "groupchat" or "text conferencing". Groupchat functionality is familiar from systems such as Internet Relay Chat (IRC) and the chatroom functionality offered by popular consumer IM services. The Jabber/XMPP community developed and implemented a basic groupchat protocol as long ago as 1999. That "groupchat 1.0" (GC) protocol provided a minimal feature set for chat rooms but was rather limited in scope. This specification (Multi-User Chat or MUC) is not compatible to the groupchat 1.0 protocol, but provides advanced features such as invitations, room moderation and administration, and specialized room types.

 @@ -579,7 +579,7 @@
Ban
To remove a user from a room such that the user is not allowed to re-enter the room (until and unless the ban has been removed). A banned user has an affiliation of "outcast".
Bare JID
The <user@host> by which a user is identified outside the context of any existing session or resource; contrast with Full JID and Occupant JID.
Full JID
The <user@host/resource> by which an online user is identified outside the context of a room; contrast with Bare JID and Occupant JID.
 -
GC
The minimal "groupchat 1.0" protocol developed within the Jabber community in 1999; MUC is backwards-compatible with GC.
 +
GC
The minimal "groupchat 1.0" protocol developed within the Jabber community in 1999; Old versions of MUC were backwards-compatible with GC.
History
A limited number of message stanzas sent to a new occupant to provide the context of current discussion.
Invitation
A special message sent from one user to another asking the recipient to join a room; the invitation can be sent directly (see &xep0249;) or mediated through the room (as described under Inviting Another User to a Room).
IRC
Internet Relay Chat.
 From a3dc32643c33282f474568f2100779f93a111deb Mon Sep 17 00:00:00 2001 From: Kevin Smith Date: Fri, 8 Mar 2019 14:32:37 +0000 Subject: [PATCH 02/16] Clarify correcting a message multiple times --- xep-0308.xml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/xep-0308.xml b/xep-0308.xml index 92a7cb74..d76dda84 100644 --- a/xep-0308.xml +++ b/xep-0308.xml @@ -21,6 +21,12 @@ message-correct &ksmith; + + 1.1 + 2019-03-08 + kis +

Clear up confusion about subsequent corrections and ids (it's the payloads getting replaced, not the message identity).

 + 1.0 2013-04-08 @@ -98,6 +104,7 @@

A single message may be corrected multiple times by subsequent edits.

A correction MUST only be allowed when both the original message and correction are received from the same full-JID.

While it's not possible to prevent this protocol from being used in such a way, it is not intended that it provides a way to continue expanding a previous message indefinitely and clients, in as much as it is sensible, should present use of this extension only for correction rather than for providing a continuous stream, for which &xep0301; can be used instead.

+

If the same message is to be corrected several times, the id of the original message is used in each case (e.g. If a message of id 1 is corrected by a message of id 2, a subsequent correction should correct 1, not 2).

Correction MUST only be used to change the details of a stanza (e.g. the message body) and not to change the nature of the stanza (e.g. correction MUST NOT be used to turn a chat message into a pubsub notification)

While it is possible to use this protocol to correct messages older than the most recent received from a full JID, such use is out of scope for this document and support for this SHOULD NOT be assumed without further negotiation.

 From 050608311a4dcda204a6ef7398c412b570fa9ee2 Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Tue, 15 Jan 2019 16:34:51 +0100 Subject: [PATCH 03/16] XEP-0184: add a box about types and JIDs --- xep-0184.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/xep-0184.xml b/xep-0184.xml index 1c3a81cb..a7e0a11c 100644 --- a/xep-0184.xml +++ b/xep-0184.xml @@ -204,6 +204,7 @@ ]]>

When the recipient sends an ack message, it SHOULD ensure that the message stanza contains only one child element, namely the <received/> element qualified by the 'urn:xmpp:receipts' namespace. In addition, it SHOULD include an 'id' attribute that echoes the 'id' attribute of the content message. Naturally, intermediate entities might add other extension elements to the message when routing or delivering the receipt message, e.g., a <delay/> element as specified in &xep0203;.

+

Note: It is a good practice to use the same message type as the message that requested the receipt, however a client should also accept receipts with a different message type. When sending a Receipt for a type='groupchat' message (which is NOT RECOMMENDED), the Receipt must be sent to the bare JID of the room and not to the full JID of the sender.

From fefccb8cc546bba0c3feed680aa7673781dd54ce Mon Sep 17 00:00:00 2001 From: Kevin Smith Date: Tue, 9 Apr 2019 12:05:38 +0100 Subject: [PATCH 04/16] XEP-0308. Don't change metadata on correction --- xep-0308.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0308.xml b/xep-0308.xml index d76dda84..14240748 100644 --- a/xep-0308.xml +++ b/xep-0308.xml @@ -105,7 +105,7 @@

A correction MUST only be allowed when both the original message and correction are received from the same full-JID.

While it's not possible to prevent this protocol from being used in such a way, it is not intended that it provides a way to continue expanding a previous message indefinitely and clients, in as much as it is sensible, should present use of this extension only for correction rather than for providing a continuous stream, for which &xep0301; can be used instead.

If the same message is to be corrected several times, the id of the original message is used in each case (e.g. If a message of id 1 is corrected by a message of id 2, a subsequent correction should correct 1, not 2).

-

Correction MUST only be used to change the details of a stanza (e.g. the message body) and not to change the nature of the stanza (e.g. correction MUST NOT be used to turn a chat message into a pubsub notification)

+

Correction MUST only be used to change the logical content details of a stanza (e.g. the message body) and not to change the nature of the stanza or its metadata (e.g. correction MUST NOT be used to turn a chat message into a pubsub notification). Where a correction stanza includes metadata, for example stanza or MAM ids, these are properties of the correction stanza, and do not correct aspects of the original stanza.

While it is possible to use this protocol to correct messages older than the most recent received from a full JID, such use is out of scope for this document and support for this SHOULD NOT be assumed without further negotiation.

 From fe8a1ad143124d3cd554c6aa20c6480265984d58 Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Wed, 17 Apr 2019 07:35:10 +0200 Subject: [PATCH 05/16] XEP-0308: relax from-full-JID requirement --- xep-0308.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0308.xml b/xep-0308.xml index 92a7cb74..b84c455f 100644 --- a/xep-0308.xml +++ b/xep-0308.xml @@ -96,7 +96,7 @@

To deal with multiple payloads, the sender MUST re-send the entire stanza, only altering id and the payloads being corrected and adding the 'replace' payload. It is expected that the receiver SHOULD then treat the new stanza as complete replacement for all the payloads received in the original stanza.

The Sender MUST NOT include a correction for a message with non-messaging payloads. For example, a sender MUST NOT include a correction for a roster item exchange request or a file transfer part.

A single message may be corrected multiple times by subsequent edits.

-

A correction MUST only be allowed when both the original message and correction are received from the same full-JID.

+

A correction MUST only be allowed when both the original message and correction originate from the same senderIn direct conversations, this means the bare-JID must match the original bare-JID, in MUCs and MUC-PMs the correction's full-JID must match the original full-JID, and either the recipient or the MUC service need to ensure that the real bare JID of the sending occupant didn't change in between..

While it's not possible to prevent this protocol from being used in such a way, it is not intended that it provides a way to continue expanding a previous message indefinitely and clients, in as much as it is sensible, should present use of this extension only for correction rather than for providing a continuous stream, for which &xep0301; can be used instead.

Correction MUST only be used to change the details of a stanza (e.g. the message body) and not to change the nature of the stanza (e.g. correction MUST NOT be used to turn a chat message into a pubsub notification)

While it is possible to use this protocol to correct messages older than the most recent received from a full JID, such use is out of scope for this document and support for this SHOULD NOT be assumed without further negotiation.

From 4a71e3b82b6e15c39051d3295bfaf65cc223c37e Mon Sep 17 00:00:00 2001 From: Kim Alvefur Date: Wed, 17 Apr 2019 22:41:32 +0200 Subject: [PATCH 06/16] XEP-0045: Move section about GC 1.0 further down It's weird that the first thing you see under "Entering a room" is how to do it in the old way, instead of the new way, which might mislead implementers and make them miss the new way entirely. --- xep-0045.xml | 39 +++++++++++++++++++++------------------ 1 file changed, 21 insertions(+), 18 deletions(-) diff --git a/xep-0045.xml b/xep-0045.xml index 048675d9..ce60cd8e 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -1397,15 +1397,22 @@ - -

In order to participate in the discussions held in a multi-user chat room, a user MUST first become an occupant by entering the room. In the old groupchat 1.0 protocol, this was done by sending presence with no 'type' attribute to &OCCUPANTJID;, where "room" is the room ID, "service" is the hostname of the chat service, and "nick" is the user's desired nickname within the room:

- +

In order to participate in the discussions held in a multi-user chat room, a user MUST first become an occupant by entering the room.

+ +

MUC clients MUST signal their ability to speak the MUC protocol by including in the initial presence stanza an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace (note the absence of the '#user' fragment):

+ + id='n13mt3l' + to='coven@chat.shakespeare.lit/thirdwitch'> + + ]]> +

In this example, a user with a full JID of "hag66@shakespeare.lit/pda" has requested to enter the room "coven" on the "chat.shakespeare.lit" chat service with a room nickname of "thirdwitch".

+

Note: The presence stanza used to join a room MUST NOT possess a 'type' attribute, i.e., it must be available presence. For further discussion, see the Presence business rules.

+

If the user does not specify a room nickname (note the bare JID on the 'from' address in the following example), the service MUST return a &badjid; error:

-]]> -

Note: The presence stanza used to join a room MUST NOT possess a 'type' attribute, i.e., it must be available presence. For further discussion, see the Presence business rules.

- - - -

Compliant multi-user chat services MUST accept the foregoing as a request to enter a room from any client that knows either the groupchat 1.0 protocol or the multi-user chat (MUC) protocol; however, MUC clients SHOULD signal their ability to speak the MUC protocol by including in the initial presence stanza an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace (note the absence of the '#user' fragment):

- - - ]]>

Before attempting to enter the room, a MUC-compliant client SHOULD first discover its reserved room nickname (if any) by following the protocol defined in the Discovering Reserved Room Nickname section of this document.

When a MUC service receives an <x/> tagged join stanza from an already-joined client (as identified by the client's full JID), the service should assume that the client lost its synchronization, and therefore it SHOULD send exactly the same stanzas to the client as if it actually just joined the MUC. The server MAY also send a presence update to the other participants according to the received join presence.

@@ -1903,6 +1897,15 @@ + +

In the old groupchat 1.0 protocol, this was done by sending presence with no 'type' attribute to &OCCUPANTJID;, where "room" is the room ID, "service" is the hostname of the chat service, and "nick" is the user's desired nickname within the room:

+ +]]> + From 45e050c9c6052a628eade566952b2d3eab98735f Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Thu, 18 Apr 2019 00:29:49 +0200 Subject: [PATCH 07/16] XEP-0045: fix wording in GC1.0 join --- xep-0045.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0045.xml b/xep-0045.xml index ce60cd8e..8412d251 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -1898,7 +1898,7 @@ -

In the old groupchat 1.0 protocol, this was done by sending presence with no 'type' attribute to &OCCUPANTJID;, where "room" is the room ID, "service" is the hostname of the chat service, and "nick" is the user's desired nickname within the room:

+

In the old groupchat 1.0 protocol, entering a room was done by sending presence with no 'type' attribute to &OCCUPANTJID;, where "room" is the room ID, "service" is the hostname of the chat service, and "nick" is the user's desired nickname within the room:

Date: Thu, 18 Apr 2019 00:37:29 +0200 Subject: [PATCH 08/16] XEP-0045: respond to GC1.0 join with kick, thx Kev --- xep-0045.xml | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/xep-0045.xml b/xep-0045.xml index 8412d251..18fceabc 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -1904,6 +1904,21 @@ from='hag66@shakespeare.lit/pda' id='ng91xs69' to='coven@chat.shakespeare.lit/thirdwitch'/> +]]> +

This behavior can not be distinguished from a presence update from a MUC-supporting client that was desynchronized from the room. Treating this as a groupchat 1.0 join will mask the error and leave the client in a partially-synchronized state. Therefore, starting with version 1.32 of this specification, it is RECOMMENDED that a service receiving a <presence> without an <x> element responds with an explicit kick to that client.

+ + + + You are not in the room. + + + + + ]]> From 5282243d5d4a4e0249aa08b879b4c8f9ef918da6 Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Thu, 18 Apr 2019 00:41:10 +0200 Subject: [PATCH 09/16] XEP-0045: do not claim compatibility with GC1.0 --- xep-0045.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0045.xml b/xep-0045.xml index 18fceabc..a5d819ed 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -534,7 +534,7 @@ -

This document addresses the minimal functionality provided by Jabber-based multi-user chat services that existed in 2002 when development of MUC began. For the sake of backwards-compatibility, this document uses the original groupchat 1.0 protocol for this baseline functionality, with the result that:

+

This document addresses the minimal functionality provided by Jabber-based multi-user chat services that existed in 2002 when development of MUC began. This design is based on the original groupchat 1.0 protocol, with the result that:

  • Each room is identified as a "room JID" &ROOMJID; (e.g., <jdev@conference.jabber.org>), where "room" is the name of the room and "service" is the hostname at which the multi-user chat service is running.
  • Each occupant in a room is identified as an "occupant JID" &OCCUPANTJID;, where "nick" is the room nickname of the occupant as specified on entering the room or subsequently changed during the occupant's visit.
    • From 84674a922133ac1cbee98f46ee2e0d87214f5fda Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Thu, 18 Apr 2019 09:26:22 +0200 Subject: [PATCH 10/16] =?UTF-8?q?XEP-0045:=20restrict=20gc1=20kick=20to=20?= =?UTF-8?q?non-occupant=20full-JIDs,=20thx=20jonas=E2=80=99?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- xep-0045.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0045.xml b/xep-0045.xml index a5d819ed..3c2ca400 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -1905,7 +1905,7 @@ id='ng91xs69' to='coven@chat.shakespeare.lit/thirdwitch'/> ]]> -

    This behavior can not be distinguished from a presence update from a MUC-supporting client that was desynchronized from the room. Treating this as a groupchat 1.0 join will mask the error and leave the client in a partially-synchronized state. Therefore, starting with version 1.32 of this specification, it is RECOMMENDED that a service receiving a <presence> without an <x> element responds with an explicit kick to that client.

    +

    This behavior can not be distinguished from a presence update from a MUC-supporting client that was desynchronized from the room. Treating this as a groupchat 1.0 join will mask the error and leave the client in a partially-synchronized state. Therefore, starting with version 1.32 of this specification, it is RECOMMENDED that a service receiving a <presence> without an <x> element from a non-occupant full-JID responds with an explicit kick to that client.

    Date: Thu, 18 Apr 2019 12:25:02 +0200 Subject: [PATCH 11/16] XEP-0045: add 333 status to gc1-kick, thx Kev --- xep-0045.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xep-0045.xml b/xep-0045.xml index 3c2ca400..50db66d6 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -1905,7 +1905,7 @@ id='ng91xs69' to='coven@chat.shakespeare.lit/thirdwitch'/> ]]> -

    This behavior can not be distinguished from a presence update from a MUC-supporting client that was desynchronized from the room. Treating this as a groupchat 1.0 join will mask the error and leave the client in a partially-synchronized state. Therefore, starting with version 1.32 of this specification, it is RECOMMENDED that a service receiving a <presence> without an <x> element from a non-occupant full-JID responds with an explicit kick to that client.

    +

    This behavior can not be distinguished from a presence update from a MUC-supporting client that was desynchronized from the room. Treating this as a groupchat 1.0 join will mask the error and leave the client in a partially-synchronized state. Therefore, starting with version 1.32 of this specification, it is RECOMMENDED that a service receiving a <presence> without an <x> element from a non-occupant full-JID responds with an explicit kick to that client. The kick MUST contain the status codes 110 (occupant's presence), 307 (kick), and 333 (kick due to technical problems).

    + ]]> From 171db7f20dc4415cf3286eec2fb4f0b96c36315a Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Wed, 24 Apr 2019 07:16:19 +0200 Subject: [PATCH 12/16] XEP-0308: incorporate Council feedback, remove dep on #736 --- xep-0308.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0308.xml b/xep-0308.xml index b84c455f..711a7276 100644 --- a/xep-0308.xml +++ b/xep-0308.xml @@ -96,7 +96,7 @@

    To deal with multiple payloads, the sender MUST re-send the entire stanza, only altering id and the payloads being corrected and adding the 'replace' payload. It is expected that the receiver SHOULD then treat the new stanza as complete replacement for all the payloads received in the original stanza.

    The Sender MUST NOT include a correction for a message with non-messaging payloads. For example, a sender MUST NOT include a correction for a roster item exchange request or a file transfer part.

    A single message may be corrected multiple times by subsequent edits.

    -

    A correction MUST only be allowed when both the original message and correction originate from the same senderIn direct conversations, this means the bare-JID must match the original bare-JID, in MUCs and MUC-PMs the correction's full-JID must match the original full-JID, and either the recipient or the MUC service need to ensure that the real bare JID of the sending occupant didn't change in between..

    +

    A correction MUST only be allowed when both the original message and correction originate from the same senderIn direct conversations, this means the bare-JID must match the original bare-JID, in MUCs and MUC-PMs the correction's full-JID must match the original full-JID, and the recipient needs to ensure that the real bare JID of the sending occupant didn't change in between, e.g. by keeping track of leave/join presences..

    While it's not possible to prevent this protocol from being used in such a way, it is not intended that it provides a way to continue expanding a previous message indefinitely and clients, in as much as it is sensible, should present use of this extension only for correction rather than for providing a continuous stream, for which &xep0301; can be used instead.

    Correction MUST only be used to change the details of a stanza (e.g. the message body) and not to change the nature of the stanza (e.g. correction MUST NOT be used to turn a chat message into a pubsub notification)

    While it is possible to use this protocol to correct messages older than the most recent received from a full JID, such use is out of scope for this document and support for this SHOULD NOT be assumed without further negotiation.

    From 59a14e2167d396ab1732fc33aecddd9328119e72 Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Wed, 24 Apr 2019 17:11:56 +0200 Subject: [PATCH 13/16] XEP-0184: fix should into SHOULD, thx Kev --- xep-0184.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0184.xml b/xep-0184.xml index a7e0a11c..f812e4ec 100644 --- a/xep-0184.xml +++ b/xep-0184.xml @@ -204,7 +204,7 @@ ]]>

    When the recipient sends an ack message, it SHOULD ensure that the message stanza contains only one child element, namely the <received/> element qualified by the 'urn:xmpp:receipts' namespace. In addition, it SHOULD include an 'id' attribute that echoes the 'id' attribute of the content message. Naturally, intermediate entities might add other extension elements to the message when routing or delivering the receipt message, e.g., a <delay/> element as specified in &xep0203;.

    -

    Note: It is a good practice to use the same message type as the message that requested the receipt, however a client should also accept receipts with a different message type. When sending a Receipt for a type='groupchat' message (which is NOT RECOMMENDED), the Receipt must be sent to the bare JID of the room and not to the full JID of the sender.

    +

    Note: It is a good practice to use the same message type as the message that requested the receipt, however a client SHOULD also accept receipts with a different message type. When sending a Receipt for a type='groupchat' message (which is NOT RECOMMENDED), the Receipt must be sent to the bare JID of the room and not to the full JID of the sender.

    From e61d13f60a1c2d50f39fc7af9604cd9b4891ab5c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Wed, 15 May 2019 17:34:20 +0200 Subject: [PATCH 14/16] XEP-0045: add revision block --- xep-0045.xml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/xep-0045.xml b/xep-0045.xml index 50db66d6..ee957e72 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -45,6 +45,12 @@ &stpeter; + + 1.32.0 + 2019-05-15 + gl +

    Remove Group Chat 1.0 compatibility due to operational issues.

     +     1.31.2 2018-07-31 From e448d938e9eed8c274603c4bfc80e3f8237e29b0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Wed, 15 May 2019 17:42:11 +0200 Subject: [PATCH 15/16] XEP-0184: add revision block --- xep-0184.xml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/xep-0184.xml b/xep-0184.xml index f812e4ec..c7ceb52c 100644 --- a/xep-0184.xml +++ b/xep-0184.xml @@ -27,6 +27,12 @@ &stpeter; &hildjj; + + 1.3.0 + 2019-05-15 + gl +

    Suggest a message type to use for replies.

     +     1.2 2011-03-01 From f40cf30b90dae717026344e04dd59a3d5029ec89 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Wed, 15 May 2019 17:50:46 +0200 Subject: [PATCH 16/16] XEP-0308: amend revision block for merge --- xep-0308.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/xep-0308.xml b/xep-0308.xml index d46d30f6..fcdf87d5 100644 --- a/xep-0308.xml +++ b/xep-0308.xml @@ -22,10 +22,10 @@ message-correct &ksmith; - 1.1 - 2019-03-08 - kis -

    Clear up confusion about subsequent corrections and ids (it's the payloads getting replaced, not the message identity).

     + 1.1.0 + 2019-05-15 + kis, gl +

    Clear up confusion about subsequent corrections and ids (it's the payloads getting replaced, not the message identity). Allow corrections from the bare JID unless for group chats.

         1.0