jdev - 2021-06-29

  1. Sam

    Are there any cases where a MUC will send an error when you try to leave it? I don't see any, and I can't imagine why, but do any servers do this for some reason?

  2. moparisthebest

    the Hotel California error...

  3. Sam

    Right now I'm treating all self-presences of type "error" as failed join requests, but I can't tell if that's right.

  4. Sam

    hah, that took me a second

  5. Kev

    > moparisthebest > the Hotel California error… You win Tuesday.

  6. jonas’

    what is it with hotel california?

  7. flow

    meh, I don't get the Hotel California reference

  8. flow

    Sam, typical error case on a MUC leave presence would be if you aren't in the MUC in the first place

  9. Sam

    flow: last verse: https://www.youtube.com/watch?v=BciS5krYL80

  10. Kev

    You can check out any time you like, but you can never leave.

  11. Sam

    Good point RE leaving error.

  12. MattJ

    You can of course get an error for any stanza to a remote server that fails to be delivered

  13. Sam

    Also a good point.

  14. Sam

    There is no good way to assiciate an error with the request that created it then; that's unfortunate

  15. MattJ


  16. Sam

    I guess I could keep track of all join/leave requests the user makes then handle self-presences in that order back from the server. This is going to be a pain.

  17. MattJ

    Oh, I see, in the case that you join the same room multiple times

  18. Sam

    Oh yah, sorry, trying to figure out what to do if the user calls Join three times and Part twice or something in different orders.

  19. flow

    is that even possbile? from the same full jid that is?

  20. MattJ

    It's not possible at a protocol level, but sure it can happen

  21. Sam

    Multiple joins are a thing; the first will join the others will either change the nick or just re-sync.

  22. Sam

    I just need to keep track of whether they've joined or not and if it gets out of sync it gets out of sync. It's just how MUC works.

  23. flow

    so the protocol design flaw in muc is that there is no way to distinguish between a join and a nick change?

  24. Sam

    That's definitely one of them

  25. Sam

    I think the main problem is that it's easy for the server and client to get out of sync. Obviously this could always happen in anything due to bugs and what not, but with MUCs it seems common and expected.

  26. MattJ

    That's not really the flaw. To solve this really you'd need a three-way handshake for joining.

  27. Kev

    There is no good way to assiciate an error with the request that created it then; that's unfortunate. The id? And you should know who causes the error because of the by stamp.

  28. Sam

    What Kev said.

  29. Kev

    > There is no good way to assiciate an error with the request that created it then; that's unfortunate. The id? And you should know who causes the error because of the by stamp.

  30. MattJ


  31. Sam

    I don't think there necessarily is an error that will be mirrored, sadly.

  32. Sam

    An ID, I mean.

  33. MattJ

    It's a "might" in XEP-0045 for the self presence to have the same id

  34. Sam

    I didn't think it mentioned it at all, but either way.

  35. MattJ

    (the text below example 23)

  36. Sam

    Ah yes, thanks

  37. Sam

    As always, I'd like to point out that all optional features are basically worthless w/o a way to check if they'll happen or negotiate for them or something.

  38. flow

    MattJ, not sure why you'd nee a three way handshake. woudln't it be sufficient to make the intent clear in the request: "I want to join this MUC" or "I believe I am already joined in this MUC and want to change my nick to X"

  39. MattJ

    I don't think nick changes are the issue

  40. Sam

    Okay, I think the issue is actually with my code and I can do this easily enough. To rephrase:

  41. Sam

    Nevermind, still can't figure out how to phrase this well.

  42. Sam

    Anyways, thanks for the help; shouldn't be an issue, I just need to keep track of order and direct self-presence errors to whatever handler was next in the order (between join/part/rename handlers)

  43. MattJ

    That sounds like it's just waiting to go wrong

  44. MattJ

    Use the id

  45. Kev

    > It's a "might" in XEP-0045 for the self presence to have the same id I thought the problem was knowing whether it was self presence or a routing error? A routing bounce will have the same id (and should have the bouncer stamped).

  46. MattJ

    If you send a join request and the join fails, you will get an error reply with the same id

  47. Kev

    Maybe I’m missing the point.

  48. MattJ

    I understood the problem to be about when the success/error result gets lost

  49. MattJ

    Which ordering doesn't solve

  50. Kev


  51. Kev goes back to lurking

  52. MattJ

    I may well have misunderstood :)

  53. Sam

    The id may not be the same though?

  54. MattJ

    What makes you think that?

  55. MattJ

    If a server sends an error in response to a stanza, it will always reflect the id

  56. MattJ

    Whether that's a failure to join the room, or a delivery error on the way to the MUC, or anything

  57. Sam

    Didn't the spec literally say 'might'?

  58. Kev

    6120? No, I don’t believe so.

  59. MattJ

    No, the text I pointed out in '45 is about the success case, not the error case

  60. MattJ

    That aside, it's a prime candidate for something that should be tested in current implementations and tightened up

  61. MattJ

    We've done that for other things in MUC in recent years, and this is a good candidate

  62. MattJ

    It doesn't change the fact that you should use the id for errors, and hope that the server also does the same for the success case (optionally have some fallback logic if it doesn't, depending on how common this behaviour is and how robust you want to be against servers that don't do it)

  63. MattJ

    On the other hand a success is a success, it means you are joined, no matter how many outstanding join requests you have

  64. Sam

    Ahhh, right, 6120 guarantees that *errors* mirror the ID, not MUC guarantees that all responses mirror the ID. Gotcha, yah, that makes sense

  65. Sam

    (sorry, just got back and was catching up on the backlog)

  66. Sam

    Prosody mirrors the ID on successful presences, ejabberd doesn't.