XSF Discussion - 2020-02-26


  1. jonas’

    This is especially annoying if you are on mobile (*)

  2. jonas’

    only if you have functions enabled which are designed to make your life harder by taking control away *scnr*

  3. Zash

    Is there any reason why you couldn't include a form in the first step of an ad-hoc command? https://xmpp.org/extensions/xep-0050.xml#execute-simple

  4. Zash

    Assuming you know ahead of time what the form looks like, eg because it's standardized by xep-0133 or such

  5. jonas’

    Zash, you could try, and I guess any sane service would allow it (because if it isn’t stateless, you run into fun DoS opportunities)

  6. Zash

    Just got rid of a thing in a convenience wrapper for simple commands that required that one-step commands be stateful.

  7. marc0s

    hi, the `source control` link from `https://xmpp.org/about/standards-process.html#submitting-a-xep` points to `https://xmpp.org/about/xsf/xsf-source-control/` (which 404s) and should point to `https://xmpp.org/about/xsf/source-control.html`. I forked the repo and tried to test it locally but the dev server from isn't rendering the menu, don't know why. I think a plausible fix might be ```diff --git a/content/pages/about/standards-process.md b/content/pages/about/standards-process.md index 303616b..38d8bc1 100644 --- a/content/pages/about/standards-process.md +++ b/content/pages/about/standards-process.md @@ -34,7 +34,7 @@ Here's how to submit a proposal to the XMPP Standards Foundation for considerati 2. Make sure you read, understand, and agree to the XSF’s [IPR Policy](/about/xsf/ipr-policy) before you submit your proposal! 3. Email the XML file (or a URL for the file) to the [Editor Team](mailto:editor@xmpp.org) with a subject line of "ProtoXEP: [your title here]". -Note: It is the author’s responsibility to provide a properly-formatted source file (see the [template](/extensions/xep-template.xml) file maintained under [source control](/about/xsf/xsf-source-control/)). Proposals submitted in HTML, TXT, MS Word, Open Document Format, etc. will be returned to the proposal author for proper formatting. +Note: It is the author’s responsibility to provide a properly-formatted source file (see the [template](/extensions/xep-template.xml) file maintained under [source control](/about/xsf/source-control.html)). Proposals submitted in HTML, TXT, MS Word, Open Document Format, etc. will be returned to the proposal author for proper formatting. #### Editor creates a ProtoXEP ```

  8. marc0s

    also, the `xep-template.xml` file doesn't exist in the website repo, should it be linked to the raw version from the xeps repo maybe (https://raw.githubusercontent.com/xsf/xeps/master/xep-template.xml)?

  9. jonas’

    marc0s: the dev server doesn't render the menu for me either :(

  10. marc0s

    jonas’, thanks for the feedback

  11. jonas’

    marc0s: linking to the xeps repo sounds sane to me

  12. jonas’

    go ahead and make a PR against xmpp.org

  13. jonas’

    thank you

  14. marc0s

    It also needs some updating, the dev server, as `python -m pelican.server` no longer works, at least with debian's packaged `pelican`, needed to use `pelican --listen`

  15. marc0s

    jonas’, I will then

  16. pep.

    yeah there are a few issues that could use some fixing on the website with newer python

  17. MattJ

    Regarding XEP-0313 deferred, please don't LC it

  18. MattJ

    I have an update incorporating existing feedback that I already received

  19. MattJ

    I posted this quite some time ago to people who inspired the feedback, I don't think I got any responses and I didn't follow-up

  20. MattJ

    But given the XEP is widely implemented already I didn't want to just push the changes without agreement that they were sensible

  21. MattJ

    I can dig up what I had done and post it to standards@ or something, or if people think I should just push it as a new revision I can do that

  22. jonas’

    MattJ, please do that

  23. MattJ

    Which? :)

  24. jonas’

    the posting to standards@

  25. MattJ

    Sure

  26. jonas’

    I wasn’t finished reading the message when I replied :D

  27. jonas’

    also, I thnik I’m one of those you pinged and I totally forgot about that and I’d love to check your changes.

  28. MattJ

    Here's a diff I generated: https://matthewwild.co.uk/uploads/stdin-s2ilB8Kj

  29. MattJ

    I can dig up the XML from whichever checkout I had it in

  30. jonas’

    i see before-id/after-id fields

  31. jonas’

    I love it already

  32. jonas’

    {+ <field type='text-single' var='urn:example:xmpp:free-text-search'/>+}

  33. jonas’

    sugegstion: make this {clark}notated

  34. jonas’

    MattJ, I have a bit more of feedback on this, shall I dump it here or 1:1?

  35. MattJ

    If it's brain-dump style... an email? (i.e. TODO item for me)

  36. MattJ

    if it's interactive, I'm fine with here or 1:1

  37. jonas’

    brain dump

  38. jonas’

    email == jid?

  39. MattJ

    Email or 1:1 and I'll copy/paste it somewhere :)

  40. MattJ

    Sure

  41. jonas’

    sent

  42. MattJ

    Received, thanks!

  43. MattJ

    I'll aim to act on that by the end of next week

  44. jonas’

    that sounds amazing

  45. MattJ

    Still without an office, and my work schedule is suffering :)

  46. Daniel

    Question to the server developers. I'm assuming that by now you are all treating muc presence with the x user attribute as full joins. To you remember when you started doing so?

  47. Daniel

    With what version of your respective server software

  48. Daniel

    Wondering if it is time to remove the good old leave before join work around

  49. MattJ

    Looks like it was Prosody 0.11 when we started rejecting GC 1.0 joins

  50. MattJ

    So 2018-11-21

  51. Ge0rG

    There are still many pre 0.11 in the wild

  52. Zash

    Got stats?

  53. Ge0rG

    Ask jonas

  54. Ge0rG

    I only have anecdata of Debian oldstable

  55. Zash

    Debian stable has 0.11, oldstable-backports has 0.11, normal support for oldstable likely ends this year

  56. flow

    IMHO usually the ideal point in time to drop compatibility workarounds or older protocol versions is when its about 2 years after the point in time when you should have dropped them

  57. Zash

    So when do we drop the "MUST support GC 1.0" from XEP-0045?

  58. flow

    now that is something we could drop

  59. flow

    Zash, it appears Smack removed GC 1.0 in 2006

  60. Zash

    Wait, did Ge0rG and I sneakily remove that MUST already or did I imagine it?

  61. Ge0rG

    flow [21:12]: > IMHO usually the ideal point in time to drop compatibility workarounds or older protocol versions is when its about 2 years after the point in time when you should have dropped them May I quote that in https://discourse.igniterealtime.org/t/smack-android-api-requirements/85767

  62. Ge0rG

    Zash: > Therefore, starting with version 1.32 of this specification, it is RECOMMENDED that a service receiving a <presence> without an <x> element from a non-occupant full-JID responds with an explicit kick to that client.

  63. Ge0rG

    Not only we removed the requirement to support GC1.0, we even discourage its use

  64. flow

    Ge0rG, the latest release version of Smack requires Android API 9 or higher, and Android API 9 is Android ~10 years ago

  65. flow

    the upcoming version will bump to Android API 19, which is Android 4.4 released 7 years ago

  66. flow

    so I believe to be reasonable conservative when it comes to supporting old versions

  67. Zash

    Ge0rG, \o/

  68. Ge0rG

    flow: yes, and now just add two more years...

  69. flow

    Ge0rG, already did so two years ago ;)

  70. Ge0rG

    I think i have roughly a dozen patches on top of 4.3 now, either adding new features / XEPs, or providing access to internals which I need exposed, or working around real world implementation issues, like the Dino MUC

  71. Ge0rG

    flow: two years ago it was too early!

  72. marc

    Ge0rG, you have the same problem with 389 as with regular IBR, right?

  73. marc

    tbh, I don't see much advantage of 389 at all

  74. Ge0rG

    marc: no, I see a number of additional problems in 0389

  75. Ge0rG

    proof-of-work just won't work against spammers

  76. marc

    yep

  77. marc

    Okay, maybe we can split 401 and PARS but somehow reference them as Daniel suggested (?) and we're done? :)

  78. Ge0rG

    marc: I think that a split doesn't make sense. Not for the UX and not technically

  79. marc

    Ge0rG, okay, but why didn't you respond to the mail then?

  80. marc

    I see a big advantage in easy account creation

  81. marc

    PARS on top is nice but not a must

  82. Ge0rG

    You don't have to add the contact from 0401. You could also add everybody who used the same token, like with the snikket Demo

  83. Ge0rG

    But those are not the main use case

  84. Ge0rG

    The really important case is adding a friend and having them in the roster automatically

  85. Ge0rG

    Daniel also made a bet on using the phone address book to automatically add contacts.

  86. Ge0rG

    My impression is that he considers this bet as failed now

  87. Ge0rG

    If you remove PARS from 0401, you'll end up with implementations that allow registration from an invitation token, but don't consistently add the contact, so you don't gain much

  88. Ge0rG

    Alternatively, you could move the combined functionality into a third XEP, but what would be the benefit?

  89. Daniel

    To be fair half the implementations do that already

  90. marc

    Daniel, hm?

  91. marc

    do what?

  92. Daniel

    Implement the registration part but not the contact part

  93. marc

    Daniel, what exactly did you implement from 401, btw?

  94. Daniel

    The being 'invited' to a server part

  95. Daniel

    And use the pars token to register

  96. marc

    Daniel, this means you send the token via ibr to the server?

  97. Daniel

    Yes

  98. marc

    Daniel, via IBR or IQ?

  99. Daniel

    Well the weird pre ibr thing

  100. marc

    :-(

  101. Daniel

    I don't have any feelings on that

  102. marc

    I hate it ^^

  103. Daniel

    That was just what's supported by prosody

  104. lskdjf

    > marc: I think that a split doesn't make sense. Not for the UX and not technically Ge0rG, I'm also in favour of spliting the two processes. As a UX developer you want the user to get some sort of image of how the application works. And for "getting a contact into your roster", I'm trying to teach the user that this happens by clicking some specific button(s). If you now start to just magically add contacts to the contact list, you break the image I'm trying to convey. What I'd like to do is to add the contact and then perhaps display a dialog "Anna invited you, would you like to add her?". I know you want to make the whole process easier, but adding more concepts doesn't make understanding easier.

  105. marc

    lskdjf, good point

  106. Daniel

    I think I said this on list but my interest in the registration part is to avoid open ibr for semi public servers (read hacker space, club) where you can stick a qr code on the wall and everyone who has physical access to the building can sign up. But spammers can't

  107. lskdjf

    s/What I'd like to do is to add the contact/What I'd like to do is to add the account

  108. Daniel

    I don't agree at all with the concept of so called easy xmpp

  109. Ge0rG

    lskdjf: that's interesting indeed. But then would you also introduce the concept of presence subscription and its bidirectionality?

  110. Daniel

    Which is fine. There can in fact be xeps that I don't agree with

  111. Daniel

    But I don't like to loose what in my eyes is a valid use case

  112. Ge0rG

    Daniel: the hacker space functionality is there, just use the domain JID URI

  113. marc

    Daniel, sure, my primary use case is a similar one

  114. Zash

    Hackerspace functionality whatnow?

  115. Ge0rG

    It's even implemented in yaxim and prosody already

  116. marc

    Daniel, and sure, you don't have to agree on everything but I would like to have opinions from experienced devs

  117. Ge0rG

    Zash: > I think I said this on list but my interest in the registration part is to avoid open ibr for semi public servers (read hacker space, club) where you can stick a qr code on the wall and everyone who has physical access to the building can sign up. But spammers can't

  118. Daniel

    I know that it is covered. Conversations handles that. But it is a mess to comprehend due to the tight coupling with _shit I don't need_

  119. Zash

    Ge0rG, ah, ours was set up to limit registrations to the local IPv6 network

  120. Ge0rG

    Daniel: but it might be shit that your users need...

  121. Zash

    Everyones needs are different for some weird reason.

  122. marc

    What _shit_ are you talking about?

  123. Daniel

    Well the registration part hooks (at very least semantically) on pars

  124. Daniel

    Which by its name alone is something completely different

  125. lskdjf

    > lskdjf: that's interesting indeed. But then would you also introduce the concept of presence subscription and its bidirectionality? Ge0rG, depends on the application and how detailt the picture is they convey. The easier version would probably be to say that if "contact X on your roster/friend list" == "contact x gets your information"

  126. Ge0rG

    I could very well live with changing 0401 to "if the invitation is from a user bare JID, the receiving client shall perform a roster request with the token as a PARS token. The client may first ask the user for permission / guide them through the process"

  127. Ge0rG

    Would that satisfy Daniel and lskdjf?

  128. Daniel

    I actually read my email again and I think it brings my point across

  129. Daniel

    You say you don't want to separate the two because you are afraid someone will implement the registration without the subscription part

  130. Daniel

    I don't think that's something the xep author should decide

  131. Ge0rG

    Right, the main reason for the XEP should be optional.

  132. marc

    Hm, what about less irony and more constrictive input? 🤔

  133. marc

    Since there is no good argument against IBR, I would like to keep this as-is, or is there a good argument?

  134. MattJ

    Seems like I should have participated in this discussion, but I didn't see it was happening

  135. MattJ

    I don't care much about the protocol - if people don't like the iq thing, come up with something else

  136. MattJ

    I think the argument about making the user do more work to add a contact they want to speak to, just to teach them a lesson is... not sound

  137. MattJ

    We already know the user intent, don't add more clicks or taps than we need to get the task done

  138. MattJ

    They can learn to add contacts next time they want to add a new contact

  139. MattJ

    Getting someone onboarded to the network is enough work already

  140. MattJ

    We need to remove all the friction we can

  141. pep.

    "just to teach them a lesson" I can only read this in a pejorative way, is it how you mean it?

  142. MattJ

    Read it however you want :)

  143. pep.

    I don't think that's how lskdjf meant it anyway :)

  144. pep.

    To teach the user habits, patterns

  145. MattJ

    It doesn't matter, it's what it is doing

  146. MattJ

    You want to talk to a contact, but first we want you to go through some training

  147. pep.

    MattJ, no you got it in reverse

  148. moparisthebest

    to teach the user a lesson we need to implement a XEP I've always dreamed of "remote slapping of a user over the internet"

  149. pep.

    if you allow that to be one and only step, then next time they want to add somebody they'll be like "why did I have to do something this time?"

  150. MattJ

    That's nonsense

  151. MattJ

    Adding contacts is a familiar activity to anyone who wants to add a contact

  152. MattJ

    Throwing popups in the face of a new user is just not what we need more of right now

  153. pep.

    I wish we had real UX people to help us tbh. I'm not qualified for this

  154. pep.

    It seems to me we're all making stabs in the dark

  155. pep.

    not all all but ..

  156. Zash

    moparisthebest, search for "xep poke"

  157. MattJ

    I don't claim to be a UX expert at all. But the effect of adding steps to an onboarding flow is well documented by now

  158. MattJ

    (and it's a negative one)

  159. marc

    > I don't care much about the protocol - if people don't like the iq thing, come up with something else I already came up with something else ;)

  160. MattJ

    marc: where?

  161. marc

    In the XEP?

  162. MattJ

    The current revision?

  163. marc

    The 'regular' way via IBR

  164. Zash

    Rough consensus and running code!

  165. MattJ

    I see a lot of TODO

  166. marc

    True, not saying the XEP is ready just that there is another way how to provide the token

  167. MattJ

    I would need to dig up chat logs to remember the things that drove us to the preauth iq, but not depending on the old IBR was one reason

  168. MattJ

    The "new IBR" is not good enough (currently?) though

  169. marc

    What's the new ibr?

  170. marc

    I don't see any advantage of 398, if you mean that

  171. MattJ

    389

  172. marc

    Whatever ;)

  173. marc

    Where is the advantage for 401?

  174. MattJ

    For 401 alone? None afaik

  175. MattJ

    For XMPP? It would be nice to have a more flexible registration flow in general

  176. MattJ

    (I repeat that today's 389 is not that, but it's a step in the right direction)

  177. marc

    Yep, but that's off topic for 401 and how to provide the token

  178. MattJ

    Not if the answer is simply "do this preauth thing and register however you want"

  179. marc

    I'm afk now, but please let me know if there is a good reason for the IQ approach. I really dislike this approach 😶

  180. Zash

    ^ is why I dislike IBR, weird thing looking like an iq stanza long before that's supposed to be allowed

  181. MattJ

    I agree

  182. MattJ

    I'd love to move away from all iqs before bind

  183. Zash

    At least in Prosody it's not even treated as a stanza, just a weird "nonza" that happens to be in the "jabber:client" namespace

  184. Zash

    ... not anymore. Used to be an uncomfortable amount of of exceptions in a bunch of places that allowed iq stanzas on unauthenticated connections under certain conditions

  185. Zash

    So, it would be nice to get 389 moving again.

  186. marc0s

    should I do something special to have firefox render XEP's XML files? it complains about `XML Parsing Error: undefined entity` while chrome displays it without any problem