I'm following up to myself with another issue that just happened to me: > MUCs > As stated above, nick-sharing is the only sane way to do MUCs with > multi-clients, and we have multiple problems to solve here: > [1-3]
4. Carbons of MUC private messages. If user@host/A has joined to a MUC and receives a private message from muc@domain/participant, that message is carbon-copied to the other resource user@host/B (not joined to the MUC). Now /B has no way to know that it is a PM from a MUC, and not a regular message from a user muc@domain, using resource /participant, and is utterly confused. One possible workaround would be to mark all MUC PMs, like it is done by prosody: http://hg.prosody.im/trunk/rev/09151d26560a Then, a client could use that information to determine if it just received a MUC PM from a MUC it is not joined into. Another issue: If both /A and /B are joined to the MUC using the same nickname, the question arises whether the MUC component should copy a PM to both resources, or send the PM to one and a carbon of it to the other (and how the priority/routing is supposed to be handled in that case). Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || ++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: Digital signature
