jdev - 2022-12-01

  1. nicoco

    so the muc xep has no "service restart use case". As I understand it, 332 means: "I'm shutting down, bye bye, see you some day in other life maybe lol". Isn't there a "I'm shutting down, but I'll probably restart soon, so maybe you should try re-joining automatically every few minutes?"

  2. nicoco

    so the muc xep has no "service restart use case". As I understand it, 332 means: "I'm shutting down, bye bye, see you some day in another life maybe lol". Isn't there a "I'm shutting down, but I'll probably restart soon, so maybe you should try re-joining automatically every few minutes?"

  3. nicoco

    Zash, the lua snippet you pasted only included code 332, but shouldn't prosody send status code 110 too since this is a "self-presence"? maybe it's added somewhere else when presence-to==user-session or something?

  4. MattJ

    nicoco, I believe Prosody no longer sends 332 (partly for this reason)

  5. MattJ

    Local users have to reconnect (their whole XMPP session) anyway on restart, and remote users don't get disconnected (in the happy path)

  6. nicoco

    MattJ: I see. So clients really need to implement "muc self-ping schrödinger's cat" now to avoid being in the "I think I'm connected but I'm really not" state

  7. MattJ

    They do, and they always did

  8. MattJ

    Prosody's new behaviour means that it works properly more often than it used to

  9. nicoco

    I haven't dug enough to understand if this is sarcasm or not? all clients implement muc self-ping!?

  10. MattJ

    No, you said they "need to implement it now", and I'm saying they always needed it

  11. nicoco

    oh OK, right.

  12. nicoco

    and just so I'm sure I understand. prosody's mucs have some persistent storage for the "connected resources" so that it's persistent across restarts then?

  13. MattJ


  14. MattJ

    So in the happy case, nobody notices a remote Prosody MUC service restarting

  15. MattJ

    If you send something during the restart, your server will give you an error bounce for that stanza if the MUC is unreachable, and your client will (should) reconnect

  16. MattJ

    If the server doesn't come back (e.g. it crashed) or s2s fails silently and you never send anything, that's where mod_ping_muc helps

  17. MattJ

    Both those cases are unrelated to Prosody's restart behaviour, since they can happen anyway

  18. nicoco

    I see. And there's no way for the MUC service to query a bare JID, sth like "hey! what resources of yours believe you are still joined? nothing happened, just asking for a friend"

  19. MattJ

    No, the MUC service doesn't have a subscription to the user, and isn't permitted to know about any resources that haven't explicitly joined the MUC

  20. nicoco

    OK, thanks for your replies! I don't think that for a MUC gateway, it is a good idea to behave like prosody. When prosody is down, no messages can go through, so it's OK to respawn "unnoticed by clients". If a gateway MUC component wanted to behave like prosody, it would have to keep (persistent) track of both joined resources and chat history, then on restart fetch the "missed" messages and send them to the resources with a delay tag. This is because, when the gateway is down, the legacy service can still have messages being exchanged. So I'd rather send send "kick" (status code 332) and let clients reconnect; then it's up to the clients to correctly retrieve chat history for this MUC. Since most other IM services have a "fetch group history" endpoint, this seems a lot less trouble to implement... I am thinking out loud here, anyone feel free to chime in and tell me if I overlooked something.

  21. nicoco

    But ideally, a status code 33x meaning "I'll be down, but I'll be up again in not too long" would be better than this 332…

  22. nicoco

    But ideally, a status code 33x meaning "I'm shutting down, but I'll be up again in not too long" would be better than this 332…

  23. pep.

    Isn't it possible for s2s (only?) to send reset? at the stream level

  24. Zash

    pep., reset, the stream error? for what purpose?

  25. pep.

    Telling clients to reconnect?

  26. Zash

    Not aware of anything like that.

  27. Zash

    But that's kinda the goal of mod_ping_muc, it activates when a s2s link is closed and sends a xep-0410 ping on behalf of local clients to find out whether they are still in remote MUCs

  28. pep.

    Zash: The MUC sends the ping? Local clients? Remote MUCs?

  29. Zash

    pep., your local server sends ping (implicitly attempting new s2s)

  30. Zash

    it's basically the same as XEP-0410 but happening on the server instead of clients

  31. pep.

    Ah this way around, ok

  32. Zash

    and happening at the time of s2s disconnection (regardless of reason) since the server sees this but clients don't

  33. pep.

    So the module is loaded on the account vhost not a MUC

  34. pep.


  35. Zash

    In the case where the MUC host shut down, it can't very well be sending anything while it's down.

  36. Zash

    Also race conditions between flushing buffers and `exit()` can result in unclean shutdowns, so anything sent from the MUC might not make it.

  37. Zash

    Or the MUC might have crashed, can't very well tell anyone about that.

  38. lovetox

    Sam, you asked earlier how to create a room with Gajim

  39. lovetox

    Gajim -> Create Groupchat

  40. lovetox

    Its in the Menu

  41. lovetox

    Its rather sad that nobody could give you this info in a room with 300 people that use Gajim

  42. Zash

    Bystander effect? "Someone else will answer"

  43. lovetox

    yeah someone answered, sadly a person with no clue

  44. Zash

    Take it as a UX or documentation bug report? :)

  45. Sam

    lovetox: the room is on a server that's not the same as the domain, as far as I can see that just requests a name, not the domain to create it on

  46. lovetox

    in the dialog are 2 options

  47. Sam

    (I did try that, I foolishly typed in room@whatever and it created a room with that name on the server of my JID :) )

  48. lovetox

    private and public

  49. lovetox

    its true that you cannot choose a remote address for private chats

  50. Sam

    What does that have to do with the domain?

  51. lovetox

    but if you click public it shows you a jid field

  52. lovetox

    where you can put it anything you like

  53. Sam

    Oh, weird, I see now; I don't get what that has to do with it being public or private though, but I wanted a private room at my other group chat server anyways

  54. lovetox

    yes just create a public room there

  55. lovetox

    go into the config, and make it private

  56. Sam

    I don't want a public room though ¯\_(ツ)_/¯

  57. lovetox

    Oo wow

  58. Sam

    Is this some technical restriction I don't know about? I don't see what the address option has to do with the public/private option

  59. Sam

    But yah, I definitely never would have found this hidden behind the public option

  60. lovetox

    For a guy writing xmpp software i suprised how hard this is :D

  61. Sam

    I dunno, I guess consider this a UX report like Zash said, I have no idea how this would be obvious to anyone

  62. Zash

    How common is it to create private chats at remote MUC hosts?

  63. lovetox

    Thats the UX, it should not be obvious

  64. Zash

    How common is it to have >1 available?

  65. Sam

    Is gajim only for people who also develop XMPP software?

  66. lovetox

    you are the first person ever who asked that question in 5 years

  67. lovetox

    and we still provide a option for you

  68. Sam

    I still don't understand what these options have to do with one another or why I'd look for that box under public

  69. Sam

    I mean, I assume other people have group chat domains that are for a specific project or organization or something, no? I'm not saying this is super common or that it should be a thing that's specially supported, just that I never would have found that dialog where it was and I don't understand the logic of these two options being tied together.

  70. lovetox

    nobody says they are

  71. Sam

    I didn't understand that; nobody says what are what?

  72. lovetox

    that public has anything to do with creating jids on a remote server

  73. Sam

    Then why are they tied together in the UI? That's what I'm trying to understand

  74. lovetox

    because we dont want to show users a JID field, because they dont know what to do with that

  75. Sam

    Why would they know what to do with that if they pick "public"?

  76. Martin

    Sam: I think the UI comes from https://docs.modernxmpp.org/client/groupchat/

  77. lovetox

    users who create public rooms are most of the time advanced users

  78. lovetox

    they know what to do with that

  79. Sam

    Okay, thanks, that was the reasoning I was trying to get to. I *really* don't think that's true though.

  80. Sam

    Anyways, fair enough, you say the UX makes sense, I say it doesn't make any sense and I never would have found that if you hadn't told me. I dunno, ignore it if you want or ask others or do whatever you do to figure out UI I guess and consider this a report. Thanks for letting me know.

  81. lovetox

    i never said its obvious, and thats not by accident, most server block foreign users creating rooms, this is really a edge case

  82. lovetox

    but if i think about that dialog, instead of public and private, we could simply do a advanced box

  83. lovetox

    and offer a public switch there or something

  84. Sam

    Advanced makes a lot more sense to me. I'm not sure why "public" would be advanced, but if you're going to have an address at another server I could see that being advanced.

  85. Sam

    If it were me I'd just have name, server (pre-filled to their domains MUC server), public/private. No need to hide stuff if there are only like 4 things.

  86. Sam

    (oh, and description or whatever else was already on the form)

  87. lovetox

    hm i dont agree, as i said you overestimate how much people care about the JID

  88. lovetox

    they want to create a groupchat, and give it a name

  89. Sam

    I don't think people care about the JID, I just don't think the fact that no one cares means it needs to be hidden.

  90. Sam

    At least not in the way it is now which makes no sense. If it were behind an advanced flag that would make sense, I just don't think it's necessary for a single field.

  91. lovetox

    hm so how would a user not accustomed with the protocol details, know that he does not fill out that field?

  92. Sam

    Because it's pre-filled to their server already.

  93. lovetox

    thats not enough

  94. wurstsalat

    Keep it simple, hide distractions. People fiddle with every knob once those are visible

  95. lovetox

    you need a local part also or

  96. Sam

    They don't need to know protocol details anyways, they know they have an address like user@whatever.com already, that much they have to know to use XMPP at all.

  97. Sam

    Sure, it says "name" at the top or whatever.

  98. Sam

    Same as it does now, that part doesn't have to change.

  99. lovetox

    but they ask themself, what it is, do they have to change it etc

  100. lovetox

    and the answer is always NO

  101. lovetox

    you dont need to care about this at all

  102. Sam

    I think you're underestimating your users, they literally already have to know that it's at a server already.

  103. lovetox

    only in the edge case that you need to create a room on another server

  104. lovetox

    which probably going to fail, because almost no server allows that

  105. moparisthebest

    We once had a user click a "copy from production" button *in production* which broke stuff because they "wanted to see what it would do"

  106. lovetox

    because of spam

  107. wurstsalat

    moparisthebest: yes.

  108. lovetox

    lets leave it at that, i agree there should be advanced option

  109. lovetox

    i dont agree showing a user a groupchat adress

  110. Zash

    <button>⚠️ DO NOT CLICK</button>

  111. Sam

    Yah, I having an advanced button seems like it at least makes sense

  112. Zash

    Create: [ private chat | public channel | custom (expert mode) ]

  113. Zash

    I promise you 100% of users will pick expert mode because they're experts!

  114. lovetox

    Create: [ private chat | public channel | Click here Sam ]

  115. Sam

    RE users filling out anything even if you tell them not to: we have a field in the registration form for social.coop that says something like "Leave this field empty, it is a spam trap" or something and people constantly fill it in with random stuff and ask why their application ended up in spam. TBF, that field should really be hidden by CSS, but still.

  116. moparisthebest

    Zash: haha yea it was a bug that the button showed up on production, but clicking it literally had a pop-up that said roughly "this will wipe all data and copy from production are you sure?" And they still clicked yes