XSF Discussion - 2020-10-19

  1. lovetox

    question regarding https://xmpp.org/extensions/xep-0077.html#example-6

  2. lovetox

    Username conflict

  3. lovetox

    why is the error in the example type=cancel?

  4. lovetox

    would type=modify not fit much better?

  5. Zash


  6. Ge0rG


  7. lovetox

    it seems really important for IBR

  8. lovetox

    because if it returns the register form with an error, and type = modify

  9. lovetox

    i would not request the form again

  10. lovetox

    instead show the form attached to the error iq

  11. jonas’

    the form may not be included in the IQ error reply.

  12. lovetox

    then i will not display it

  13. lovetox

    and need to request it again

  14. lovetox

    but especially for form errors it is nice to attach the form

  15. Guus

    Even if the suggested modification makes sense, I wonder if changing that now, given that this was defined 15 years ago, would hurt more than it'd bring benefits.

  16. lovetox

    so we have error and the corresponding form with the values

  17. lovetox

    in one single place

  18. lovetox

    Guus, i thought examples are not normative, so can be changed any time

  19. Guus

    Not being normative doesn't mean 'that's how people have been doing it' - I'm not sure if that's actually the case, though, but I'd least consider that such a change might introduce issues for existing implementations.

  20. lovetox

    i dont care much about changing it, but i want to write my code so that if some server dev someday cares about a good user experience for ibr, its at least possible

  21. Ge0rG

    We can't change a Final XEP, can we?

  22. lovetox

    but i dont see how this would cause any problem for an implementation

  23. lovetox

    if a implementation follows the RFC

  24. lovetox

    cancel -- do not retry (the error cannot be remedied)

  25. lovetox

    this would mean a client would not let a user try again on a username conflict

  26. lovetox

    and i guess we can all guess this is very unlikely

  27. lovetox

    so every client already ignores the type

  28. Ge0rG

    lovetox: unless a client is hardcoded to treat type=cancel for retry ;)

  29. lovetox

    then it would not follow the RFC, as it says *do not retry* :D

  30. Ge0rG

    XEP beats RFC

  31. lovetox

    like never, you had one try to register at this server and you failed

  32. eta

    lovetox: haha

  33. Ge0rG

    > Note: Once an XMPP Extension Protocol has been advanced to a status of Final, every effort shall be made to limit the scope of modifications; in particular, backwards-incompatible changes shall not be made. However, limited modifications may be made as long as they are optional, backwards-compatible extensions rather than modifications to the core protocol itself. Therefore, a Final protocol is safe for deployment in mission-critical applications. Good luck! ;)

  34. Zash

    Did the '77 author perhaps simply copy https://xmpp.org/rfcs/rfc6120.html#stanzas-error-conditions-conflict

  35. Zash

    Says <conflict> SHOULD go with "cancel"

  36. eta

    Ge0rG: time for a new XEP

  37. Zash


  38. Zash


  39. eta

    Best Practices for In-Band Registration :p

  40. Zash


  41. Ge0rG

    eta: https://xmpp.org/extensions/xep-0389.html

  42. eta

    I like IBR though :c

  43. lovetox

    does a server support 0389?

  44. Zash

    Does a client support 0389?

  45. eta

    answers: no

  46. Ge0rG

    chicken-egg IBR

  47. lovetox

    i would be willing to implement it, if some server dev also would work on the server side

  48. Zash

    I might have half an implementation somewhere

  49. Zash

    However I imagine it predatest the latest updates and will need some changes

  50. Zash

    Mmmmmm, can haz bookmarks 2 plz?

  51. Zash investigates potentially exponential bookmark duplication bug

  52. Guus


  53. jonas’


  54. lovetox

    Zash, Gajim has a bookmarks 2 impl

  55. lovetox

    if you want to test, there is a switch in advanced config editor to force enable it

  56. marc

    lovetox: i have a wip implementation for 389

  57. marc

    for ejabberd

  58. marc

    The plan is to implement basic registration and enhance it later with token / 401

  59. lovetox

    good to know, i ping you once i have time to work on it

  60. marc

    yep, my client is implemented with aioxmpp

  61. emus

    Why is the /me command actually part of the compliance suite?

  62. Zash

    It's expected of clients to support it

  63. Ge0rG

    emus: because it's my favorite command!

  64. emus understands 🙂

  65. Zash

    Because you didn't invent a XEP to replace it!!1!1!1eleventyeleven!

  66. emus

    just out of interest because I was wondering why this goes to the level of good experience

  67. emus

    (like group chat)

  68. marc

    > just out of interest because I was wondering why this goes to the level of good experience > (like group chat) +1 :)

  69. Ge0rG

    It's about creating a consistent IM experience over different clients.

  70. Ge0rG

    That and Consistent Colors were the most contested additions

  71. Ge0rG

    I'll try to sneak in some more UX this year

  72. Ge0rG

    marc: speaking of which, how do we proceed with 0401?

  73. marc

    Ge0rG: as mentioned before, I have a poc for 389 for ejabberd

  74. marc

    Once that's done I will continue with 401

  75. marc

    Unfortunately, the token thing is not that easy with ejabberd

  76. Ge0rG

    marc: prosody has implemented the token thing already, even both variants AFAICT.

  77. emus

    Sure, it's not that I dont like it

  78. marc

    Ge0rG: not based on 389 I guess?

  79. Ge0rG

    marc: no, because of chicken and eggs

  80. marc

    Yes, I don't like the solo action of prosedy

  81. Ge0rG

    The solo action of fixing a long standing problem?

  82. Ge0rG

    Together with two (three?) client implementations?

  83. Ge0rG

    marc: when we implemented 401, we had the impression that there is no implementation yet of it

  84. marc

    I don't see lots of new users just because this solo action ;)

  85. Ge0rG

    My goal was to make it fly with minimal new protocol, not to reinvent all of IBR

  86. Ge0rG

    marc: have you seen the new prosody invitation page?

  87. marc

    Ge0rG, maybe, I don't remeber... I saw something some time ago

  88. marc


  89. Ge0rG


  90. Ge0rG

    marc: live install on https://xmpp-trial1.ietf.org/

  91. marc

    Ge0rG, nice page :)

  92. Ge0rG

    MattJ: ⬆️👍

  93. marc

    I don't like to approach and the protocol but the page is nice

  94. marc

    Also the blog post

  95. Ge0rG

    marc: users don't care about the protocol

  96. marc

    Ge0rG, sure, I'm not a user ;)

  97. MattJ

    Mistake #1 :)

  98. Ge0rG

    marc: why aren't you using MIX yet, then?

  99. marc

    MattJ, I'm a user but I care about the protocol

  100. MattJ

    So do I

  101. marc

    Ge0rG, sorry but I don't want to waste my little time about useless discussions (MIX)

  102. Ge0rG

    marc: thanks for the excellent idea of using "I don't care about protocol" as my Council 2021 slogan!

  103. MattJ

    I care about the protocol, I also care about getting things done

  104. MattJ

    Where is the new XEP-0401, since the previous attempt at fixing it was reverted?

  105. marc

    MattJ, I sent you a proposal quite some time ago but you never responded

  106. marc

    No blaming, just saying

  107. MattJ

    I think I approved it verbally after looking through?

  108. marc

    No, you had no time

  109. MattJ

    In any case, please don't hold off a new revision because of me

  110. MattJ

    I am sure feedback will come if there are still improvements to be made

  111. marc

    Ge0rG, again, no time for trolling sorry

  112. Ge0rG

    marc: I'm not trolling

  113. Zash

    Hey if I could say "Bring back 2006-era XMPP" and get on Council, why not that?

  114. Ge0rG

    marc: I'd love to have a working and documented way to invite people to xmpp. So far I have to choose between those two, and you know how I chose

  115. marc


  116. Ge0rG

    Working or documented

  117. marc

    Yep, either we have to change it later then or you have to document it properly

  118. MattJ

    The current implementation is working and documented

  119. marc

    Then everything is fine?

  120. Ge0rG

    marc: like this? https://github.com/xsf/xeps/pull/874

  121. Ge0rG

    Now I'm trolling

  122. Zash

    Only Daniel responded to that thread?

  123. Ge0rG

    I could also fork 0401 or make a new "Using 0401 with a pre IBR IQ" XEP. But that would require 0401 to be in a stable state

  124. marc

    Ge0rG, what is your question?

  125. Ge0rG

    > marc: speaking of which, how do we proceed with 0401?

  126. marc

    Ge0rG, you know my standpoint, no?

  127. MattJ

    As I see it, the XEP was stalled with no implementations and unanswered questions. Out of necessity we figured out a solution, implemented it in 4 clients and 1 server. The update wasn't accepted, and the XEP has not been updated since.

  128. Ge0rG

    marc: so we are not going to reach agreement?

  129. MattJ

    The preauth iq was chosen for maximum compatibility with all current and future IBR mechanisms

  130. jonas’

    MattJ, appeal to council to transfer authorship of the XEP and get it documented?

  131. marc

    Ge0rG, MattJ I don't care what you guys do but I don't like the approach so I won't spend on it

  132. Ge0rG

    marc: I'd like to document our approach under the XSF umbrella

  133. marc

    But document it if you like

  134. marc

    Ge0rG, sure, I won't block it

  135. marc

    Why would I?

  136. Ge0rG

    marc: you already did

  137. marc

    Ge0rG, you should take authorship in that case then?

  138. MattJ

    marc: it matters to me if we don't get an ejabberd implementation

  139. marc

    MattJ, I'm not an ejabberd maintainer nor regular dev

  140. marc

    I'm working on 389 - that's it

  141. MattJ

    I care less about documentation, it is already documented on xmpp.org and modernxmpp.org

  142. MattJ

    But I don't want to see the ecosystem split, or for this to be Prosody-only thing

  143. MattJ

    It's too important

  144. marc

    MattJ, me too

  145. marc

    But I don't want to spend time on a token-only thing

  146. marc

    That's why I'm interested in 389 - that's it

  147. MattJ

    Ok, so can we get the rejected revision of 401 republished?

  148. Zash

    For Attic?

  149. MattJ

    It is already in attic

  150. MattJ

    I link to it

  151. Zash


  152. Ge0rG

    marc: I don't want to disown you. If you are okay with giving me authorship, well, now we are talking. But I'd rather have a separate document with that pre-ibr iq documented, but that requires that you finish 0401

  153. Ge0rG

    It's been in limbo for over a year now

  154. Zash

    Wanna publish something as an Historical XEP?

  155. marc

    Ge0rG, I don't care about ownership

  156. Ge0rG

    marc: do you care about 0401?

  157. marc

    Ge0rG, but maybe it makes sense to make different XEPs for different approaches? I don't know

  158. marc

    Would be nice to have *one* approach but I don't see this atm

  159. MattJ

    marc: can you summarize what makes your approach fundamentally different?

  160. marc

    MattJ, there is no fundamental difference, just based on an extenisble approach (389) which will be implemented sooner or later anyway (my assumption)

  161. Ge0rG

    Version 0.0.1 (2018-01-10) First submission.

  162. Ge0rG

    marc: well, you can't force people to implement 389 by requiring it in a semi related other xep

  163. MattJ

    It seems easiest to me if we do just submit preauth as a separate XEP

  164. Ge0rG

    MattJ: a separate XEP based on what?

  165. MattJ

    What do you mean?

  166. marc

    Ge0rG, I don't want to force anybody

  167. marc

    Ge0rG, just my feeling that we need something extensible anyway in the future

  168. Ge0rG

    MattJ: 0401 still contains TODOs

  169. MattJ

    Ge0rG: well, we'll have to factor out or duplicate common parts

  170. Ge0rG

    marc: nothing wrong to put the working approach into 0401 now and add 389 in that extensible future

  171. MattJ

    E.g. make 0401 only about obtaining URIs/URLs?

  172. MattJ

    And define registration flow in other docs

  173. Ge0rG

    MattJ: fine with me

  174. marc

    sounds good

  175. MattJ

    We are all in agreement about the adhoc commands in 401, right?

  176. Ge0rG

    marc: who should do the splitting?

  177. Ge0rG

    MattJ: yes

  178. MattJ


  179. marc


  180. Ge0rG

    Can we get 402 and 403? 😁

  181. marc

    They're already taken, no?

  182. Ge0rG


  183. Ge0rG

    marc: are you okay with me or MattJ splitting out the registration parts from 0401 into a new XEP?

  184. marc

    Ge0rG, sure!

  185. Ge0rG

    Perfect, thanks!

  186. Ge0rG

    marc: do you want to keep a XEP for the modified IBR that was discouraged by Council, or would you like to aim right for 388?

  187. Ge0rG

    marc: do you want to keep a XEP for the modified IBR that was discouraged by Council, or would you like to aim right for 389?

  188. Ge0rG

    The part that's currently in §5.5

  189. marc

    Ge0rG, No, I would aim right for 389

  190. Ge0rG

    marc: do you have anything written up for 389?

  191. marc

    Ge0rG, spec-wise?

  192. Ge0rG

    Yes, we could aim for two consecutive XEP numbers

  193. marc

    Ge0rG, no, but it's not more than a few lines of text I guess

  194. marc

    I prefer to have a poc implementation before writing something down

  195. Ge0rG

    marc: I'm not sure I want to wait that long

  196. MattJ

    I'm off for a bit, thanks for the productive discussion, I think we're getting somewhere :)

  197. marc


  198. marc

    Ge0rG, I'm afk next week, so if you need something from my side let me know this week

  199. marc

    or the week after, of course :)

  200. Ge0rG

    marc: thanks