[Standards] MUC 2

Dave Cridland dave at cridland.net
Thu Feb 12 12:40:16 UTC 2015


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150212/1f40e45e/attachment.html>


More information about the Standards mailing list