XSF Discussion - 2017-03-05

  1. jonasw

    arc: you should make a talk about that :-)

  2. fippo

    spam pointing me to a jid on antispam.im... oh the irony (-:

  3. Tobias

    totally makes sense for spamproviders and antispam providers being in the same boat...the same works for cloundflare, who provide DDoS protection for DDoS booter sites ;)

  4. Tobias


  5. daniel

    Is there a reason muc doesn't force all resources into using the same nick?

  6. SamWhited

    I've honestly never considered that… I kind of want to go try it just to see how things behave.

  7. jonasw


  8. daniel

    the reason i'm asking is because ejabberd now supports merging and parting multi sessions nicks. and Conversations behaves pretty badly when you actually try it

  9. daniel

    and gajim is even worse

  10. daniel

    which kinda lets me believe that this is a problem that can not really be fixed

  11. jonasw

    you could fix it in conversations, couldn’t you?

  12. SamWhited

    Where "this" == "MUC"

  13. jonasw

    also, where can I test how bad pidgin breaks?

  14. SamWhited

    I'd be curious to see how other clients behave though; theoretically clients have to accept whatever NIC the server gives them, so I'd *think* this would "just work", but never underestimate client devs ability to ignore the spec :)

  15. SamWhited

    Nick, even.

  16. daniel

    jonasw, yes and i'm about to. i'm mostly done

  17. daniel

    however that's like soo many edge cases to consider

  18. daniel

    i'm confident that *I* will get that to work somehow. but i'm not sure for like 99% of the other clients out there

  19. daniel

    in that regard forcing a clients into the same nick might actually be the smoother edge case

  20. SamWhited

    On a similar note, why don't servers let you change to an existing nick if it's also owned by another resource? Every time I try to change my nick in Conversations ot a new room I'm in from the default one it sets I get the dreaded "nick already in use", and then have to part/join to use my own nick.

  21. SamWhited

    It seems like this could work; but most of my intuitions about MUC end up being wrong, so…

  22. jonasw

    if I understand you correctly, that’s one of the thigs ejabberd now allows and it’s simply because of "we don’t implement that" when it doesn’t work

  23. daniel

    SamWhited: yes I think that's a recent thing that ejabberd allow that now.

  24. daniel

    Prosody still prevents this

  25. SamWhited

    Excellent; all MUCs need to switch to ejabberd. That's quite possibly my biggest annoyance when using Conversations, I'd never considered that you could fix it on the server with either of these changes.

  26. jonasw

    I think Zash mentioned that it’ll be a thing with prosody in 0.10 too

  27. jonasw

    but I might be wrong

  28. daniel

    SamWhited: the nick already in use is a server error

  29. daniel

    Meaning you have to fix it on the server side

  30. daniel

    That's not a Conversations check

  31. SamWhited

    Yah, I'd always wanted to fix the symptom, not the problem (by having a "default nick" setting in Conversations)

  32. SamWhited

    I'd still like that, because I'd still like a default nick on servers that don't force all resources to the same nick, but it would definitely be better if the error were fixed on the server too.

  33. SamWhited

    Although, even if you force all clients to the same nick, nick changes would still be break things I guess because I don't *think* there's a way to force clients to change their nick if they don't request it.

  34. SamWhited thinks out loud even though you've probably been through all this reasoning before because MUC is hard…

  35. jonasw

    SamWhited: xep 45, around example 51: If the service modifies the user's nickname in accordance with local service policies, it MUST include a MUC status code of 210 in the presence stanza sent to the user. An example follows (here the service changes the nickname to all lowercase).

  36. daniel

    and now that i fixed most of the bugs in conversations i think there is a bug in ejabberd

  37. jonasw

    not clear whether that can happen out of the blue

  38. daniel

    Holger, when i'm joined with two clients A and B both using the nick x and client A changes the nick to y client B will see y join (which is correct) but client A wont see x join

  39. daniel

    which i think would be the correct behaviour...

  40. daniel

    but the fact that i'm not even sure about that doesn't speak for MUC

  41. jonasw


  42. daniel

    another thing you wouldn't have to worry about when forcing all clients in the same nick; if you you receive a message from another client with a different nick; does this count as a sent or as a received message?

  43. jonasw


  44. jonasw

    can we have MIX please.

  45. daniel

    in Conversations it actually counts as a received message; which totally confused me when testing multi session nicks; but in general this is probably expected behaviour?

  46. kaboom

    daniel: it's a received message, and: does forcing nick mean that I can no longer join a MUC with different nicks per resource?

  47. daniel

    kaboom, that whati mean by forcing the nick

  48. kaboom

    but, why?

  49. kaboom

    I use that as a feature...

  50. daniel

    kaboom, because it would get rid of *a lot* of problems

  51. daniel

    kaboom, https://xkcd.com/1172/

  52. SamWhited

    Is there any other big multi-user chat system that allows different clients using the same account to show up as different nicks? I don't know of any.

  53. kaboom

    you can already have multiple resources share a nick optionally, why force it?

  54. SamWhited

    > kaboom, because it would get rid of *a lot* of problems

  55. kaboom

    what problems?

  56. daniel

    those i just described

  57. MattJ

    There are a lot of corner cases on the server wide with nick sharing

  58. MattJ

    Prosody just doesn't let you change nick if you are sharing it with another resource, decided the complexity to implement it correctly wasn't worth it for the one person that might one day need this feature :)

  59. daniel

    MattJ: I'm sure. However I'm starting to assume that (forced) nick sharing has fewer corner cases than allowing client to merge and split their nicks

  60. MattJ

    I'd potentially be ok with that (forcing you to use a nick you are already using), but I don't really see a need for it

  61. MattJ

    It's probably what users want in (almost?) all cases

  62. MattJ

    The main problem is that from what I've seen, clients haven't traditionally been very good at handling server-forced nick changes

  63. daniel

    MattJ: well I'm kinda starting to assume that this will be easier for clients and maybe even for servers. Gajim for example has completely broken behavior when joining and splitting nicks

  64. MattJ

    I'm not sure why clients should have any issue with it, if the server does it correctly

  65. Ge0rG

    prosody's current behavior makes it really hard to change your nickname if you are using two clients, already.

  66. MattJ

    s/hard/impossible/? (unless you rejoin)

  67. Ge0rG

    MattJ: yes, unless you rejoin with all clients at the same time. it's a PITA

  68. MattJ

    Oh, you want to change nick on all clients

  69. MattJ

    Yeah, we could implement it, but again, is it really useful? and then... will clients handle it?

  70. Ge0rG

    It might be a good thing to enforce the nick change over all clients as well

  71. Ge0rG

    I'm sure clients will love to receive a new nickname

  72. MattJ


  73. Ge0rG

    I still don't see how any part of MSN can negatively affect the client-side protocol implementation

  74. MattJ

    No, I think it can always be transparent to clients if done correctly

  75. MattJ

    But it's really hard to do correctly

  76. daniel


  77. daniel

    My gajim has a different story to tell on that

  78. Ge0rG

    what MattJ said.

  79. Ge0rG

    daniel: it's a received message if it comes from another nickname, and it's a sent message if it comes from another nickname. just ignore the non-anon-MUC JID ;)

  80. MattJ

    The server has remote code execution on the client for the following operations: nick joined, nick changed, nick left

  81. Ge0rG

    daniel: and what you described above sounds like a bug in ejabberd

  82. MattJ

    i.e. it has full control over the nick list

  83. MattJ

    in every client

  84. Ge0rG

    the thing with "sent" messages in a MUC is: how do you know if it's the one you sent right now or a message from an MSN client?

  85. MattJ

    To implement every operation for nick sharing, you have to stop thinking about room state management and code for client state management instead

  86. Ge0rG

    MattJ: you need to think about both, actually.

  87. Ge0rG

    Still, I'd love to have prosody either implement nick-split and nick-join, or to enforce a nick-change over all MSN resources

  88. Ge0rG

    the current situation is really cumbersome, especially with clients that disallow editing a MUC you are not joined to *cough*conversations*cough*

  89. MattJ

    I think enforcing nick change is likely the easiest, but I don't think many clients handle it

  90. MattJ

    Maybe we should just try that and see

  91. Ge0rG

    MattJ: +1 to that.

  92. Ge0rG

    MattJ: I'm sure it affects the same clients that fail to recognize that your nickchange was rejected by the server.

  93. daniel

    MattJ, if a client doesn't handle nick changes; how can you expect them to handle the merging and seperation of nicks properly

  94. Ge0rG

    daniel: because merge and separation are join and leave events for a different participant

  95. Ge0rG

    daniel: when you initiate a nick change, you see that change followed by a join of your other client, everybody else (including the other client) will see your new nickname joining

  96. Zash

    daniel: I haven't seen any client handle forced nicknames

  97. daniel

    Zash, conversations certainly does. I haven't check others

  98. daniel

    sure that's not common?

  99. Zash

    daniel: all I tested broke in varying ways

  100. Ge0rG

    Zash: now I'm surprised. They break on forced nick change, but not when the server denies a change?

  101. Zash

    Nick override on join at least

  102. Ge0rG

    My client doesn't even always recognize MUC events.

  103. Ge0rG

    Something is leaking presence listeners...

  104. kaboom

    Just for the record: because most clients an servers fail to properly implement nick split/join, you want to remove the feature of being present with multiple nicks completely. Ever thought of removing just the split/join and forbid nick changes when being online with multiple resources? Solves the problem without losing a totally unrelated feature...

  105. Ge0rG

    kaboom: prosody forbids nick changes for MSN, and it's a usability nightmare

  106. Ge0rG

    Error> xsf@muc.xmpp.org/Zash: modify: Unknown error

  107. Ge0rG

    Hm. something is wrong

  108. Zash

    Didn't I disable mod_firewall?

  109. Ge0rG

    21:18:06 IN <message type="error" id="3ca0c0b6-3334-45f3-a65d-5d5d4a974adb-8D9B" to="georg@yax.im/9f1e6da6-2e3c-46d5-80ab-e73ac32d4719" from="xsf@muc.xmpp.org/Zash"><error type="modify"><policy-violation xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" /></error></message>

  110. Ge0rG

    I wonder why Zash isn't kicked for sending errors to the MUC

  111. MattJ

    Only certain errors are "kickable"

  112. MattJ

    The list isn't standardized

  113. Ge0rG


  114. MattJ

    Don't dig any deeper

  115. waqas

    Kicking on error isn't standardized, is it?

  116. MattJ

    No, I don't think so

  117. Ge0rG

    is there even one place in XEP 0045 that is properly standardized?