XSF Discussion - 2019-08-05

  1. rion

    Is there any description of transport negotiation for https://xmpp.org/extensions/xep-0338.html ?

  2. rion

    I guess it's like 1) all content element in group MUST describe the same transport 2) an implementation should assume 1 and take any to start negotiating. 3) during transport negotiation it doesn't matter which content name in group is used for transport-info messages 4) after the transport is negotiated all the content in group is considered to be ready to transfer data.

  3. fippo

    https://tools.ietf.org/html/rfc6120#section-4.7.3 -- do we have any good reference for the "random and non-repeating" requirement for the stream id? I'm fairly sure we didn't come up with it ourselves

  4. Ge0rG

    it sounds like uuid v4 or something

  5. fippo

    i recall "take the timestamp and add something random" in that context. but not sure from where. maybe dwd remembers?

  6. Ge0rG

    fippo: that sounds like uuid v1 and v2

  7. Ge0rG

    marc_: ping. Do you have short-/mid-term plans to work on XEP-0401?

  8. marc_

    Ge0rG: I'm at a point where it would be nice to meet with other people to discuss how to integrate this feature for good UX

  9. jonas’

    meet? like, in meatspace?

  10. Ge0rG

    marc_: then you should go to a Sprint.

  11. marc_

    Also, if we should rely on PARS and so on

  12. Ge0rG

    marc_: I feel that the unfinished state of 0401 is distracting people from implementing it

  13. jonas’


  14. Ge0rG


  15. Ge0rG

    I have very strong opinions regarding PARS.

  16. marc_

    Ge0rG: what opinion?

  17. Ge0rG

    marc_: PARS is a very good fit for the use case.

  18. marc_

    Ge0rG: yes, for this kind of discussion "we" need to meet in person

  19. marc_

    Ge0rG: why do you ask?

  20. Ge0rG

    marc_: Are you coming to FrOSCon? That will be probably the only chance in the next months.

  21. Ge0rG

    marc_: other than that, email / xmpp should do it.

  22. Ge0rG

    marc_: and I'm asking because one day, The Editor will realize that it's actually Deferred by now.

  23. pep.

    Don't say it too loudly

  24. marc_

    Ge0rG: I don't know when is FrosCon?

  25. jonas’

    oh right, I forgot to run The Script

  26. pep.

    this weekend

  27. marc_

    Then I'm not at Froscon 😄

  28. Ge0rG

    marc_: I want to finally make 0401 usable, and integrate it in the next yaxim release.

  29. marc_

    Ge0rG: do you know if somebody else is interested in this feature?

  30. Ge0rG

    marc_: Anu from Monal is interested in easier user onboarding, and I'm sure we'll find more non-stubborn people

  31. marc_

    Ge0rG: what's your timeline?

  32. pep.

    I'd also like PARS tbh, but just IBR in poezio is a pain (in slix actually)

  33. marc_

    pep.: pars != ibr

  34. marc_

    pep.: maybe I don't get what you want to say

  35. pep.

    marc_, yeah ok not 401, but IBR does count into onboarding

  36. pep.

    hmm, 401 does mention ibr

  37. marc_

    Yes, but pars is without ibr

  38. marc_

    I would prefer 401 without pars at all

  39. pep.


  40. pep.

    Also https://xmpp.org/extensions/xep-0401.html#preauth-ibr

  41. marc_

    pep.: 401 has ibr but pars doesn't

  42. pep.

    Ah sorry I was confused, PARS is not 401 indeed

  43. marc_

    Or let me rephrase: I would like to have 401 with a single use-case without fallback, different UX and so on

  44. Ge0rG

    marc_: what are the UX inconsistencies you see currently?

  45. marc_

    Ge0rG: different behaviour when the Server does not support 401 or ibr

  46. Ge0rG

    marc_: I'm very sure those can be hidden from the users, except obviously when a server supports neither, in which case you are lost.

  47. pep.

    Is there a prosody module for all that btw?

  48. marc_

    Ge0rG: no, you have to choose a server, create a regular account when ibr is not allowed

  49. marc_

    You cannot hide this

  50. marc_

    pep.: no, not for 401

  51. pep.

    marc_, the client can abstract some of it still. At least the choice of server can be really oriented

  52. marc_

    pep.: how?

  53. marc_

    By using a default one?

  54. pep.

    Choosing one depending on $stuff, (user language, location, etc.?)

  55. Ge0rG

    marc_: have you seen the yaxim onboarding?

  56. Ge0rG

    marc_: are you saying that it's better to fail immediately than to provide graceful fallback?

  57. marc_

    No, I would say "invite" is invitation on a server. Everthing else is adding a contact

  58. marc_

    Then it is clear what will happen

  59. Ge0rG

    marc_: but the user wants to get both in one step

  60. Ge0rG

    A user doesn't care what kind of tech magic is behind, they want a simple and fast onboarding

  61. marc_

    Ge0rG: create account + mutual subscruption of couree

  62. Ge0rG

    marc_: I'm just saying that it makes very much sense to use the same PARS mechanism for the out of band invitation transmission

  63. marc_

    Ge0rG: however, I would split add contact (with server pars) and account invite

  64. Ge0rG

    marc_: but why?

  65. marc_

    But the UX changes if ibr is not supported

  66. marc_

    And different UI for the same "invite" sucks

  67. marc_

    Different UI because some tech stuff in the background sucks IMO

  68. marc_

    Different UI because some tech stuff in the background is different sucks IMO

  69. Ge0rG

    marc_: what's different about the UI?

  70. marc_

    (Not) able to create an account, as said before

  71. Ge0rG

    marc_: the difference is what comes behind the @ in the dialog.

  72. marc_

    Yes, sometimes you have to choose a server

  73. Ge0rG

    You as the invitee should always be able to choose the server.

  74. Ge0rG

    And still send up with your friend added

  75. marc_

    Yep, at least when you add a contact

  76. Ge0rG

    No, always.

  77. marc_

    But that's what needs to be discussed :)

  78. Ge0rG

    You don't need 0401 for manually adding friends

  79. marc_

    Yep, you need it for account creation and server-side pars

  80. Ge0rG

    marc_: that reads like we agree

  81. Ge0rG

    marc_: and I was asking because 0401 needs some text improvements, and I wanted to step up

  82. marc_

    Ge0rG: I don't know if we agree but would be nice if you discuss 401 with other xmpp guys at froscon

  83. marc_

    Ge0rG: I really would like to see some movement on 401

  84. marc_

    I think At the end of this month I have time to work on it

  85. Ge0rG

    marc_: are there still text improvements to be made?

  86. marc_

    Ge0rG: in 401? Of course, there are even some TODOs IiRC

  87. Ge0rG

    marc_: because that makes it hard to pitch it to developers

  88. marc_

    You can not pitch it, just pitch the idea :D

  89. Ge0rG

    marc_: and they will ask for the XEP

  90. marc_

    XEP is not a big deal once all agree on the same user story / use case

  91. marc_

    Ge0rG: what's the timeline for the next yaxim release

  92. Ge0rG

    marc_: I have no idea, sorry.

  93. marc_

    Ge0rG: okay, sounded like you plan a release in the next few weeks :)

  94. Ge0rG

    marc_: no, but other developers do