Having spent a while playing with - gasp! - non-XMPP based chat systems,
I'm quite taken with the notion that some kind of Inbox might be rather
useful to us.
Currently, there is Erlang Solutions (ESL)'s Inbox, which is essentially a
duplication of MAM with some chat state tracking. It's more than just that,
of course, but the essential concept I see is that it's a different, but
largely equivalent interface to MAM, with the concept of an unread counter
added.
Instagram, on the other hand, has no roster, as such, and its Inbox simply
lists (recent) conversations, in much the same way as a client might
display them. Each record contains the conversation's participants, and the
most recent message. Things like presence subscription, in the Instagram
model, are simply the open conversations.
We do have a roster, of course, and we're putting more things into it - MIX
channels, MUC Light in ESL's case, and so on.
This makes me wonder if the right way to design an Inbox is actually to
enhance our Roster with MAM and state awareness, and make it the
conversation information hub for IM.
Let's suppose that the nature of what is "unread" is equivalent across all
clients of a particular user, to begin with.
If a client requests the inbox "since" a particular point, it would then
receive a series of records:
First, a set of N records similar to a roster item, containing a jid,
subscription state, the last archive-id received in the conversation, and
the number of unacknowledged (by some definition) messages. Our roster also
includes groups and a name; we could also include the type (MUC, MIX, or a
user), the full message, etc - these are all optimisations.
We do not, actually, need the numbers of unread messages - a client seeing
that the last archive-id isn't in its cache knows the conversation has
messages that are unread to it, at least. But if we can track message read
state, that's useful for multi-device.
Finally, an update message to indicate the current point, where things
change. I would use an archive-id again here - even if the thing causing
the update isn't an archived message at all. This allows a client to ask
for the archive either since a particular message, or since an event.
You'll note I'm not building this directly on PubSub in the XEP-0060 (or
XEP-0163) sense - instead I'm proposing building this on the existing
Roster and MAM.
So:
<iq type='get' id='some-id'>
<query xmlns='jabber:iq:roster' ver='last-archive-id'>
<inbox xmlns='urn:xmpp:inbox'><!-- Add enhanced inbox info -->
<messages/><!-- Include the entire last message? -->
<unread/><!-- Include unread count -->
</inbox>
</query>
</iq>
I'd dearly love to return updates using <message/>, MAM-style, actually.
But let's say we stick with the roster design, the pushes look like:
<iq from='[email protected]' id='b2gs90j5' to='[email protected]/home'
type='set'>
<query xmlns='jabber:iq:roster' ver='ver42'>
<item jid='[email protected]' subscription='both'>
<unread count='4'/>
<stanza-id id='ver42' xmlns='...'/>
<message ...>
<body>Yeah, sure - whenever you like.</body>
</message>
</query>
</iq>
Any message "counts" for updating the roster version, by dint of unifying
the namespace of stanza-id (for archive) and roster version. So any new
message arriving updates the current point of the roster as well, and any
new change in the roster changes the archive pointer similarly.
Updating the shared unread count could be by Carbonizing the read-receipts
(or similar), and using the stanza-id from that, or by an explicit roster
push. Either's good - I think the roster pushes are more explicit, which is
helpful.
I'm fully expecting some push-back here. Comments are, of course, welcome.
Dave.
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
