XSF Discussion - 2019-09-17

  1. jonas’

    was there some protocol which allows a MUC to announce a URL where a web chat to join it can be found?

  2. jonas’

    or did we just agree that there should be such a thing but nobody did it yet?

  3. Ge0rG

    jonas’: the latter

  4. Guus

    also: 'now, you touched it last.'

  5. jonas’


  6. jonas’

    Zash, you do a prosody thing for xmpp.org, I do a muclumbus thing and an update for '45, deal?

  7. jonas’

    I suggest `roominfo#web_join_url`

  8. lovetox_

    if you update 0045 anyway you could also fix example 10

  9. lovetox_

    it cointains muc#roominfo_changesubject which is non existent

  10. Ge0rG

    I bike-shed `roominfo#webchat_url`

  11. jonas’

    Ge0rG, wfm

  12. Zash

    Is it implied that this would be some anonymous webchat setup?

  13. jonas’

    Zash, yes

  14. jonas’

    I think?

  15. Ge0rG

    is there a use in a non-public webhcat?

  16. Ge0rG

    is there a use in a non-public webchat?

  17. jonas’

    Ge0rG, as an alternative to firing up your client if you know your credentials... but I think that’s not useful to have on each and every MUC of a service

  18. Ge0rG

    jonas’: so it's a server config then?

  19. jonas’


  20. Ge0rG

    what if I want to have a nicer webchat on my MUC?

  21. Ge0rG

    which is custom-hosted

  22. jonas’

    I don’t care ;)

  23. jonas’

    I think that’s a different use-case anyways

  24. pep.

    I remember that was mentioned in a sprint (Düsseldorf), and then we faced member-only channels and we figured we needed something like 401 but for MUCs? And never did it

  25. Ge0rG

    typically you need some kind of web space and xmpp / BOSH / CORS magic.

  26. Zash

    Step 1: Only do it for public (not members only) non-hidden MUCs

  27. Ge0rG

    what Zash said

  28. Ge0rG

    as a server admin, I'd like to have a default webchat proto-URL where you only need to fill in the MUC name

  29. Ge0rG

    as a MUC owner, I'd like to see that / have an opt-in / override it

  30. pep.

    Ge0rG: a few services have that already, the former

  31. pep.

    Look at chat.jabbefr.org's JS for example

  32. Ge0rG

    > chat.jabbefr.org’s server IP address could not be found.

  33. pep.

    There's a look from jabberfr.org somewhere probably

  34. pep.

    There's a link from jabberfr.org somewhere probably

  35. pep.

    (I can point to something more specific when I get a laptop)

  36. Zash

    https://chat.jabberfr.org/converse.js/some-jid-here ?

  37. jonas’

    Ge0rG, s/jabbefr/jabberfr/

  38. Ge0rG

    tres bien

  39. Zash

    Or we could go full generic and figure out how to link arbitrary URIs from MUC metadata

  40. Ge0rG

    Zash: roominfo#metadata_json

  41. jonas’

    xep-0157? ;)

  42. Zash


  43. jonas’

    seriously though, how about we solve this thing at hand right away with the obvious solution?

  44. MattJ


  45. Zash

    `hg cp mod_muc_lang.lua mod_muc_webchat_url.lua`

  46. jonas’

    MattJ, excellent. my offer stands: you do this for prosody on xmpp.org, I do it for muclumbus and an update for '45.

  47. Ge0rG

    jonas’: what is the obvious solution? A per-room manual setting? Defaulting to the server's webchat, with some kind of placeholder?

  48. MattJ

    Zash, ==> mod_muc_generic_additional_options.lua

  49. jonas’

    Ge0rG, the obvious solution is that if a server is configured with a muc log and converse, it should be published in a form field.

  50. Zash

    muc#room{config,info}_* eh?

  51. MattJ


  52. jonas’

    Ge0rG, the obvious solution is that if a server is configured with a muc log and converse and anon login, it should be published in a form field.

  53. Ge0rG

    jonas’: on the MUC domain or on individual MUCs?

  54. Ge0rG

    on both?

  55. jonas’

    Ge0rG, on the individual MUCs

  56. Ge0rG

    jonas’: what if some MUC owners don't want that?

  57. jonas’

    Ge0rG, make it members-only?

  58. jonas’

    make it password-protected?

  59. jonas’

    apply the typical access control measures for your MUC

  60. MattJ

    Agreed, if it's open then anyone can point a web chat to you and advertise it somewhere, whether you like it or not

  61. MattJ

    so if you don't want that, it shouldn't be open (or make it hidden, and we'll default it to disabled for hidden MUCs)

  62. jonas’

    MattJ, so I think the conditions should be: anon webchat configured && open && not password protected.

  63. jonas’

    MattJ, so I think the conditions should be: anon webchat configured && open && not password protected && public?.

  64. jonas’

    MattJ, so I think the conditions should be: anon webchat configured && open && not password protected && public(?).

  65. MattJ


  66. jonas’

    MattJ, `roominfo#webchat_url`?

  67. Zash

    In the case of Prosody, the anon webchat isn't attached to the MUC component, which complicates things. Implementation detail tho.

  68. Ge0rG

    I'm okay with a server config

  69. MattJ

    I think it's easy enough to add a config option to the MUC component to supply the web chat URL

  70. jonas’

    Zash, in that case I suggest a config option on the MUC component which is something like 'webchat_url = "https://chat.example/join?room=%s"' ;)

  71. Zash

    I'm in fact typing this out right now

  72. jonas’


  73. Daniel

    you need to a way to pass the block of an anon user in a muc through to the anon domain and block the ip

  74. Daniel

    otherwise you won’t be able to block users anymore

  75. MattJ

    We already have that

  76. Daniel


  77. jonas’


  78. jonas’

    code for muclumbus is ready for testing :)

  79. Zash

    jonas’: %s would be the room jid or the node?

  80. jonas’

    Zash, node?

  81. jonas’

    what node?

  82. Zash

    localpart of room JID

  83. jonas’


  84. Zash

    orrr "https://chat.example.com/join?room={node}"

  85. jonas’

    I guess that makes more sense since if your webchat needs the bare JID, it’s easier to tack a @hostname behind the %s than to try to pry the @hostname off whatever %s substitutes

  86. jonas’

    whatever works :)

  87. Ge0rG

    Zash: what if I have multiple MUC domains?

  88. jonas’

    (on the client side, I expect a perfectly working URL)

  89. jonas’

    Ge0rG, since that’s a per-componetn/domain setting ... ;)

  90. Ge0rG


  91. Zash

    I made {jid}, {node}, {host}

  92. Ge0rG


  93. jonas’

    now for the most important question. which emoji/icon should I use in the muclumbus web interface?

  94. jonas’


  95. jonas’


  96. Zash

    With what motivation?

  97. Ge0rG

    jonas’: 💬 or 🗪

  98. jonas’

    the former then, the latter shows as box only

  99. Ge0rG

    jonas’: your Unicode is too old.

  100. Ge0rG

    (Mine is, too)

  101. jonas’

    Ge0rG, let’s not get into that PRECISe discussion now

  102. edhelas

    time is PRECIouSE

  103. Ge0rG

    what kind of sauce?

  104. Zash

    jonas’: done and deployed everywhere I have access :)

  105. Test


  106. jonas’

    Zash, deployed on search.jabbercat.org \o/

  107. Zash


  108. Zash

    jonas’, avatars?

  109. wurstsalat

    Zash: there is an open issue about avatars (and how to manage/whitelist them)

  110. jonas’

    Zash, first I’ll redesign the list view (which I’m on right now), then I’ll consider how to implement whitelisted avatars for good

  111. jonas’


  112. Zash

    jonas’: Nice.

  113. moparisthebest

    bummer about the whitelisted avatars, some real troll potential lost there :'(

  114. Zash

    jonas’, which one of the various non-standard muc avatar methods will you support?

  115. MattJ

    The best one

  116. Zash

    The one implemented by everyone? The one implemented by Prosody and Gajim? The one not yet invented or implemented? 🙂

  117. Zash

    s/Prosody/a 3rd party Prosody plugin/

  118. jonas’

    Zash, I query vcard right now

  119. jonas’


  120. jonas’

    it happened

  121. Zash


  122. jonas’

    someone should set the XMPP logo as avatar for this room

  123. Zash

    I like that you rescale the ~200 byte Prosody SVG logo to ~1400 bytes of PNG

  124. jonas’

    is it an SVG?

  125. jonas’

    if it was SVG, I would not parse it at all

  126. Zash

    Unless whatever I used to set it converted it to PNG at that time

  127. Zash

    ... Gajim?

  128. jonas’

    I only parse image/jpeg and image/png

  129. Zash

    Hm, PNG indeed

  130. wurstsalat

    Wow, this looks nice :)

  131. lovetox

    jonas the black banner looks a bit boring

  132. lovetox

    otherwise great job

  133. lovetox

    and how can i whitelist the gajim muc avatar?

  134. Zash

    How do you convert SVG to PNG even?

  135. Zash

    The GNU Image Manipulation Program doesn't have the slightest idea what aspect ratio xmpp-logo.svg has

  136. lovetox

    Gtk can do that

  137. lovetox

    and yes Gajim does that at the moment

  138. lovetox

    C for example has no support for svg

  139. Zash

    `viewBox="-3277 648.6 176.5 134"` ???

  140. jonas’

    Zash, inkscape -z --export-png=/path/to/out.png /path/to/in.png

  141. Zash

    Would it pick up a vcard for xsf@ if one had set one?

  142. jonas’


  143. jonas’

    muc.xmpp.org is in the whitelist

  144. Zash

    Entire domain?

  145. jonas’


  146. Zash


  147. wurstsalat

    jonas’: so gajim.org is probably on the whitelist but it fails to provide its avatar the right way?

  148. jonas’

    wurstsalat, refresh

  149. jonas’

    wurstsalat, it just took a while to re-scan the MUC

  150. moparisthebest

    ooh entire domain you say, can I create mucs here?

  151. jonas’

    moparisthebest, no

  152. Zash

    You also can't set vcards.

  153. jonas’

    off to bed now

  154. wurstsalat

    jonas’: I do like the new layout!

  155. Daniel

    jonas’: I'm currently getting internet server error from the api

  156. pep.

    Newbie question: "After SASL negotiation, the parties MUST restart the stream." why is that?

  157. Zash

    pep., iirc to be sure that any sensitive SASL data can be wiped from memory.

  158. Zash

    And so that you can offer new features.

  159. pep.

    new features? ah, after being authenticated

  160. Zash

    post-auth only stream features

  161. fippo

    yes. it would not make sense to offer you any stream features that require authentication prior to auth ("try this! ah sorry, you need to be authenticated") so the rule of thumb is to only offer what has a chance to work

  162. Zash

    and you can't re-send stream features without a stream restart for whatever reason

  163. Zash

    this is one of the reasons dialback is awkward, since there's no stream restart involved, so you have to offer post-auth features before auth.

  164. pep.

    yeah that's what I was wondering (why not "just" send new features)

  165. Zash


  166. Zash

    resetting the parser and wiping pre-stream restart data has some value one might think

  167. pep.

    So using a mobile client actually has some benefits. This way you can see new features your server advertizes quickly (/s)

  168. Zash

    Now go implement SASL2 and/or BIND2 :)

  169. fippo

    "just" sending new features might break backward compat

  170. pep.

    Call it XMPP2!

  171. fippo

    (i suspect this is a mostly theoretical concern)

  172. pep.

    or 3, or 4

  173. Zash

    XMPP 99