Talk:NGMUC
Resource Support
There's nothing that needs to change in the spec to support this as far as I can see. It's purely an implementation design choice. With the PyIRCt transport: multiple resources can join the same room twice and they share the same nickname. (If one resource changes the nick, both resource's nicks are changed of course, both resources share the same role, etc)
In fact: from 1.21 (2006-09-13), 7.1.10 Nickname Conflict:
However, if the bare JID (<node@domain.tld>) of the present occupant matches the bare JID of the user seeking to enter the room, then the service SHOULD allow entry to the user, so that the user has two (or more) in-room "sessions" with the same roomnick, one for each resource. If a service allows more than one occupant with the same bare JID and the same room nickname, it SHOULD route in-room messages to all of the user's resources and allow all of the user's resources to send messages to the room; it is up to the implementation to determine how to appropriately handle presence from the user's resources and how to route private messages to all or only one resource (based on presence priority or some other algorithm).
Norman Rasmussen 09:04, 16 Oct 2006 (CDT)
Jingle Multicast
What about "Jingle multicast" in MUC?
Scenario: a MUC participant want to initiate a session with every another participant: he can send a file, initiate a voice or video session, or any non-XML, binary stream.
Each one partipant can accept or refuse.
Each Jingle event (beginning, end, a user quits, etc.) can be notified to the chatroom.
Nyco 07:29, 27 Jun 2006 (CDT)
Yeah...Maybe it is one too. But do you really want a session to everyone? The better way for audio and video conferencing is to connect just to one central component which mixes the audio data. Every participant of the conference would just need one session. But feel free to add this.
--Tobiasfar 08:23, 27 Jun 2006 (CDT)
Conference Component Intercommunication
I've been thinking about this one recently. You could create a 'muclinker' component that sends presence to all rooms you want to 'mirror'. That will make all the rooms send you the presence and messages. You receive these messages and 'bounce' them to the other rooms. By making this a component you can track enough state in the entities jid that you don't actually need to store much state on the component. All of this requires no code changes to any muc implementations. XEP-0033 support could be added to reduce the bandwidth consuption.
If you're going to make code changes and enhance the muc XEP, then I think it would be best to add something to allow an authorised external source to control the network linkages, and fail-over. This way the muc's can concentrate on doing what they're good at, and people can implement their own auto fail-over designs, and swap them out at will.
Norman Rasmussen 09:04, 16 Oct 2006 (CDT)
IRC++
NGMUC _*has*_ to have most of the best (all?) features IRC has, plus much more.
I am currently trying to convince IRC people to switch to Jabber these days. Because we need more users, in order to attract more users, because then we will benefit from a network effect. They do understand the necessity to adopt open standards and fight against the big proprietary giants. They even try Jabber, and more than try because they stay on Jabber even if they don't like it. But they find so many limitations, and so many lack of features...
We can't be blind, we have to listen to the thousands of users, hundreds of developpers, and years of experience. We have to learn from the past, learn from what they have learnt. We can't just redesign from scratch all the time, we can't always design with the NIH syndrome.
With Jabber, we let the IRC people the chance to go further than just IRC, we an already great platform. With IRC people, we Jabber people will benefit from them. Let us open them the door, and build together this IRC++/NGMUC.
NGMUC has to be a better IRC than IRC. More: NGMUC has to be better than the best both IRC and Jabber united.
Nyco 14:50, 5 Jul 2007 (CDT)