We have this (not exactly this, but for the very same purpose) mostly implemented and already working, would be happy to share the results with everyone. Currently, it's implemented on a server, client support (in Web version of Xabber) will arrive in a week or two. We also plan to release an open-source server (ejabberd fork) that will support this.
Problem is, we definitely lack skills putting this as a 'XEP' formatted thing with proper description, and, what's worse, current documentation is mostly in Russian, but XMLs are in english and if someone would volunteer help us putting it in a XEP-like way, I'll muster myself to translate crucial bits into English. ср, 29 мая 2019 г. в 16:12, Dave Cridland <[email protected]>: > 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] > _______________________________________________ > -- Andrew Nenakhov CEO, Redsolution, Inc. https://redsolution.com <http://www.redsolution.com>
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
