XSF Discussion - 2019-04-06

  1. jonas’

    pep., what is the fail?

  2. pep.

    Oh is that not a fail? Lifecycle on the right? If not then I'd say it's missing a bit of margin maybe

  3. jonas’

    it’s not a fail, it needs a bit of padding, yes

  4. jonas’

    pep., FWIW, the terms come right from XEP-0001, you’d have to take it up with XEP-0001 to change them :)

  5. pep.

    Yeah but I have no idea what to replace them with

  6. jonas’

    I like "Living Standard" for Draft

  7. jonas’

    now for the fun part

  8. jonas’

    can someone tell me where https://xmpp.org/extensions/xmpp.css comes from? It is **not** in the attic container (<https://github.com/xsf/xep-attic/>)

  9. jonas’

    cc @ Kev, MattJ

  10. jonas’


  11. MattJ

    Sorry, I don't know the answer and I'm currently on my phone

  12. jonas’

    hm, so you probably also can’t help me with the fact that https://xmpp.org/extensions/xmpp.v2.css 404's

  13. jonas’

    (despite being in the xeps docker image)

  14. jonas’

    I pushed a hotfix against the presentational issue, I still need a permfix on the server level

  15. jonas’

    (and the hotfix will take 2h or something to deploy)

  16. flow

    jonas’, Ge0rG: just for my notes: why was https://github.com/xsf/xeps/pull/752 considered not a good idea?

  17. jonas’

    flow, I edited to link minutes + logs

  18. flow

    jonas’, thanks :)

  19. flow

    We probably should make sure that the "Application Specific Errors for MUC" are going to get defined some day (all of them being optional as long as we don't want to bump the namespace)

  20. jonas’

    announced via a separate disco#info feature, yes

  21. Ge0rG

    > Georg proposes that Jonas writes a separate "Application Specific Errors for MUC" XEP, for having instigated this mess (with the original discussion.) 😁

  22. flow

    jonas’, I am usually not against adding more disco#info features, but is there any advantage besides statistics in this case?

  23. jonas’

    flow, not sure

  24. jonas’

    it gives clients more information about what an absent application specific condition means

  25. jonas’

    (undefined vs. server doesn’t support it)

  26. jonas’

    alternatively, we could have a <undefined-muc-condition/> thing which is always sent on MUC errors if the XEP doesn’t override it

  27. jonas’

    that’s nice because it’s zero-roundtrip

  28. flow

    wouldn't you still need a feature to determine if the server is going to add <undefined-muc-condition/>? Also what if a condition becomes defined later on?

  29. jonas’

    for the first question: no, you’ll find that out when you receive an error

  30. flow

    Not sure if optimzing for zero-roundtrip is a worthwile goal here

  31. jonas’

    for the second question: then it gets a new condition (and the <undefined-muc-condition/> vanishes of course), I don’t see a problem

  32. flow

    I don't see a problem right now too, just wondering

  33. jonas’


  34. flow

    jonas’, the important question right now is: When will you write the XEP? ;)

  35. jonas’

    I think "if" is the more interesting question ;)

  36. flow

    Well if the answer is no, then I would consider taking a shot. Collaboration is welcome of course

  37. jonas’

    oh, go ahead please

  38. flow

    taking a shot and stealing your ideas, of course

  39. jonas’

    I don’t have it high on my agenda at the moment

  40. jonas’

    (I actually 99.999% forgot about it until you mentioned it ;))

  41. jonas’

    hotfix landed

  42. jonas’

    enjoy our new XEP CSS live

  43. Kev

    jonas’: The question above, is it urgent? I don't want to look at it right now, but will if things are broken.

  44. jonas’

    Kev, for the attic, it’s not that urgent

  45. Kev

    Ta. Poke me Monday then, please.

  46. jonas’

    the xmpp.v2.css 404 was urgent, but by now another docker build passed with a workaround from my side.

  47. jonas’

    we can discuss it monday, too

  48. Guus

    Jonas, the "this document in another format" XML button directs me to a 404.

  49. Guus


  50. jonas’

    ha, it probably always did that

  51. jonas’

    (I didn’t change it)

  52. jonas’

    well, "always", since the server crash

  53. Guus

    Pdf does work

  54. jonas’


  55. Guus

    Yeah, I never tried that before. 😁

  56. Guus

    Maybe remove the button if fixing it is more effort?

  57. jonas’

    fixing it should be easy if I can get hold of iteam

  58. Guus

    Should a http button be added? In case the document is copied somewhere, to have a reference to the original one?

  59. jonas’

    ITYM "e"HTML

  60. jonas’


  61. jonas’

    I don’t think so

  62. Guus

    Should a html button be added? In case the document is copied somewhere, to have a reference to the original one?

  63. Guus


  64. Guus

    I love the way this turned out. Thanks for putting in the effort!

  65. jonas’


  66. Guus

    We should tweet about this

  67. Guus

    Anyone able to do so now? If not, I'll find a laptop.

  68. jonas’

    I can’t, but good idea!

  69. Guus

    I can, but not from mobile

  70. Guus

    I'll find a laptop.

  71. Guus

    jonas’: what do you consider key improvements?

  72. jonas’

    Guus, left-hand TOC on large screens, responsive design, modernised HTML

  73. Seve

    Hey jonas’, I see your changes are now live, I haven't been able to follow all this. Nobody mentioned anything about the blue color for headers or the blue background color for the code-example class?

  74. jonas’

    Guus, left-hand TOC on large screens, modernised HTML and using an award-winning responsive CSS framework

  75. jonas’

    Seve, noone did indeed

  76. Seve

    It must be me then, the only one missing those :D

  77. Seve

    Looks really good, thank you very much jonas’ !

  78. jonas’


  79. jonas’

    Guus, while you’re at it, the newsletter hasn’t been tweeted yet either

  80. jonas’

    uh, and it’s still using the old (unfixed) logo as avatar

  81. Guus

    sent out two tweets

  82. Ge0rG

    Guus: you missed the link to the extensions 😉

  83. Guus

    I didn't

  84. Guus

    I'm guessing that top level links are better SEO wise, but unsure

  85. Guus

    It was a deliberate choose, in any case. 😉

  86. fire

    Welcome guys

  87. fire

    No body?

  88. Seve


  89. pep.

    Yes <body/>

  90. fire

    Good day

  91. fire

    pep., hey man

  92. fire

    pep., you programmist?

  93. fire

    I think this room for programmist

  94. fire

    Seve, wow, new face

  95. fire

    Seve, I am not talk english language

  96. fire

    Seve, have jabber bot translate for me?

  97. fire


  98. fire

    I am from in russia

  99. fire

    I am walk this room

  100. fire

    Seve, hey man

  101. fire

    I am look they

  102. vanitasvitae

    fire: this chat is not meant for casual "whats up man" chatting. It is intended for talks around the xmpp standard. In order to allow busy folks to follow the important conversations, please keep the non-standards talk to a miminum.

  103. fire

    Don't sleep, don't sleep, don't sleep everybodu

  104. fire


  105. vanitasvitae

    fire, Этот чат не предназначен для случайных чатов. Он используется для обсуждения стандарта XMPP на техническом уровне. Пожалуйста, перестаньте говорить о вещах не по теме, чтобы занятые участники могли следить за важными вещами, которые написаны.

  106. fire

    vanitasvitae, I am understand, can you help me go in casual chat?

  107. vanitasvitae

    no, but it would work similar to how you joined this chat

  108. fire

    I can't search casual chat

  109. Mikaela-

    fire: https://search.jabber.network/rooms/1

  110. fire

    Mikaela-, yes, thank you man

  111. fire

    Mikaela-, this cool

  112. goffi

    jonas’: I'm seeing that a bit late, but thanks for the new design, it's neat.

  113. jonas’


  114. jonas’

    thanks :)

  115. moparisthebest

    Yep excellent work on that, I'll avoid the unnecessary highlight

  116. jonas’


  117. rion

    xep-0166 v0.30 "Clarified that session-accept action accepts only the content definition(s) in the session-initiate." does anyone know why it was removed in next versions?

  118. Lance

    I'm pretty sure that version predated the content disposition attribute. So that behaviour was to handle what would now be early-session disposition contents

  119. Lance

    Current behaviour is session-accept only accepts content with disposition=session

  120. rion

    content-add hs other disposition by default?

  121. Lance

    nope. default is always session

  122. Lance

    its all related tohttps://xmpp.org/extensions/xep-0269.html

  123. Lance

    its all related to https://xmpp.org/extensions/xep-0269.html

  124. rion

    hm. well I'm just trying to decide what's better while I have peding incoming session and remote adds more content before I accepted the session. a) send content-accept and skip this content in session-accept later b) don't send content-accept and accept everything with session-accept

  125. Lance

    its a matter of user intent here. if the user hasn't accepted, then let it get included with the session-accept

  126. Lance

    you would do a content-accept before the user accepts the session only for this early-session stuff

  127. rion

    If accept everything in session-accept it becomes possible an user may accidently accept undesired content

  128. rion

    I didn't read early media xep before

  129. Lance

    early media is mainly for interop with telephony stuff

  130. rion

    it's like remote music instead of beeps ?

  131. Lance


  132. Lance

    but yeah, determining what is being accepted is a small pain. and would need to be handled higher up

  133. Lance

    like, don't enable accept button until after small delay from any content-accept

  134. pep.

    jonas’, btw, there's no way to not display the index? At least not without JS I assume?