diff --git a/xep-0430.xml b/xep-0430.xml index 1775675e..56ecdaeb 100644 --- a/xep-0430.xml +++ b/xep-0430.xml @@ -2,7 +2,7 @@ %ents; - + ]> @@ -23,6 +23,19 @@ inbox &dcridland; + + 0.2.0 + 2020-02-03 + dwd + Updates from the Summit 24 discussion: +
    +
  • Remove Marked
    • +
  • Metadata in sibling
    • +
  • Ensure the last "mam id" is present in metadata, and describe how that can be used.
    • +
  • Add options to control unread-only and elide messages.
    • +
+ + 0.1.0 2020-01-29 @@ -74,30 +87,26 @@

An &IQ; of type "get" is used, containing a single element <inbox/>, containing an optional RSM - filter as specified by &xep0059;. This will typically be sent only to the user's own bare jid. The server + filter as specified by &xep0059;. This will typically be sent only to the user's own bare jid. If a client + requests the inbox without RSM, the server MAY limit the number of conversations arbitrarily by either time or number. This element has a number of attributes:

+
    +
  • unread-only - Defaults to false. If true, the server will list only conversations with at least one unread message.
    • +
  • messages - Defaults to true. If true, the server includes the last message; if false, this is elided.
    • +
+

The server responds with a sequence of &MESSAGE; stanzas, each containing an <entry/> element qualified by the &ns; namespace with a number of attributes:

  • jid - contains the Jid of the conversation for this entry.
    • -
  • unread - contains a count of messages which are deemed to be unread by the server.
    • -
  • marked - a boolean indicating that a client has explicitly marked the conversation for some reason.
    • +
  • unread - contains a count of messages which are deemed to be unread by the server. Clients may use this to indicate unread messages to the user.
    • +
  • id - contains the last id in the MAM archive for this conversation. Clients may use this as a marker to fetch additional messages (or collated fastenings, see &xep0427;) about the conversation via MAM.
-

The <entry/> element contains the latest instant message, if any, which is encapsulated as a +

If the messages attribute is missing or set to true, the <entry/> element is followed by the latest instant message, if any, which is encapsulated as a <result/> element as defined by &xep0313;. This contains collated fastenings if supported by the server.

After all entries required have been returned, the server then responds with an &IQ; result containing a <fin/> element qualified by &ns;. This contains the RSM data, a total count of conversation entries within the inbox, a count of conversations with unread messages, and a total count of unread messages.

-

Any counter of unread SHOULD be accurate, however client implementors please note that due to heuristics - involved and other issues these counters can be inaccurate at times.

- - -

A client MAY at any time set a conversation as marked by sending an &IQ; of type "set" containing something or - other. This causes the server to set the "marked" flag on a conversation. A client SHOULD display a marked - conversation in the same way as an unread conversation, and explicitly removed the marked flag when the - conversation is considered re-read.

-

Removing a marked flag, even when the conversation is not currently marked, causes the unread counter for that - conversation to be set to zero.

 @@ -108,14 +117,14 @@
  • An instant message always starts unread.
  • A Chat Marker (see &xep0333;) of "displayed" or "acknowledged" causes the message to be read (and also causes all prior messages to be read by implication).
    • -
  • A Message Receipt (see &xep0184;) does not cause messages to be considered unread. Perhaps it should?
    • +
  • A Message Receipt (see &xep0184;) does not cause messages to be considered unread.
  • Unmarking a conversation always sets the unread counter to zero, and by implication sets all messages to be read.
    • -

    Let us assume a user has only two contacts they have exchanges messages with, and a single chatroom. Asking for their inbox is simple:

    +

    Let us assume a user has only three jids they have exchanged messages with. Asking for their inbox is simple:

    @@ -124,21 +133,43 @@

    The server responds with a list of conversations:

    - - - - - Greetings from Alpha Centauri! - - - - + + + + + Greetings from Alpha Centauri! + + + + + + + + + + + Greetings from Mars! + + + + + + + + + + + Greetings from Somewhere Else! + + + ]]> -

    After the list of messages, the server completes its response with a the reply to the original IQ.

    +

    If the id of a conversation has changed, a client might fetch the missing messages and metadata by requesting the MAM archive with the jid of the entry, and after the previous known id for the conversation.

    +

    After the list of conversations, the server completes its response with a the reply to the original IQ.

    - + ]]> @@ -161,7 +192,7 @@     -

    The author notes that this protocol is heavily based on the mod_inbox system of MongooseIM. In addition, Kevin Smith provided useful feedback which has shaped this specification.

    +

    The author notes that this protocol is heavily based on the mod_inbox system of MongooseIM. In addition, Kevin Smith and several others at the XMPP Summit 24 provided useful feedback which has shaped this specification.