At the summit, a bunch of us decided to have a serious effort at a redesign of multi user chat, to address shortcomings and emerging use cases.
The overall model was a service domain which exposed, at bare jid level, a set of rooms, which acted more or less as pubsub services, with subsidiary nodes exposing information such as messages, occupants, and so on. I think this general concept would work well for both traditional chatrooms and the different demands of things like buddy cloud. Unifying MUC and buddy cloud is a personal goal, but I think it's a useful yardstick to see if we're capturing the use cases right. However, this model doesn't address three other use cases I feel are important. Firstly, there's XEP-0277, which I suspect fits in the same concept. Secondly, multi party chat. I'm using the term multi party chat to mean ephemeral conversations between more than two people. Currently these are handled, badly, by hosting the conversation on an existing third party chatroom service. This means that one participant locates a chatroom service and invites the other; meaning the first party needs to use a server that has a chatroom service, and the second party needs to be willing to use it. I suspect that both of these use cases are addressed, at least partly, by being able to host chatrooms on the pep service of the user. This means, possibly, making the model one of a single pubsub mode with multiple strands of publication, which I've previously called facets. The third missing use case is that I'd like to have room level federation in from the outset. It's proven really hard to retro fit, and it's work usefully in the multi party chat scenario, too, as well as several other use cases. Dave.
