[Standards] distributed MUC rooms

[Mridul Muralidharan]

Michal 'vorner' Vaner wrote:
> Hello
> 
> On Sat, Jun 02, 2007 at 06:34:53PM +0530, Mridul Muralidharan wrote:
>>  Peter Saint-Andre wrote:
>>> Last October I talked with some folks in the XMPP community about the idea 
>>> of distributing MUC rooms across domains. Late this afternoon and this 
>>> evening I finally got around to writing up an approach to this problem. The 
>>> document I've started working on is quite tentative, but I figured I'd send 
>>> it out for feedback anyway (release early, release often!).
>>> http://www.xmpp.org/extensions/inbox/distributedmuc.html
>>> I'll try to work on it more this weekend, since I'd like to present some of 
>>> the ideas at a conference I'm attending next week.
>>> Peter
>>  A few thoughts in general.
>>
>>  1) What is the scope of the distribution - is it going to be an muc service 
>>  spread across domains ? Or is it going to be a single logical muc service 
>>  (hosted on multiple machines/nodes) ? (With reference to 1.3.3)
>>
>>  From examples 5 onwards, it looks like the former case ... might get a bit 
>>  tricky. Why would a user join muc.example.net for a conference on 
>>  chat.example.com ?
>>  Wont this not be a potential routing issue ?
>>  I assumed we will be using something like dix[1] for this - where bare jid 
>>  is the same, just that it is distributed and fault tolerant. (or integrated 
>>  into the cluster/pool'ed server).
>>
>>  This could also become potentially confusing for clients - where user of a 
>>  conference is receiving messages from multiple room jids.
> 
> As I got the idea, you never get messages from anyone except the muc you
> connected to. Every MUC would get all messages and route them to its
> local users.
> 
> As I got it, it means different rooms where messages teleport from one
> to every other, so their occupant list and messages are the same.
> 

In which case, how would directed message, iq, etc work ? multiple hops 
through the components ? Or are full jids to be shared across 
components/rooms in different domains ? (trust conf in remote domain ? 
privacy leaks ?)

So we are back to the question of - what is the intention : only high 
availability of conferences ?
Or is the intention also to spread them across domains ? So, they end up 
talking over s2s (overhead would be quite high in the latter case).

I guess without more clarity on the requirements and intentions, it 
might be premature for me to comment more.
I guess my earlier queries stemmed from my not having enough clarity on 
this.

Regards,
Mridul