On 12 Aug 2015, at 11:41, Dave Cridland <[email protected]> wrote: > > > > On 12 August 2015 at 11:20, Holger Weiß <[email protected]> wrote: > * Dave Cridland <[email protected]> [2015-08-12 10:54]: > > For MUC, I'll summarize our conversation online as servers already have to > > track directed presence to chatrooms; it should be relatively low-cost to > > check responses and mark those as chatrooms as needed, and then perform a > > lookup for Carbons purposes. > > That way you can make sure a client won't receive carbons of PMs of MUCs > he's not joined to. A remaining problem is that multiple clients might > be joined using the same nick name, in which case you don't know whether > the MUC service delivers PMs to all or just one of them.น > > > That's a good point. > > To expand, we could have the servers send Carbons to nick-shares, in fact, > but the MUC server might be sending duplicates (and three devices would then > yield one PM and two Carbons each). > > I don't think we can solve this without specifying MUC nick-sharing properly, > which probably opens many cans of worms. > > As Kev says, this is just another problem that needs solving in MUC2.
I think that, with pubsub-to-account (I forget the term you used at the summit) this largely solves itself. PMs and MUC messages alike both get sent (once) to the bare JID, and the account is then responsible for farming them out. Once there’s only one incoming message, and the account(server) is responsible for distribution, interplay with Carbons/MAM/MAMSub becomes much easier to sort out (this is currently a big problem for MAM, because one account could be receiving a message many times, archiving many times, and then being a horrible UX unless you try to have MAM services deduplicating messages). /K
