[Standards] Suggestion for XEP-0045 : permit alias for the MUC address

Waqas Hussain waqas20 at gmail.com
Sat Sep 24 21:51:08 UTC 2011

On Sat, Sep 24, 2011 at 10:38 PM, Alexander Holler <holler at ahsoftware.de> wrote:
> Am 24.09.2011 11:57, schrieb Kevin Smith:
>> MUC aliasing is actually one of the very few cases in XMPP where
>> aliasing could work without protocol extensions. The server would know
>> which alias each client has joined and can route messages from that
>> JID. I don't know any server implementation that does this, but if one
>> did it wouldn't require client changes or deviation from XEP-0045.
> I think confusion on the client side would start if a client connects to
> both aliases without knowing they are aliases. A server would have to forbid
> that with a meaningful message.
> And handling room-aliases on the server side would have many pitfalls
> (e.g.the delay elements in the history). I'm not sure where else room-JIDs
> are used (besides in 'from'), that would require checking the whole XEP for
> appearances of room-JIDs (which currently isn't that easy) ;)

Kev is correct. MUC aliasing can work fine without any protocol or
client changes. A server doesn't need to forbid letting a client enter
a room in two ways. It would work fine. And I can't think of any
pitfalls regarding the delay element.

This is effectively one room 'object' on the server, and two 'views'
on it. It wouldn't be hard to modify Prosody's implementation to do
this. Most of the work required has already been done to support
multi-session nicks. I think the only change required would be to make
the internal data structures use fullrealjid+fullroomjid as a key
where they currently use just fullrealjid.

Waqas Hussain

More information about the Standards mailing list