Re: [Standards] MUC 2
On 12 February 2015 at 17:19, Dave Cridland d...@cridland.net wrote: On 12 Feb 2015 14:00, Christian Schudt christian.sch...@gmx.de wrote: Dave, maybe could you (or somebody else) elaborate on the shortcomings and the different demands of things like buddycloud you have discussed for those who didn't attend the summit. Also what's so bad about multiple parties chatting via a third party chat service (your 2nd use case)? In the case of a private conversation between three people, it feels wrung to introduce a fourth. Agreed. They can join but don't get access to the mentioned in confidence history before they joined. Google Hangouts is very sensible about the two-people - now-a-group upgrade handling. Secondly, I think that we do want to maintain basic protocol compatibility with old MUC, so clients joining via presence we probably want to support, and clients sending messages would be unchanged. Presumably this could be achieved through a translat-o-matic ( http://wiki.xmpp.org/web/Summer_of_Code_2015#MUC_to_Channels_translat-o-matic ) My vision is that legacy MUC clients can still work. But more modern BC clients can handle the case of liking a comment ( http://xmpp.org/extensions/inbox/buddycloud-channels.html#item-rating), comment threading, post revocation etc. S. -- Simon Tennant | CEO Buddycloud http://buddycloud.com | +49 17 8545 0880
Re: [Standards] MUC 2
Dave, maybe could you (or somebody else) elaborate on the shortcomings and the different demands of things like buddycloud you have discussed for those who didn't attend the summit. Also what's so bad about multiple parties chatting via a third party chat service (your 2nd use case)? For me one shortcoming of XEP-0045 is that there's no good concept for the offline case of an occupant (member). E.g. you create a members-only room with three friends. They exchange messages, while you are one week offline. You then enter the room and only receive messages according to your discussion history request while entering, let's say the last 25 messages. But missed most of the messages your friends have exchanged, while you were absent. That's of course unfortunate, because you would expect to not miss any conversations. It's like if my mail client would only request the last few mails from this mailing list, when I start it and any older messages could only be read in an archive via a browser, if available. (well, maybe this could be solved with pubsub). Although I don't know the real shortcomings and demands you discussed about, I imagine doing MUC with PubSub adds extra complexity. XEP-0045 is already complex, XEP-0060 is even more complex and maintaining two very different MUC approaches (from a technical point of view) is a burden for any developer, while end users probably won't see many differences (e.g. they don't care if their MUC is hosted by an traditional chat service or by a PEP service). Isn't it possible to eliminate the shortcomings of XEP-0045 by just evolving it? Christian
[Standards] MUC 2
At the summit, a bunch of us decided to have a serious effort at a redesign of multi user chat, to address shortcomings and emerging use cases. The overall model was a service domain which exposed, at bare jid level, a set of rooms, which acted more or less as pubsub services, with subsidiary nodes exposing information such as messages, occupants, and so on. I think this general concept would work well for both traditional chatrooms and the different demands of things like buddy cloud. Unifying MUC and buddy cloud is a personal goal, but I think it's a useful yardstick to see if we're capturing the use cases right. However, this model doesn't address three other use cases I feel are important. Firstly, there's XEP-0277, which I suspect fits in the same concept. Secondly, multi party chat. I'm using the term multi party chat to mean ephemeral conversations between more than two people. Currently these are handled, badly, by hosting the conversation on an existing third party chatroom service. This means that one participant locates a chatroom service and invites the other; meaning the first party needs to use a server that has a chatroom service, and the second party needs to be willing to use it. I suspect that both of these use cases are addressed, at least partly, by being able to host chatrooms on the pep service of the user. This means, possibly, making the model one of a single pubsub mode with multiple strands of publication, which I've previously called facets. The third missing use case is that I'd like to have room level federation in from the outset. It's proven really hard to retro fit, and it's work usefully in the multi party chat scenario, too, as well as several other use cases. Dave.
Re: [Standards] MUC 2
On 12 Feb 2015 14:00, Christian Schudt christian.sch...@gmx.de wrote: Dave, maybe could you (or somebody else) elaborate on the shortcomings and the different demands of things like buddycloud you have discussed for those who didn't attend the summit. Also what's so bad about multiple parties chatting via a third party chat service (your 2nd use case)? In the case of a private conversation between three people, it feels wrung to introduce a fourth. For me one shortcoming of XEP-0045 is that there's no good concept for the offline case of an occupant (member). E.g. you create a members-only room with three friends. They exchange messages, while you are one week offline. You then enter the room and only receive messages according to your discussion history request while entering, let's say the last 25 messages. But missed most of the messages your friends have exchanged, while you were absent. That's of course unfortunate, because you would expect to not miss any conversations. Right, and this was discussed in detail at the summit. Presence and MUC are going to be split. MAM is part of the solution here, as I'd the account model based pubsub. It's like if my mail client would only request the last few mails from this mailing list, when I start it and any older messages could only be read in an archive via a browser, if available. (well, maybe this could be solved with pubsub). Although I don't know the real shortcomings and demands you discussed about, I imagine doing MUC with PubSub adds extra complexity. XEP-0045 is already complex, XEP-0060 is even more complex and maintaining two very different MUC approaches (from a technical point of view) is a burden for any developer, while end users probably won't see many differences (e.g. they don't care if their MUC is hosted by an traditional chat service or by a PEP service). Well, pubsub is actually simpler than MUC, since MUC is essentially an all or nothing, whereas pubsub is a tiny core with lots of optional parts. Secondly, I think that we do want to maintain basic protocol compatibility with old MUC, so clients joining via presence we probably want to support, and clients sending messages would be unchanged. I'm reasonably confident that MUC 2 should be okay to implement on both server and client. Luckily, clients won't have to change much, and we can almost certainly keep full protocol compatibility. Isn't it possible to eliminate the shortcomings of XEP-0045 by just evolving it? Christian
Re: [Standards] MUC 2
* Christian Schudt christian.sch...@gmx.de [2015-02-12 14:59]: For me one shortcoming of XEP-0045 is that there's no good concept for the offline case of an occupant (member). That could be solved with MAM (XEP-0313), for what it's worth. Holger
