XSF Discussion - 2022-06-01

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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.

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.

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

https://matthewwild.co.uk/share.php/6f7928f5-264f-4b99-9448-c4242e63d353/Screenshot_20220601-105723.png

https://matthewwild.co.uk/share.php/48a62fb3-e918-40d6-970f-e82878cd46fd/Screenshot_20220601-105639.png

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

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

Data forms have everything to do with UI

When clients display them to users

Responsive is a web dev term to me

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

I'm sure converse can build a responsive form

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

What information is missing

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

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

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

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.

I've had*

Yeah, good example

>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/

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

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

https://xmpp.org/extensions/xep-0335.html

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

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

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

it can be responsive too.

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

No exactly sure about the security implications though.

"Complete this game of Tetris to enable the thing"

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

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?

XEP-0141 seems to add light layout caps

like adding a section or have different pages

but thats about it

MattJ, probably searches for much more detailed layout

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

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

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

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

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.

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 ..

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

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

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

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

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).

Egg, meet chicken?

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

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

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

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

without inventing there own iq flow

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)

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

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

but of course the fields should be fixed than

Yep

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

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

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

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

as its very expert use case

MUC config is dataforms, but not ad-hoc

yeah sorry

actually it does not matter if its adhoc

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

the problem for MattJ is the dataform rendering

it does not matter in which context

but its really dataform rendering ...

not adhoc

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

and server config is not really neccessary at all

not even sure admins use this

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

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

Step 0: define scope of that 🙂

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

adhoc on account is already available

Something like XEP-0133 but for users?

Adhoc is only necessary for transport config and server admin config

thats the reason its last on the list for every client

these are not important things users need

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

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

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

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

and then add a notification thingy on top

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

because many servers offer already on adhoc account options

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

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

Why?

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

the reason clients dont implement adhoc is because its not needed

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

there is zero reason for any client to implement adhoc

lovetox: except for configuring stuff

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

no, nobody even knows what a bridge is

no, nobody uses XMPP!

I beg to differ

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

We see plenty of non-technical people actively wanting bridges

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

they want bridges, they dont want to configure them

they simply want them to work

and most work fine without any configuration

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

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

then saying, clients dont implement it because its to complicated

hence lets not use adhoc

no event another iq flow, with 2 attributes less

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

https://cerdale.zash.se/s/liKMWWH34XlTeqJG_jRqm2VB/823603e4-9b69-4287-ad79-26d6584fd749.png

accurate

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.

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).

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

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

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

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

clients implement jingle, adhoc is laughable

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

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

this is certainly not trivial

but is not inherent to Adhoc

a muc configuration form is also a dataform

a IBR flow has also a dataform

+ 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

correct, for IBR everybody uses the same dataform basically

Conversations never had a dataform UI, and IBR worked fine

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

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

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

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

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

In Metronome that is

> 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.

(Not just Conversations.)

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

sure, maybe that can be a bot