On Sat, Sep 24, 2011 at 10:38 PM, Alexander Holler <hol...@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
