I would like to be able to bridge a couple chatrooms, especially across two (or more) servers.
Is this possible?
Hi Chris,
creating shared rooms sounds as a nice feature, so your room should be called room@conference.server1 and room@conference.server2 and s2s makes sure that all rooms get synchronized? This would imho create a lot of traffic to synchronize the rooms, especially with more than two servers.
I’'m not aware of such a possibility.
LG
I don’‘t see why it would create a lot of traffic, it would double the traffic on each server as every message coming in would also have to go out but that isn’'t a lot of data even for a busy room.
In my case the room is very small I just want to link users on a server inside a firewall to users on a server outside a firewall.
Message was edited by: cweaver
Hi Chris,
as soon as you enable s2s the “outside” users should be able to see the internal conference service, maybe they can not connect because they can’'t resolve its DNS name. But the internal users should be able to use the “outside” conference service.
LG
I agree this would be a really nice feature, and doesn’'t seem too difficult to do as the wildfire server currently supports communication over the xmpp-server port (5269) for relaying person-to-person messages between servers.
FWIW, I have seen some other discussions of supporting multi-server chat-rooms (or whatever you want to call it).
Unfortunately, the MUC protocol just plain doesn’‘t support it, right now. The other discussions I’'ve seen were talking about extending MUC to support the ability to do that.
If you’'ve ever used IRC any significant amount, then you probably know that there are some downsides to that way of doing things. There are benefits as well, but to do it well is actually fairly difficult.
Just forwarding the messages from one to the other is not all that difficult, its the administrative side of things that makes things hard to deal with. How do the two (or more) servers agree who has admin, or owner, or moderator, or outcast roles (or whatever), and juggling those permissions correctly between servers gets a bit hairy.
–
Jeff
Those issues seem pretty basic to me.
Assign one server as the primary controller and the others as mirrors.
All admin responsibility rests in the primary MUC controller.
That’'s pretty antithetical to the whole idea of how Jabber/XMPP works. It could be done that way, but I think it could certainly be improved on.
A good decentralized way of doing it would also help cut down on bandwidth usage. shrug
And even if you do it the way you propose, the protocol extensions would still need to be developed before it could really be made to work.
–
Jeff