[Standards] Distributed chatrooms in PSYC

Michael Laukner laukner at googlemail.com
Sun Feb 28 13:16:43 UTC 2010


Sorry for jumping into the rather technical discussion as a bold user
;-)  We are trying to migrate our users from IRC to XMPP and I have
therefore looked into the DMUC draft some time ago. Since there was no
activity on this XEP draft and (more importantly) no reference
implementation we considered DMUC as a dead and implemented some
simple discovery support for 'remote' chat rooms in the client.

Like Kevin, I was also thinking using DNS SRV records to help
automating the discovery of 'remote' chat rooms. At the moment our
user has to 'know' a master's FQDN.

Our users say that mIRC is the world-leading standard against which
any XMPP solution will be measured.   Specifically, the baseline
standard must offer the same or better functionality as it is accepted
that there are currently two main backbone comms systems (XMPP and
IRC).  This is a bold statement but very much the reality for our
users.

Please keep up the good discussion.

Michael

On Fri, Feb 26, 2010 at 2:37 PM, Philipp Hancke
<fippo at goodadvice.pages.de> wrote:
> Peter Saint-Andre wrote:
>>
>> I want to make it clear at the start that the main driver for
>> distributed MUC is not the desire for an Internet-wide federation with
>> stable masters that have good connectivity and never get into trouble.
>> Instead, the people who want distributed MUC are mostly interested in
>> the problem of endpoints or slaves that lose connectivity to the broader
>> network because they are on distressed networks. That kind of scenario
>> might lead to very different assumptions and requirements. So we need to
>> think clearly about what we're trying to achieve before we go down the
>> path of designing something.
>
> Aye. fup2 muc@
>
> Some basic design considerations first. Note that I am using the
> master/slave vocabulary instead of source/shadow, but I mean the same
> thing.
>
> On-the-fly creation of slaves is probably the way to go, we've stopped using
> manual master/slave trees in 2003. We usually use a master-submit strategy,
> where every stanza is routed through the master, with additional
> clustering/fallback strategies at the master level to avoid the single point
> of failure.
>
> How the messages travel from master to each slave (and individual users) is
> another issue. Top-down spanning trees are a quite good solution, easy to
> implement and can even be used to route around communication failures
> between two domains (as long as both parties can still contact a third
> party). Other architectures may provide more resilience but require methods
> to detect and filter duplicates.
>
> Resilience (or "split mode") as described by you is still possible, but has
> turned out to be dangerous for IRC. In a closed environment this is no
> problem however.
>
> On the C2S level the assumption that the slaves are within the same domain
> as the user and can therefore "fake" addresses is useful. The whole dmuc
> issue can (and should) be handled transparently for the user, which reduces
> the specification requirement to the master/slave protocol.

Fully agree, a user should see only one chat room list. A room may be
marked as 'local' or 'remote'.

Not sure if I understand the UUID approach and how the human-readable
name of the room and MUC service name are preserved: "The room IDs of
source rooms SHOULD be opaque to users and unique across all possible
peerhosts, for example by generating a UUID in accordance with RFC
4122 [2] or by hashing the human-readable name of the room using the
SHA-256 algorithm in accordance with SHA  [3]."

A single XMPP server may serve multiple MUC services like e.g.
Openfire. This should maybe clarified under 2.2. Entities:

room JID: darkcave at chat.example.com
master JID: f609923deb78718a125b93d32609bd5265dd927242ac93a99eb366109df2bd39 at chat.firsthost.example.com
or
f609923deb78718a125b93d32609bd5265dd927242ac93a99eb366109df2bd39 at firsthost.example.com
or

shadow JIDs: f609923deb78718a125b93d32609bd5265dd927242ac93a99eb366109df2bd39 at conference.peer1.example.net
and f609923deb78718a125b93d32609bd5265dd927242ac93a99eb366109df2bd39 at chat.peer2.example.org

>
> The join flow I would propose is (since the join is the essential problem,
> let us make sure that we're agreeing on that before continuing):
>
> User sends presence to the master. The master then determines if there is a
> peerhost available in the users domain (an alternative here: the peerhost
> intercepts the stanza locally and it is then forwarded to the master by the
> slave - however, that requires the peerhost to know that the user intends to
> join a muc room, that this muc room is dmuc-capable etc.
>
> If there is a peerhost, the master creates a slave on the peerhost and sends
> room roster and discussion history to the peerhost (if necessary). After
> that, the master sends the slave a message to inform the slave that the user
> has joined the room. The slave then sends the room roster to the user,
> followed by the users presence and discussion history. Note that the master
> does not need to resend the room roster or discussion history to the slave
> when additional users join.

To keep things simple I would propose to make some assumptions for a
DMUC P2P network:
a) P2P adhoc support is done through DNS => all masters get registered
through SRV records and are
b) Network consists solely of equipotent peers => All slaves have
access to all masters (no chat room distribution/routing between
slaves is required)

>
> The slave could optionally start to intercept any messages sent to the
> master, this is a necessary requirement for split-mode.
>
> Comments?
>
>
> Kev:
>> In the case where cjo themselves want to have available several
>> available peers, they can set up SRV records for the service to point
>> to pre-agreed peers.
>
> What you're describing is probably better solved by a clustering protocol.
> I don't think that we should tackle that problem because
> a) there are lots of different approaches to clustering. Most of them
> require much more trust than you have in open federation.
> b) there is usually no need for an "open" protocol since you usually have a
> homogeneous cluster with just a single implementation and no interop
> requirements.
> c) reinventing IRC is no fun anyway ;-)
>
> philipp
>



More information about the Standards mailing list