[Standards] Move Carbons to Last Call ("Proposed")

Kevin Smith kevin.smith at isode.com
Wed Aug 12 13:07:44 UTC 2015

The thread is moving somewhat away from Carbons Last Calls, but this is all related so I won’t feel too guilty. I have two opinions here:

1) Carbons is most of the way to solving its part of the problem. I’m happy enough that Carbons is used as the basis for solving that bit (although I originally suggested a new XEP so as not to interfere with Carbons, I have further thought on it, and the changes are not so intrusive that Carbons is the wrong base), and I think it’s right that implementing it now is a good idea.
2) Carbons will need some changes in the (hopefully near) future once the pubsub/account stuff is specced/we have deployment experience. I believe this means that going to Draft now wouldn’t be appropriate, as knowing there will be backwards-incompatible changes is at odds with the Draft requirement of avoiding such things where possible.

Some more thoughts (I am using the term ‘groupchat’ here, as I think I mostly mean MUC2 instead of MUC):

I would like my client to be able to log in, with multiple other clients, and

1) “Catch up” on all history (both groupchat and otherwise) via MAM and store it in a local cache. This is possible with MAM currently, with considerable duplication on the wire*
2) Know about all the pubsub nodes I’m subscribed to (addressed by Dave’s account/pubsub stuff. Watch This Space™)
3) Know about all the groupchat rooms I’m in (addressed by bookmarks kinda, presently. Fully addressed by MUC2/Account/Pubsub)
4) Receive all incoming and outgoing chat messages to the account, including groupchat PMs (Carbons nearly addresses this).
5) Know when my other devices have handled a message so I can cancel any pending OS notifications, and remove any unread hints in the UI (We don’t have this covered yet)

* To solve this duplication we’ll change carbons so that all clients receive all messages that go in the MAM archive (with MUC2 only going in the archive once because of pubsub/account), including your own outgoing messages, and include the archived id so you can do a resync. That, plus the change of how to interact with pubsub/account, is what’s needed for changes to Carbons I think (although implementation experience is going to inform this somewhat).


More information about the Standards mailing list