jdev - 2020-01-12


  1. 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

  2. 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

  3. pep.

    Like a legacy MUC-PM

  4. 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

  5. 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 :/

  6. moparisthebest

    Wouldn't it come through as just a normal message or no?

  7. pep.

    "What's a normal message"? :)

  8. pep.

    How do you know it's normal

  9. moparisthebest

    Uh like someone messaging you from foo@domain ?

  10. moparisthebest

    I would think it would be the same thing

  11. 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)

  12. moparisthebest

    Is anything stopping a domain from serving both mucs and regular users? I think not

  13. moparisthebest

    I have quite a few IRC users like that in my roster

  14. pep.

    dino.im, and biboumi I think are the two cases I know of

  15. pep.

    dino.im announces itself not as a muc component though (chat@dino.im _is_ a muc component technically)

  16. moparisthebest

    I guess I'm saying poezio is wrong querying the domain and assuming everything on it is a muc or not

  17. pep.

    I guess the issue is with clients not including <x/>. Poezio wouldn't need to do that

  18. pep.

    (poezio might also be one such client..)

  19. pep.

    moparisthebest, actually, the issue is not just doing the disco#info, otherwise poezio would possily consider that message as a MUC-PM

  20. pep.

    Unless one wants to say "no MUC-PM has a resource ever", then it's "easy" to distinguish between MUC-PM and not

  21. pep.

    Unless one wants to say "no MUC-PM has a resource always", then it's "easy" to distinguish between MUC-PM and not

  22. Zash

    Nice and easy: Nope!

  23. allie

    does it matter that it's a MUC PM?

  24. Zash

    Matter how?

  25. Zash

    You must join the MUC to reply, for one thing.

  26. pep.

    allie, it matters because you want to ignore carbons of MUC-PMs you're not joined to

  27. allie

    Zash: I was asking about pep. trying to determine if a message was or wasn't a MUC PM

  28. pep.

    And this breaks for biboumi

  29. 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?

  30. 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.

  31. allie

    ohhhhh, okay.

  32. Zash

    Also weird because PMs aren't sent trough channels in IRC

  33. pep.

    What do other clients do?

  34. 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!)

  35. pep.

    I don't see any obvious side-effect