pep.Anybody doing anything specific to receive messages from biboumi users? In poezio we're ignoring carbons of MUC-PMs, and that's fine for the general use-case, but not for biboumi anymore
pep.Users there have their own address that are not tied to MUCs, but biboumi components still have 'conference' as identity, so wherever you look it looks like a MUC-PM
pep.Like a legacy MUC-PM
pep.https://lab.louiz.org/poezio/poezio/merge_requests/59/diffs I have this patch waiting, not sure what other effects it could have on real-life(tm) use-cases
pep.example of user address: foo%network@biboumi. no resource. So I'm using this info to not ignore it, as normal MUC-PMs would have a resource :/
moparisthebestWouldn't it come through as just a normal message or no?
pep."What's a normal message"? :)
pep.How do you know it's normal
moparisthebestUh like someone messaging you from foo@domain ?
moparisthebestI would think it would be the same thing
pep.poezio apparently does a disco#info on the domain to check if it's a MUC, if we haven't been able to detect it was a PM before that (checking <x/>, open tabs, roster, bookmarks)
moparisthebestIs anything stopping a domain from serving both mucs and regular users? I think not
moparisthebestI have quite a few IRC users like that in my roster
pep.dino.im, and biboumi I think are the two cases I know of
pep.dino.im announces itself not as a muc component though (firstname.lastname@example.org _is_ a muc component technically)
moparisthebestI guess I'm saying poezio is wrong querying the domain and assuming everything on it is a muc or not
pep.I guess the issue is with clients not including <x/>. Poezio wouldn't need to do that
pep.(poezio might also be one such client..)
pep.moparisthebest, actually, the issue is not just doing the disco#info, otherwise poezio would possily consider that message as a MUC-PM
pep.Unless one wants to say "no MUC-PM has a resource ever", then it's "easy" to distinguish between MUC-PM and not✎
pep.Unless one wants to say "no MUC-PM has a resource always", then it's "easy" to distinguish between MUC-PM and not ✏
ZashNice and easy: Nope!
alliedoes it matter that it's a MUC PM?
ZashYou must join the MUC to reply, for one thing.
pep.allie, it matters because you want to ignore carbons of MUC-PMs you're not joined to
allieZash: I was asking about pep. trying to determine if a message was or wasn't a MUC PM
pep.And this breaks for biboumi
allienot like I'm an expert on any of this stuff, just thinking... but why would someone be receiving message carbons from a MUC PM for a MUC they weren't joined to where they weren't sending messages?
pep.You're joined to a MUC on clientA, you open MUC-PM from clientA to userB and start sending messages. Your clientB starts receiving carbons.
ZashAlso weird because PMs aren't sent trough channels in IRC
pep.What do other clients do?
pep.A pretty elegant solution is to disco#info the barejid instead of the domain. Not sure why this wasn't done before. (Thanks MattJ!)