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
pulkomandyhas joined
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 :/
Neustradamushas left
pulkomandyhas left
moparisthebest
Wouldn'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
moparisthebest
Uh like someone messaging you from foo@domain ?
moparisthebest
I 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)
kikuchiyohas joined
moparisthebest
Is anything stopping a domain from serving both mucs and regular users? I think not
moparisthebest
I 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
kikuchiyohas left
pep.
dino.im announces itself not as a muc component though (chat@dino.im _is_ a muc component technically)
moparisthebest
I 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
pulkomandyhas joined
pep.
(poezio might also be one such client..)
strarhas left
strarhas joined
pulkomandyhas left
pulkomandyhas joined
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✎
kikuchiyohas joined
pep.
Unless one wants to say "no MUC-PM has a resource always", then it's "easy" to distinguish between MUC-PM and not ✏
Zash
Nice and easy: Nope!
allie
does it matter that it's a MUC PM?
Zash
Matter how?
Zash
You 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
allie
Zash: I was asking about pep. trying to determine if a message was or wasn't a MUC PM
sonnyhas left
sonnyhas joined
pep.
And this breaks for biboumi
allie
not 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.
allie
ohhhhh, okay.
Zash
Also weird because PMs aren't sent trough channels in IRC
sonnyhas left
sonnyhas joined
UsLhas joined
sonnyhas left
sonnyhas joined
pulkomandyhas left
pulkomandyhas joined
sonnyhas left
sonnyhas joined
pep.
What do other clients do?
sonnyhas left
sonnyhas joined
sonnyhas left
Neustradamushas joined
sonnyhas joined
rionhas left
rionhas joined
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!)