XSF Discussion - 2020-04-20

  1. Neustradamus

    MattJ: Any news? - https://github.com/xmpp-observatory/xmppoke-frontend/issues/8#issuecomment-616323674

  2. jonas’

    Neustradamus, is xmpp.net working?

  3. marc

    SamWhited: yes, I'll ping you 👌

  4. eevvoor

    How do I connect to a IRC via XMPP? I did that bevore but cannot refind instructions nor remember how I did that.

  5. Zash

    You would use a transport like Biboumi or something.

  6. eevvoor

    Zash, how exactly? I used Gajim that time and only remeber that it was easy, nothing else :D.

  7. Ge0rG

    eevvoor: there are a few public hosted biboumi instances, and you can run your own of course

  8. eevvoor

    Ge0rG, ah ok. I will not host my own at the moment.

  9. Ge0rG

    eevvoor: there is a semi-public one on irc.yax.im that I'm running and I think there was also one on jabberfr

  10. eevvoor

    How would I use yours Ge0rG

  11. Ge0rG

    eevvoor: /join #channel%ircserver@irc.yax.im should work, or ad-hoc-configure irc.yax.im

  12. Ge0rG

    provided that s2s works for it.

  13. Ge0rG

    no idea though ;)

  14. MattJ

    No DNS

  15. MattJ

    irc.jabberfr.org responds though

  16. Ge0rG

    ah right, you'd have to add irc.yax.im CNAME xmpp.yaxim.org for it to work.

  17. Ge0rG

    ...on your xmpp server. security by obscurity.

  18. eevvoor

    hm Ge0rG where do I use the /join cmd?

  19. Ge0rG

    eevvoor: in your xmpp client

  20. eevvoor

    ah :D

  21. eevvoor

    Ok. it worked. thx Ge0rG, this time I document it for myself.

  22. eevvoor

    In case I would need to specify the port, would it be also in the join line?

  23. pep.

    To configure the port you'll need ad-hoc support I would say

  24. MattJ

    Anyone know of a client library (not web-based) that supports websockets?

  25. Link Mauve

    MattJ, nbxmpp, from Gajim.

  26. MattJ

    Ah nice, thanks

  27. eevvoor

    ok pep. the question was luckily just for curiosity.

  28. MattJ

    flow, just sent a mail regarding list-multi

  29. MattJ

    XEP-0004 forbids arbitrary values there

  30. MattJ

    Hmm, what do people think about a <comment> block in XEPs that isn't rendered by default?

  31. pep.

    Comment for whom to see?

  32. MattJ

    People working on the XEP

  33. pep.


  34. MattJ

    Potentially useful for detailed rationale, etc.

  35. pep.

    Sorry I read "block" and "XEP" and I made the wrong connection

  36. jonas’

    MattJ, <!-- ... -->?

  37. MattJ

    It would be nice if we /could/ render these though

  38. MattJ

    e.g. in a different colour

  39. pep.

    MattJ, I would prefer to render the rationale tbh :x

  40. jonas’

    I think detailed rationale should simply go in the document itself

  41. MattJ

    That could lead to a lot of noise

  42. MattJ

    I don't think XEP-0313 needs a detailed explanation of why it uses list-multi or text-multi

  43. pep.

    Do you have an example ?

  44. pep.

    Do you have an example?

  45. pep.


  46. MattJ

    That's just going to be noise for people trying to implement it

  47. jonas’

    MattJ, ah indeed

  48. jonas’

    just put it in <

  49. MattJ

    But for people working on the XEP, or curious in these decisions, it's valuable

  50. pep.

    Well that can go into a "rationale" section that people can skip

  51. jonas’

    just put it in <!-- .. --> I think

  52. MattJ

    No, I kinda want it inline

  53. jonas’

    MattJ, so put it inline?

  54. Zash

    Oh but XEP-0122 lets you alter the behavior of list-multi

  55. jonas’

    (ah that was in reply to pep)

  56. Zash


  57. Zash

    Tremble before the tower of complexity!

  58. MattJ

    It would be nice for a HTML rendering with author notes visible

  59. Kev

    I agree that a 'real' block that's unrendered but renderable would be useful for quite a lot of things.

  60. MattJ

    and we can even render both versions on the site by default

  61. MattJ

    Zash, aha, thanks

  62. Zash


  63. MattJ


  64. Zash

    Hm, views. Separate renditions / views for users, implementors, authors?

  65. MattJ

    Users? No thanks

  66. Zash

    User view = just a description of the feature + list of implementatinos

  67. MattJ


  68. Zash

    Becasue XEP == Feature now.

  69. flow

    MattJ, replied

  70. Kev

    MattJ: Oh, I was thinking of a JS toggle, rather than a different document.

  71. flow

    MattJ, I also think the statement "text-multi is defined to be multiline" to be problematic. text-multi values appears to be explicitly *not* multi lines, as should not contain newlines

  72. MattJ

    Either works for me (Zash's solution doesn't even use JS)

  73. Zash

    Kev, `<details>` !

  74. MattJ

    "The field enables an entity to gather or provide multiple lines of text. ***"

  75. Kev

    Whatever :)

  76. MattJ

    "an application that receives multiple <value/> elements for a field of type "text-multi" SHOULD merge the XML character data of the value elements into one text block"

  77. Zash

    What happens if you put newlines in the individual <value>s?

  78. Kev

    MattJ: It's fine isn't it? We can use list-multi, just have to have the server generate a form that has all the IDs in it so the client can then choose from them.

  79. Zash

    Kev: Perfect!

  80. Zash

    How many unique IDs do you think the MUC logs of this chat room has?

  81. flow

    MattJ, that requirement appears strange to me. but irregardless text-multi should be a good fit?

  82. Kev

    text-multi is just a way of providing a multi-line text field, it's not multiple text entries.

  83. MattJ

    Other than I expect any sensible library is going to return a multiline string from this form, it's "ok"

  84. Kev

    So I think that's a worse fit than list-multi, TBH.

  85. MattJ

    As long as newlines aren't allowed in message ids...

  86. MattJ

    list-multi does feel cleaner

  87. Zash

    ``` <field var="archive-ids" type="list-multi" label="Archive IDs of messages to retrieve"> <validate xmlns="http://jabber.org/protocol/xdata-validate" datatype="xs:string"> <open/> </validate> </field> ```

  88. flow

    MattJ> Other than I expect any sensible library is going to return a multiline string from this form, it's "ok" definetly, although low layers of an API would (and should) probably allows access to the individual values

  89. flow

    ahh the requirement above explicitly talks about "an application", everything is fine then ;)

  90. MattJ

    You certainly could get that info in Prosody, for example. But it's a mess, you have to then access that field differently to all the others that are parsed, validated and returned automatically

  91. MattJ

    Would be easier just to split by newline again

  92. MattJ

    But ugly

  93. MattJ

    I think I'm going with list-multi

  94. Zash

    Luckily we don't have any validation that values are among the offered options \o/

  95. Zash

    Haha, maybe IDs should be JIDs, then we use jid-multi :D

  96. lovetox

    hm if list-multi says a client is not allowed to add new options

  97. lovetox

    but we never receive a form from the server in the MAM spec anyway

  98. lovetox

    so tecnically we dont add new values

  99. Zash

    What's about the iq-get?

  100. MattJ

    You do receive a form (but you don't have to)

  101. lovetox

    ah yeah you can request it i remember

  102. Zash

    You receive the form from the allmighty XEP author when you read the holy text.

  103. flow

    I think the fact that you can retrieve a (blank) gather form for MAM query options is a strong argument against list-multi, since you usually would have that field populated in gather forms

  104. Kev

    Maybe it shouldn't be a list at all, but just a single value? :)

  105. MattJ

    At which point we might as well stick with the current non-form proposal

  106. MattJ

    <p>A special note about the 'ids' field: this field is of type 'list-multi' which typically is used to allow the client to select from a provided list of options. In this form the list of all possible ids MUST NOT be provided by the server, as it is likely to be extremely large. Instead the server MUST include a &xep0122; &lt;validate/&gt; element that signals the list is open to arbitrary values provided by the client.</p>

  107. Kev

    Seems pragmatic.

  108. flow

    Kev> Maybe it shouldn't be a list at all, but just a single value? :) Wouldn't that be an indicator that there is a hole in xep4 which we may want/need to fill?

  109. flow

    ahh, TIL <open/> from xep122 is actually defined as what we need

  110. flow

    must the <open/> only appear on form retrieval or also on form submission?

  111. Zash


  112. Zash

    The entity you're submitting it to should know what the form looks like

  113. Zash

    so, sending them such metadata would be redundant

  114. flow

    yeah I know, I just wondered if there is some spec text on that

  115. Zash

    IIRC 0004 says that the basic type attrs are optional on submitting, same logic

  116. flow

    not sure if my spec laywer would agree to that, but yes ;)

  117. Zash

    20% of Council agrees :P

  118. eevvoor

    > not sure if my spec laywer would agree to that, but yes ;) layer or lawyer flow ;)

  119. flow

    not sure if my spec lawyer would agree to that, but yes ;)

  120. flow

    Friendly (and probably only) reminder that you can suggest characters for the XSF to adopt by the end of the week at: https://wiki.xmpp.org/web/Adopt-a-Character or by writing me an email: flo@geekplace.eu

  121. Ge0rG


  122. pep.

    <💡/> 4 chars

  123. Zash

    <🗪 xmlns=💡/>

  124. Zash

    `<💬 xmlns=💡 type=🗫><body>Nobody said XML element names are restricted to ASCII</body></💬>

  125. pep.

    missing a >

  126. pep.

    Or is that my terminal

  127. Zash


  128. rion took a look on the calendar. Doesn't seem to be 1st..

  129. Syndace

    Zash, MattJ: if you want to have a look at what I came up with for Quick Response: https://github.com/xsf/xeps/pull/933

  130. Syndace

    no idea if this is the formally correct way to re-propose a protoXEP that has been rejected before 😀

  131. pep.

    As an editor I am not sure how to deal with this :p

  132. MattJ

    Let's just say it is

  133. Syndace

    Technically you can treat it as a new protoXEP, it has a different name and 99% different content

  134. pep.

    Do we need an ACK from the original author

  135. MattJ

    I have some feedback but can't type it up right now

  136. Syndace

    okay I converted it to a draft pr for now

  137. pep.

    Syndace, thanks

  138. Zash

    pep., enough of an ack? https://github.com/xsf/xeps/pull/933#issuecomment-616742618

  139. pep.


  140. Zash

    Did I spell Syndace correctly this time?

  141. pep.


  142. Zash

    Wrote "Syndance" first :)

  143. Syndace

    Hahaha I like it :D

  144. pep.

    Syndace, poke me when you remove the WIP state and it's ready to merge

  145. pep.

    Or another editor

  146. Syndace

    Sure, thanks

  147. Zash

    I suppose you want to add your own version block as well

  148. Zash

    Oh wait, you did

  149. Zash

    Confused by indentation. nm me.

  150. Syndace


  151. Zash

    Not sure you want to delete the old one tho, since that was a thing that was proposed

  152. Syndace

    theoretically protoxeps are supposed to be version 0.0.0 anyway afaik

  153. Zash

    Oh no!

  154. pep.

    I'm always so confused by our versioning scheme

  155. pep.

    I don't like it

  156. Syndace

    but I'll wait for an editor to tell be that :)

  157. pep.

    XEP-0001 doesn't actually say protoXEPs are not versioned

  158. pep.

    It just seems to say a XEP (experimental) gets published with version 0.1

  159. Syndace

    oh, I think I read something in the readme of the xeps repo

  160. pep.

    Maybe the xep-README thing contains useful info

  161. pep.

    2§ XEP Editor Responsabilities: 11. List administration ??

  162. pep.

    "Set the version to 0.0.1."

  163. pep.

    for a protoXEP

  164. pep.

    I would like to note that this file mentions a mercurial repo for XEPs :o

  165. Syndace


  166. Zash

    I think I still have a clone of that repo, from ... bitbucket? or whatsitcalled?

  167. pep.

    Does anybody still have access to editor@xmpp.org?

  168. Syndace

    Zash: do you have any feedback on the content? Did I about grasp what we discussed yesterday?

  169. Zash

    I got distracted before I got that far :)

  170. MattJ

    Ok, I'm here for a few

  171. Syndace


  172. Syndace


  173. MattJ

    Syndace, a big one I'd like to comment on is internationalized responses

  174. MattJ

    I think it came up while discussing the previous protoXEP, and it also has come up for me again in Hats, and possibly elsewhere too

  175. Syndace

    hmm yes, I thought it would be weird if you see a frensh message and a frensh button but then on click suddenly there is an english "yes"

  176. MattJ

    and we had a big discussion a while back about multiple <body> tags

  177. Syndace

    (oh boi, french I mean)

  178. MattJ

    I think what I'm converging on is the approach that generally each interaction is confined to one language

  179. MattJ

    and this can be indicated by xml:lang for clarity

  180. MattJ

    A Spanish bot, or a multilingual bot in a Spanish MUC is just going to use Spanish for all interactions

  181. Syndace

    does the bot always know the preferred language of the recipient?

  182. Zash

    If it's responding, it can know

  183. MattJ

    My argument is that yes, in practice it does

  184. Zash

    Dunno if you have bots initiating interactions ever

  185. MattJ

    We have basically never used the multiple xml:lang <body> thing, it's basically a lurking security issue at this point

  186. Zash

    💡️🤖️> Hello Zash, you haven't voted yet. Maybe you wanna do that now? Eh?

  187. MattJ

    It has many problems in practice, and I think it's good to keep things simple, and not add stuff just because we can

  188. MattJ

    I was planning hats (aka Badges, whatever) to offer translations, and I decided to drop it on similar grounds

  189. Syndace

    okay. So what would you propose? Remove all the xml:lang stuff and replace the i18n considerations with "if the entity aims to support multiple languages, it should do so by detecting the preferred language of its communication partner and then using only that one language"?

  190. Zash

    Syndace, not remove, but only allow one

  191. Zash

    xml:lang is still allowed everywhere in theory

  192. MattJ

    It should have (optional?) xml:lang

  193. MattJ

    But not support for multiple

  194. Zash

    Hm, multilingual bot interactions, would that be an informational XEP?

  195. Zash

    Actually applies to servers

  196. pep.

    "MattJ> A Spanish bot, or a multilingual bot in a Spanish MUC is just going to use Spanish for all interactions" I'm sorry to be the exception again, but it happens quite often in two different MUCs I'm in that it's not the case :(

  197. pep.

    There's no "one language defined"

  198. pep.

    poezio@ is such an example

  199. MattJ

    pep., I'm fine with that

  200. MattJ

    But you wouldn't deploy a Spanish-speaking bot in that room, would you?

  201. pep.

    I could deploy a french + english bot

  202. Zash

    MUC deos have that "primary langage" field that we're using now :)

  203. MattJ

    I don't think in this case you are the exception

  204. MattJ

    In reality we all speak different languages, but each room does tend to have a primary (and sometimes a preferred secondary)

  205. pep.

    and that bot would not just use french or english, it'd used french and english

  206. MattJ

    I really don't think it harms anyone for the bot to be just like anyone else

  207. MattJ

    It can

  208. MattJ

    But it can't mix both in one message

  209. pep.

    in one <message>?

  210. MattJ


  211. Syndace

    my thought process was that bots are probably the only real use-cases of a message with multiple bodies in different languages

  212. pep.

    why not, I'm not sure I get it

  213. Zash

    Normala människor don't mix olika språk in the same meddelande!

  214. Syndace

    but if the multiple bodies is a think you'd rather see die (which I can totally understand) then I will remove the support

  215. Zash

    pep., most bot interactions is responding to humans, right? just respond in the same language and things should be fine.

  216. Zash

    so !ping would respond pong and !shtrudel would reply kartoffel

  217. Zash

    easy peasy

  218. pep.


  219. pep.

    That's fine when answering maybe

  220. pep.

    Not when initiating

  221. pep.

    (I'm only reading now what's being said above)

  222. Syndace

    anything else matt? 🙂

  223. MattJ

    If you're in any doubt, you should dig up the previous xml:lang discussions

  224. pep.

    which ones!!

  225. MattJ

    Yes, there was something else, let me check

  226. pep.

    Somebody(tm) should write an informal XEP about @xml:lang

  227. pep. adds that to XEP ideas

  228. MattJ

    Oh, I think it was just the naming "allowed response" - it makes it sound like other responses are disallowed

  229. Syndace

    well they probably are

  230. Zash

    Oh no

  231. Syndace

    if you reply "lol maybe" to memberbot it won't be happy

  232. MattJ

    I don't think that's necessarily the case

  233. Zash

    My freedom to reply "lol maybe"!!!

  234. MattJ

    Providing shortcuts for common responses, but also allowing freeform responses is definitely a valid use case

  235. pep.

    Zash, and the bot's freedom not to listen to your "lol maybe"!

  236. Syndace


  237. Zash

    pep., mutual freedom, mmmmmmmm

  238. MattJ

    and for legacy client's it's a reality you'll have anyway

  239. Syndace

    taking ideas for alternative element names :D

  240. MattJ

    Oh no, that's the hard part!

  241. Syndace

    right xD

  242. Syndace

    maybe just response, there should be no ambiguity as we're using a namespace anyway

  243. MattJ

    Yeah, that sounds good

  244. Zash


  245. moparisthebest

    Next you'll be asking about the proper first array index and the lua devs will pipe up and it'll be all out war!

  246. pep.

    https://wiki.xmpp.org/web/XEP_ideas/@xml:lang !

  247. flow

    https://xmpp.org/extensions/xep-0045.html#roomconfig: really stupid question: do I have to submit all fields with values or just the changed fields with their new values?

  248. MattJ

    flow, "yes" ;)

  249. flow

    ahh the universally valid answer

  250. MattJ

    flow, as far as I'm concerned you can just submit the changed fields, but I don't think it is actually defined what happens to the rest

  251. pep.

    the latter?

  252. pep.


  253. MattJ

    Other than "default"

  254. MattJ

    which for Prosody at least means "whatever it currently is"

  255. flow

    smack currently sends all values, but I see a possiblity to save bytes on the wire!!!

  256. MattJ

    Yeah, I think it's sensible

  257. MattJ

    But I can't say that another server won't reset all the missing fields to their defaults

  258. flow

    lets see what ad-hoc commands do…

  259. flow

    hmm ex11 and ex12 in xep50 not helpful

  260. flow

    hmm ex11 and ex12 in xep50 are not helpful

  261. flow

    is that really not defined? :(

  262. MattJ

    Syndace, I'm also unsure about whether responses or actions should be limited to the previous message

  263. MattJ

    Responses, probably, I guess... since there is no id

  264. MattJ

    But actions, a bot could (and probably would) put a sensible unique id on each action, that's up to the bot

  265. Syndace

    I obviously had the bot use-case in the back of my mind and I think having responses to messages that are not the last would probably only cause confusion and nothing else

  266. MattJ

    If I push some more commits to the same PR, it might cause another notification, but the 'merge' button could have the same id

  267. pep.

    You're starting to comfort me that these may be two different use-cases

  268. MattJ

    If it's a textual response then yeah, it's not clear what it's replying to

  269. Syndace

    for actions it's not limited to the last message but the last message that contains actions. A bot _could_ obviously assign unique ids to every action it ever sends out, but that's not guaranteed and if it doesn't things become weird

  270. MattJ

    (without the in-reply-to thing we discussed)

  271. MattJ

    If it doesn't, that's the bot's responsibility. I just gave an example of non-unique ids being fine

  272. MattJ

    It's likely worth mentioning, but I don't think it is necessary to forbid actions on older messages

  273. pep.

    I also find this weird

  274. Syndace

    but if there's a new message with a new merge button, do you think it's valuable to have the change to trigger the action on the old message?

  275. pep.

    I wouldn't forbid it

  276. Syndace


  277. pep.

    I don't think we can do much about this until threads or whatever other magical solution

  278. pep.

    If there's an id and I support it, I'll use it

  279. pep.

    if it's between people, they'll figure it out

  280. Syndace

    > I don't think we can do much about this well what we can do it say that only the newest actions should be accessible

  281. pep.

    Syndace, what if they're different?

  282. pep.

    Why would you prevent this

  283. Syndace

    but I can remove that restriction and add a note that this should be kept in mind

  284. pep.


  285. pep.

    "There might be cases where.. *handwave-maybe-somebody-will-figure-out-a-solution*"

  286. Syndace

    yeah right, will do that

  287. pep.

    And hope you get feedback from implementing clients

  288. Syndace

    yeah. first of all I hope it gets accepted as experimental 🙂

  289. Syndace

    the changes we're discussing right now are already too advanced for a protoxep that might just get rejected 😀

  290. pep.


  291. MattJ

    It would be a bit weird if two PRs came in and only the second one had a merge button

  292. pep.


  293. Syndace

    hmm that's true

  294. pep.

    Maybe the merge button can actually be "merge !234" and "merge !345"

  295. Syndace

    yes I'm convinced, for actions it doesn't make sense to limit the messages just because the dev of a bot might mess up the ids

  296. pep.

    I find the current experimental XEP updating flow a bit weird. An author pushes changes, doesn't open any thread on standards (they're the author after all, they can just push things), I have feedback that I won't be able to get in before it gets pushed. Changes get pushed, new revision, my feedback is heard, another revision

  297. pep.

    We could have skipped an editor roundtrip in between

  298. pep.

    I kinda prefer what's happening with MAM atm

  299. pep.

    What would be a use-case for allowing registering accounts (IBR2) after bind

  300. Syndace

    Quick Response updated, here's the rendered version: https://syndace.com/xeps/inbox/quick-response.html

  301. Syndace

    pep. I'll remove the WIP now I guess, this should be ready to be voted on, even if it's not perfect yet

  302. pep.

    gogo, I'm merging stuff nao

  303. Syndace


  304. Zash

    Nit: In general, data that's to be considered "content" ought to be in text elements, and attrs should be used for more metadata-ish things.

  305. Syndace

    ah interesting, was wondering when to use which

  306. Zash

    I forget if this is mentioned in some XEP but otherwise it's a general XML guideline thing.

  307. pep.

    I'm unsure if buttons should be removed from the inbox though

  308. Zash


  309. Syndace


  310. Zash

    Seems a weird thing to do

  311. Syndace

    If this should be seen as a totally new protoXEP, buttons should probably not be removed. If this is seen as a rework of buttons, then it _os_ buttons

  312. Syndace

    If this should be seen as a totally new protoXEP, buttons should probably not be removed. If this is seen as a rework of buttons, then it _is_ buttons

  313. Syndace

    I mean, locally I didn't `rm` buttons but I `mv`ed buttons to quick-response 😀

  314. Zash

    This is why working on protoXEPs is generally discouraged

  315. pep.

    Zash, how do you rework refused XEPs?

  316. pep.

    To repropose them once feedback is integrated

  317. Zash

    Why couldn't that be done in experimental?

  318. pep.

    Don't ask me, I'm not part of council rejecting stuff :p

  319. pep.

    Don't refuse protoXEPs, people wouldn't have to work on them :P

  320. Zash

    I wasn't on council then

  321. pep.


  322. Syndace

    can the author of a rejected protoXEP ask the editor to remove that rejected protoXEP from inbox?

  323. Syndace

    If so I'd propose that Zash just formally asks pep. to remove buttons and we're good 😀

  324. Zash

    I'd say leave it. It was voted on, it's good to be able to go back and see what that was.

  325. Syndace

    fair enough

  326. pep.

    Syndace, can you do that? unrm it

  327. Syndace

    on it

  328. pep.


  329. pep.

    Zash, on a related note, I want to work on ToS (inbox/tos.html) and if possible keep the name, how to do? :p

  330. Zash

    oh glob

  331. Syndace

    there we go, feel free to squash obviously

  332. Syndace

    hmm now I wonder whether I should remove all traces of buttons from quick-response

  333. Syndace

    like old version blocks and zash as author

  334. Zash


  335. Syndace

    whatevs, if that's not an editorial issue leave it at that

  336. Zash

    Let's not try to determine if this constitutes an original work or a derived work.

  337. pep.

    I'm fine with that I've got a signed message from the original author

  338. Syndace

    nah it's cool, feel free to merge now

  339. Syndace

    I hope you don't have to wait for the pipeline 😀

  340. pep.

    I do, to update xmpp.org at least

  341. Zash

    > this is not always the case due to reasons