XSF Discussion - 2022-06-01

  1. MattJ

    There night be room for a simpler ad-hoc protocol perhaps

  2. MattJ

    It wouldn't be too hard to implement on the server with the same underlying commands

  3. MattJ

    But I think it's mainly forms that are the issue

  4. MattJ

    Building good UIs is hard, and just chaining together a bunch of controls of different types doesn't suffice for anything but the most basic prompts

  5. MattJ

    I spent a whole day implementing a user-friendly time zone selector recently, and there's just no way it could be reasonably done with data forms, and yet I don't expect every client to implement a timezone selector control just for the 1 or 2 services that might use it

  6. MattJ

    The logical step up would be allowing a HTML/CSS form, but the problems with that are hopefully obvious

  7. mathieui

    Should I summarize with "we can never have nice things"

  8. MattJ

    HTML 5 has a lot of form-related improvements that XEP-0004 doesn't, and if we don't adopt HTML itself and still want to pursue dataform UIs, we'd probably want to at least adopt some things that HTML has gained

  9. MattJ

    But then client complexity increases, and will ultimately warrant a HTML renderer (i.e. web view) and then in 10 years people will be complaining that we didn't just allow HTML forms

  10. MattJ

    And all of this falls into the products vs protocols dichotomy, since it's only needed when the clients are supposed to interoperate with arbitrary unknown services

  11. MattJ

    A client could instead support a nice native UI for biboumi configuration

  12. goffi

    MattJ: what was needed for your form? Would something like XEP-0141 helps? Regarding the particular time-zone selection, this seems generic enough to me to worth a dedicated field-type.

  13. goffi

    But yeah HTML/CSS forms would be interesting, I've had similar thoughs when I've been working on the ad-hoc based remoted control.

  14. goffi

    despite obvious security implications, there would be issues also for TUI/CLI clients, or any UI libraries not supporting direct HTML rendering/webview (like Kivy). But still, it would be nice to have.

  15. MattJ

    goffi: to be fair most of the complexity ended up on the server side for that (gathering, formatting and sorting the available options). Things that wouldn't be possible in XMPP currently would be automatically detecting the user's current time zone (available from the browser) and preselecting it for them.

  16. lovetox

    Html/CSS form? So the sender decides how the UI looks? Meh ...

  17. MattJ


  18. MattJ


  19. MattJ

    Example of a responsive UI that just can't be done in XMPP today

  20. lovetox

    I don't know what you mean, what has xmpp to do with UI

  21. MattJ

    Data forms have everything to do with UI

  22. MattJ

    When clients display them to users

  23. lovetox

    Responsive is a web dev term to me

  24. MattJ

    It's not a web dev term, have you used Gajim on a Linux mobile?

  25. lovetox

    I'm sure converse can build a responsive form

  26. MattJ

    Converse doesn't have the necessary information to make a responsive form

  27. lovetox

    What information is missing

  28. MattJ

    If we agree that a good user interface is one that is structured logically for the data it is presenting/requesting, and that a simple flat list of controls often does not suffice, then layout is an important part of the form designer's job

  29. MattJ

    And given that people access the forms on a range of screen sizes and orientations, it is also the form designer's job to ensure it functions well across all of them

  30. MattJ

    HTML/CSS has a bunch of problems, but they do give you the tools to do this. XEP-0004+XEP-0141 do not.

  31. goffi

    In the special case of the experiment I've made with XMPP powered remote control, I've add to make dedicated UI. It would be nice to be able to specify from the sender, and also to add stuff like volume control, timer, etc. Cf. https://www.goffi.org/b/74BwHSApD7w7Tr9L9fvR82/news-control-your-media-player-from-omemo and notably the first video.

  32. goffi

    I've had*

  33. MattJ

    Yeah, good example

  34. Dele Olajide

    >MattJ : Converse doesn't have the necessary information to make a responsive form It doesn't, but it has a plugin that does. https://github.com/conversejs/community-plugins/tree/master/packages/adaptive-cards https://adaptivecards.io/

  35. MattJ

    Right, but XEP-0004 doesn't carry the necessary information, is my point

  36. MattJ

    Am I reading rightly that the converse.js plugin is interpreting Adaptive Card JSON in <body/>? 😬

  37. Dele Olajide


  38. Zash

    👉️ XEP-0141: Data Forms Layout https://xmpp.org/extensions/xep-0141.html

  39. goffi

    regarding the remote control, I was thinging that SVG could actually be a neat way to do elaborated UI

  40. goffi

    and it's XML, making it straightforward to link in XMPP

  41. goffi

    it can be responsive too.

  42. goffi

    and there are plenty of tools that could be used, in particular inkscape.

  43. goffi

    No exactly sure about the security implications though.

  44. Zash

    "Complete this game of Tetris to enable the thing"

  45. Zash

    So, is XEP-0141 something we should obsolete? Or is it just unknown?

  46. goffi

    it has been mentioned twice today, so it's not unknown. But I don't think that there are many implementation in the wild, or are there?

  47. lovetox

    XEP-0141 seems to add light layout caps

  48. lovetox

    like adding a section or have different pages

  49. lovetox

    but thats about it

  50. lovetox

    MattJ, probably searches for much more detailed layout

  51. lovetox

    i think, sure it would be cool, but i discovered no form in the wild where i thought i need to add a custom layout because the simple field list doesnt cut it

  52. lovetox

    so lots of complexity for probably very few and niche use cases

  53. Zash

    > Right, but XEP-0004 doesn't carry the necessary information, is my point So what's missing and what is actually needed?

  54. Zash

    Does chat clients really _need_ full HTML forms (with CSS layouts)?

  55. Zash

    I like to think that a lot of nice things could be done by inventing datatypes with xep-0122 and then having clients do nice things where it knows those data types. E.g. a timezone type could be smart about its default, even show a map selector.

  56. lovetox

    its either css or nothing, like what do you want to do otherwise, invent a whole new layout language that works with all the different ui frameworks out there ..

  57. lovetox

    im all for more hints about what the data is that we should display, and i think this can be easy done

  58. lovetox

    but starting with stuff like "display this filed on the right side from that field"

  59. lovetox

    i probably not going to implement something like that, sounds like a lot of work with very little gain

  60. moparisthebest

    MattJ: yea XMPP can't be taken seriously if you can't implement a proper date picker like https://i01000101.github.io/RedditBadUIBattles/ScientificDatePicker/index.html

  61. Guus starts to slowly clap.

  62. MattJ

    To be clear, I'm personally not advocating adding this complexity into XMPP at all. I just see it as a necessity if we really started using ad-hoc for important things. We don't support this complexity today, which means ad-hoc commands will never be used for more than very simple things (if clients implement them at all).

  63. Zash

    Egg, meet chicken?

  64. MattJ

    I don't think today's ad-hoc + dataforms leads to good UIs, and that's why I don't push for them in modern XMPP clients

  65. MattJ

    Ad-hoc commands with a native UI is fine, and clients already do this (e.g. for creating invitations)

  66. lovetox

    i thin adhoc has also value in simply providing a flow for whatever

  67. lovetox

    like if some XEP wants to provide some options to configure something on the server etc, they can simply reuse adhoc

  68. lovetox

    without inventing there own iq flow

  69. MattJ

    Yeah, I agree. And as I said earlier, it might be nice to simplify it somewhat (many of the awkward edge cases are caused by features that aren't used)

  70. lovetox

    as a client developer im not against adding a custom UI for some adhoc workflow, (not my standard rendering of a dataform)

  71. lovetox

    if its a good feature and it benefits from a custom UI why not

  72. lovetox

    but of course the fields should be fixed than

  73. MattJ


  74. lovetox

    MattJ, about what are you thinking that you would like to do with adhoc?

  75. Zash

    Yeah, well-known ad-hoc commands with client-side custom UI can be nice.

  76. lovetox

    like until now only server and muc configs are done with adhoc

  77. lovetox

    i think the standard dataform rendering is fine enough for that use case

  78. lovetox

    as its very expert use case

  79. Zash

    MUC config is dataforms, but not ad-hoc

  80. lovetox

    yeah sorry

  81. lovetox

    actually it does not matter if its adhoc

  82. MattJ

    Well that's kind of what started this discussion: why do only the "advanced" clients implement ad-hoc commands + dataforms

  83. lovetox

    the problem for MattJ is the dataform rendering

  84. lovetox

    it does not matter in which context

  85. lovetox

    but its really dataform rendering ...

  86. lovetox

    not adhoc

  87. lovetox

    adhoc of course is a expert use case, because its only used for muc config and server config

  88. lovetox

    and server config is not really neccessary at all

  89. lovetox

    not even sure admins use this

  90. MattJ

    FWIW one thing on my to-do list is a XEP for user account config

  91. moparisthebest

    that would be excellent, could probably get rid of those terrible servers that blanket block all messages from strangers for all accounts

  92. Zash

    Step 0: define scope of that 🙂

  93. lovetox

    MattJ, but what needs to be specified in that XEP?

  94. lovetox

    adhoc on account is already available

  95. Zash

    Something like XEP-0133 but for users?

  96. lovetox

    Adhoc is only necessary for transport config and server admin config

  97. lovetox

    thats the reason its last on the list for every client

  98. lovetox

    these are not important things users need

  99. lovetox

    thats the reason in my opinion, and certainly not because its "to hard to implement"

  100. MattJ

    moparisthebest, yes, that's definitely one of the first things I would like to expose and standardize

  101. MattJ

    lovetox, on my list of things the XEP should support: a registry of options, types, an ad-hoc command to fetch and set them, and a mechanism to get, set and subscribe to changes in individual options

  102. lovetox

    so basically you specify a set of options which should be available via adhoc@account

  103. lovetox

    and then add a notification thingy on top

  104. lovetox

    i think this is great, please stay with adhoc for fetching and setting the options

  105. lovetox

    because many servers offer already on adhoc account options

  106. lovetox

    it would be less ideal if i have to merge this with some other mechanism

  107. MattJ

    Ad-hoc will be one way of doing it, but I expect most clients won't use it

  108. lovetox


  109. lovetox

    Again, nothing about Adhoc is complicated or hard to implement, every other IQ flow is exactly the same

  110. lovetox

    the reason clients dont implement adhoc is because its not needed

  111. lovetox

    its basically only used by nerdy xmpp people that want to admin there server

  112. lovetox

    there is zero reason for any client to implement adhoc

  113. mathieui

    lovetox: except for configuring stuff

  114. mathieui

    Even non-nerdy people want to be able to configure their bridged accounts

  115. lovetox

    no, nobody even knows what a bridge is

  116. Zash

    no, nobody uses XMPP!

  117. mathieui

    I beg to differ

  118. moparisthebest

    what do non-nerdy people bridge with? certainly not IRC

  119. mathieui

    We see plenty of non-technical people actively wanting bridges

  120. lovetox

    i dont see your argument, i said there is zero reason to implement this, and you argue "but bridge configuration" which is about the most expert thing there is on xmpp

  121. lovetox

    they want bridges, they dont want to configure them

  122. lovetox

    they simply want them to work

  123. lovetox

    and most work fine without any configuration

  124. lovetox

    im not arguing that adhoc is not useful, im saying its not a good reason to not use adhoc, because "no client implements it"

  125. lovetox

    when the xmpp specs simply have no widley used usecase which uses adhoc

  126. lovetox

    then saying, clients dont implement it because its to complicated

  127. lovetox

    hence lets not use adhoc

  128. lovetox

    no event another iq flow, with 2 attributes less

  129. lovetox

    but im looking forward to see the iq flow that is so much simpler than adhoc, but offers exactly the same functionality

  130. Zash


  131. moparisthebest


  132. MattJ

    lovetox, I want to support setting one option at a time, and that's a bit weird to do via ad-hoc. It would at least turn it into multiple round-trips when only a single one was necessary.

  133. MattJ

    I want to present an ad-hoc interface to the configuration for clients that want to present the configuration all at once to a user (in a native or dataforms-driven UI).

  134. Zash

    {get,set,enable,disable}-${option} ?

  135. lovetox

    MattJ, if there are valid protocol reason to not do adhoc for something, because it does not fit, im all for it

  136. lovetox

    but please dont base any decision on the count of clients that implement adhoc

  137. Zash

    Hm, maybe one could make a thingy that exposes ad-hoc commands via a chat interface, probably on the bare host JID....

  138. lovetox

    clients implement jingle, adhoc is laughable

  139. lovetox

    adhoc is 200 lines of code in nbxmpp, and thats is with boilerplate

  140. lovetox

    i think what people confuse this with is, displaying dataforms in a UI

  141. lovetox

    this is certainly not trivial

  142. lovetox

    but is not inherent to Adhoc

  143. lovetox

    a muc configuration form is also a dataform

  144. lovetox

    a IBR flow has also a dataform

  145. Zash

    + not enough existing commands or other dataforms using things exposed that warrant implementing the UI translation routines, which I hear can be pretty complicated on some platforms

  146. lovetox

    correct, for IBR everybody uses the same dataform basically

  147. lovetox

    Conversations never had a dataform UI, and IBR worked fine

  148. Zash

    It's also got a reduced MUC config interface, which is probably fine for the majority

  149. lovetox

    For MUC config you dont need dataform UI, because most servers offer the standard configs, and only very few addtional

  150. Maranda

    > <lovetox> Conversations never had a dataform UI, and IBR worked fine I dissent slightly on that

  151. lovetox

    Yeah you are one of the very few that adds custom additions to IBR

  152. Maranda

    I had to specifically add exceptions for C not supporting extended fields in IBR or even just the supplemental ones

  153. Maranda

    In Metronome that is

  154. Holger

    > Yeah you are one of the very few that adds custom additions to IBR Chicken egg, I'd love to do that as well, but client side support is close to nonexistent.

  155. Holger

    (Not just Conversations.)

  156. wgreenhouse

    > they want bridges, they dont want to configure them a bridge needs some way to enter authentication/account details for $other_network if applicable

  157. wgreenhouse

    sure, maybe that can be a bot