XSF Discussion - 2019-11-25

  1. nyco

    for this month, yes: https://wiki.xmpp.org/web/XMPP_Newsletter

  2. wurstsalat

    nyco, thanks!

  3. jonas’

    Alex, have you updated the mailing list memberships already?

  4. Alex

    jonas’: no, I don't have the keys to them, requesting some help there

  5. jonas’

    cc @ MattJ, Kev ^

  6. Kev

    Alex: If you mail me what mailing list changes you'd like done, I can update lists.

  7. Kev

    To my Isode address please.

  8. jonas’

    ha fun

  9. Kev

    I'm on a train at the moment.

  10. Kev

    It is not conducive to such things.

  11. jonas’

    dwd just now sent the mail I wanted to send, but without taking into account that the mailing lists aren’t updated yet

  12. Zash

    https://logs.xmpp.org/xsf/2019-11-21?p=h#2019-11-21-142285cb0e1824d2 tho

  13. Alex

    Thanks Kev, will mail you shortly, still in some meetings

  14. Alex

    Kev: sent

  15. Alex

    Memberbot is online for the Q4-2019 membership applications

  16. jonas’

    finally an easy election

  17. jonas’

    there you go, first set of votes

  18. Alex


  19. Zash

    > The <text/> element [ in an <error> ] is OPTIONAL. [...] It SHOULD NOT be used as the error message presented to a human user This doesn't match current practice, and what else would you show users?

  20. jonas’


  21. jonas’

    ah well, normally you’d know via the protocol what an error condition means and you should show that primarily

  22. jonas’

    e.g. "MUC creation failed due to lack of permissions" for a <forbidden/>

  23. jonas’

    and then you’d attach to that the <text/> from the peer I guess... in a "details" field

  24. jonas’

    (without that use, the i18n of the <text/> does make zero sense at all)

  25. lovetox

    of course you *could* do that

  26. lovetox

    but why should you? if the server already has a more detailed error message

  27. Zash

    I believe I've mentioned a wish for a reusable set of text strings for the various stanza errors

  28. Zash

    with translations

  29. lovetox

    and of course there is not exactly one error condition per server error

  30. MattJ

    Personally I feel when I'm writing server code that I have a pretty good idea what text should be shown to the user when emitting an error (and it varies even within the same condition)

  31. jonas’

    I think the error text sent by the server should detail the "why", while the error text generated from the condition and the action should be the "what plus basic why"

  32. MattJ

    We could make custom "application specific" conditions for each instance of error, but the client would need to understand those and get some text from somewhere

  33. jonas’

    in the example above, the server could say something like "Only users from domain X are allowed to create rooms"

  34. MattJ

    Previously clients have literally copy/pasted the error description text from each condition in the RFC and displayed that

  35. Zash

    s/-/ / + title case gets you ... something

  36. lovetox

    yeah seems all really a workaround for not giving server developers the responsibility to formulate a basic englisch sentence

  37. jonas’

    lovetox, plus all other languages.

  38. lovetox

    yeah and every client has thousands of strings to translate :)

  39. Zash

    Hence why I think it would be nice to have some basic common strings and their translations

  40. jonas’

    Zash, agreed

  41. lovetox

    how would something like that look

  42. pep.

    To add to the previous discussion on our voting system, I knew something was off with the membership one as well. I can't vote blank :)

  43. jonas’

    lovetox, a huge .po file

  44. Zash

    Pretty much

  45. Zash

    Some file(s) in some format with forbidden = Forbidden | Förbjudet | VERBOTEN | no u

  46. Zash


  47. Zash

    Probably with some variants for eg conflict in MUC meaning something slightly different from conflict in IBR or in resource binding

  48. jonas’

    pep., I agree that the voting could use some fixing. I’d go with some Schulze-like method (as suggested by flow) for council/board and add a way to abstain for member votes maybe. pep. would you shepherd this to get it into the Q1 membership meeting?

  49. lovetox

    Zash, i have a hard time picturing this

  50. lovetox

    you want a mapping of error conditions to texts?

  51. lovetox

    with context

  52. Zash

    Pretty much

  53. lovetox

    and how are you then going to use that po file

  54. lovetox

    picking out the lines you need?

  55. lovetox

    or importing the full po file, even though there are many strings in it you never use

  56. pep.

    jonas’, not in a state to answer (I'm a walking zombie, tired), but that's a secondary items I wanted to tackle yeah

  57. Zash

    That'd be up to you.

  58. jonas’

    (though importing the whole file is probably easier to maintain)

  59. Zash

    And how do you know you'll never use some strings? These are things remote entities can send.

  60. Zash

    I'm no expert on .po file management and I don't wanna focus on specific formats.

  61. Zash

    Is there anything that says stream errors must only be sent in one direction?

  62. Zash

    https://xmpp.org/extensions/xep-0178.html#s2s says to just close the TCP connection if the cert is unacceptable