On Wed, 29 May 2019 at 12:27, Ненахов Андрей <[email protected]> wrote:
> 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. > > Right - I knew you had this but had forgotten. It'd be great to collate all these ideas and pick the best bits from them all. Just a high-level technical sketch would be really useful. > ср, 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] > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
