When initially run, a messaging client typically shows some list of contacts and chatrooms, and whether any new messages are present in each.
The current mechanism for achieving this UX involves a complete synchronization of the server-side archive, and is both time-consuming and bandwidth-intensive. This specification proposes a solution to directly obtain such data from the server.
Moreover, the information gathered by the server to support this can be used in support of mobile push notifications.
Nomenclature used for instant messages versus ancillary messages will need to be adjusted to make it consistent
with Message Fastening (XEP-0422)
Support for this protocol is advertised by the Service Discovery protocol defined in Service Discovery (XEP-0030)
The Inbox consists semantically of a list of conversations in order of last activity. Each conversation is identified by a jid - for group chats this would be the chatroom, and for individual contacts this would be their bare jid.
Each Inbox entry includes a count of messages considered new, the last MAM stanza-id relating to this conversation,
and the last MAM result for this conversation, as defined by Message Archive Management (XEP-0313)
Finding more messages from this conversation can be achieved via a MAM query using with to specify the conversation required.
An <iq/> of type "get" is used, containing a single element <inbox/>, containing an optional RSM
filter as specified by Result Set Management (XEP-0059)
The server responds with a sequence of <message/> stanzas, each containing an <entry/> element qualified by the urn:xmpp:inbox:1 namespace with a number of attributes:
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 Message Archive Management (XEP-0313)
After all entries required have been returned, the server then responds with an <iq/> result containing a <fin/> element qualified by urn:xmpp:inbox:1. 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.
Servers MUST track which instant messages sent to clients remain unread.
Let us assume a user has only three jids they have exchanged messages with. Asking for their inbox is simple:
The server responds with a list of conversations:
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.
TODO - Hopefully roughly given by the examples.
TODO
This XEP requires no interaction with the Internet Assigned Numbers Authority (IANA)
None.
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.