XSF Discussion - 2024-08-29

lovetox, cal0pteryx: gajim.org is down; both the website and the xmpp server (and by extension your public channel)

Thanks lissine

Someone walked on the powerstrip while going to bed last night.

I have witnessed a cleaner unplugging a rack to do plug in the vacuum, once. Still get shivers.

That's literally a Dilbert comic.

ah no, that was management unplugging the server.

http://www.chillicheese.plus.com/dbert131001.gif

Well, it wasn't a rack in our case, since we didn't have racks - they were too expensive, and most of the machines were tower-cased machines, except Toyota's vast monstrosity. And this was, I think, before Toyota had their machine there. Same office blew the power once and had to power these servers by daisy-chaining four-way adapters from the shop downstairs. Good times.

For attendees of the upcoming UK sprint, I've created a dedicated MUC for before and during the event: xmpp:uksprint@rooms.modernxmpp.org?join

I'm noticing that in XEP XML files, some XEPs are being referenced by an XML entity (eg `&xep0030;`) while others use a HTML `cite` element (eg `<cite>XEP-0030</cite>`). The latter doesn't seem to do anything with regards to rendering (there's no link to the reference list, for example. Should _all_ references to XEPs be an XML entity?

I remember there was an open issue about referencing authors by entities, because it was mixed there as well. So I think entities are the way to go

jonas’ I think you did the last rewrite of the rendering. Any thoughts?

Guus, yes, they should all be entities.

Thanks

I tried to brute-force my way through this: https://github.com/xsf/xeps/pull/1377

Which fails the validation step. I probably messed up.

Do our validation scripts work only when a PR changes exactly one XEP?

Guus, try splitting xep-README.xml xep-template.xml into a separate PR?

Zash, I did that, didn't help

I'm now experimenting with the invocation. I think something is off with multi-file processing

Yeah, it's now less broken (but still broken).

aaah, as I now changed many files, each file will be evaluated, causing failure if something else in that file isn't correct (like a missing approver).

https://github.com/xsf/xeps/pull/1378 fixes part of it.

For mass editorial changes like that it's fine to ignore the tooling failures imho

Are there restrictions to the string used for the "node" attribute of adhoc commands? Is it a good idea to provide something namespacey like node='https://slidge.im/commands/admin'? Is there a registrar for such nodes, so that clients can maybe provide a less generic UI, such as not using the command "name" (translation, adaptation to potential client-specific terminology)…?

nicoco, https://xmpp.org/registrar/nodes.html ?

so this could have a new section "adhoc command"? I only see "Nodes for Service Discovery and Publish-Subscribe" right now :)

Heh, > Last Updated: 2004-10-11

nicoco: there are no restrictions

For something that will be standardized a namespacy thing is good

For something local to just one service is doesn't matter at all

Were there even a size limit?

No. Unless XML attributes have one

JMP uses nodes like "top up account" with the spaces even

XML attributes don't as per the spec, but parsers might limit them nontheless.

Thanks. I followed JMP design and actually used the nodes as some sort of "category": "step 1" of the adhoc command is a dataform with a list-single field and actual real commands are the "step 2". This is to avoid having a very long list of commands in most, I guess this was the rationale for JMP as well, right?

Personally I'd propose to update AdHoc and add a category="Category Title" or something like that in the list

nicoco: we use nodes like that because we also have a chatbot and those are the chatbot commands

And leave the freedom to the client implementer to adapt its UI

> Personally I'd propose to update AdHoc and add a category="Category Title" or something like that in the list That sounds good to me. ↺

> Personally I'd propose to update AdHoc and add a category="Category Title" or something like that in the list Yes this is something we've considered. We don't quite need it yet but our list of commands is pretty long and will probably get longer ↺

I'm not a big fan of XMPP dictating how I show present things, Forms are "ok", but this is imposing navigations in the clients

The problem being retrocompat, the current hack using step1 as category works in every client supporting adhoc commands, but for your proposal edhelas we need specific support. It will work without support, but we get back to that ugly long list.

Maybe I'd prefer to request all the commands and then do my UI/UX flow how I want based on what I have, actually Movim is already using the node= to find a proper icon based on an internal list

I think the number of supporting clients is small enough I wouldn't worry about that too much. But if course you're current strategy is also quite fine

Oh really? What nodes do you know about to use for icon?

edhelas, it's not necessarily dictating, you could just treat the category as a hint, and ignore it if you have a better UI

> Oh really? What nodes do you know about to use for icon? https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/PZrW1yemD5or/image.png ↺

Here for example

But in the absence of knowledge about what the commands are, I would assume that such categories can only help improve the UI

singpolyma this way of doing also allows me to have nice icons in some forms, like with the toggles

https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/CSKKHUGzIIW0/image.png

These are dataform fields though, it's a related but different thing, innit?

Yes, that's why I said "way of doing" :)

You've convinced me that ~standardized node names and this new "category" attribute is a better approach than. I was thinking it's good for translations too but I just realized XEP-0050 already covers that with the iq get xml:lang attribute in theory, I wonder if that's actually implemented by some clients.

edhelas, do you use that xml:lang attribute when you request adhoc commands?

Nope, but I could

(slidge is not going to use it tomorrow, I have nothing started regarding internationalisation right now, but in the distant future, it may be planned if the stars align)

> For mass editorial changes like that it's fine to ignore the tooling failures imho Not sure if I agree

Guus: the tooling specifically ensures each MR only changes 1 XEP etc, which is normally correct, but in the case of a mass search+replace that doesn't change meaning it's harmful, no?

There's no writing the tooling to decide what's a mass editorial search and replace vs not

So human overriding it and merging anyway is the right way imho

That change shouldn't add version numbers and such either imho

moparisthebest: I modified at least one script to be run once for each file changed. That properly validated the files. Validation found valid issues in files that were modified.

Those issues should simply be fixed, in my opinion.

And you are gonna fix them all now?

The validation I suggested ignoring was simply the "one XEP per Mr" one

Going to give it a try, yes

good luck 😄 if it's gonna cause you to give up I'd argue some fixes are better than no fixes at all, last time I tried to mass fix things it took months to be merged 💀

Do we need revision blocks for editorial changes?

Yes! Very detailed, individually composed for each XEP! /s

Is this even editorial if you change some stuff into an entity representing the same stuff?

The rendered output changes.

But I'm now also pushing missing approver elements, etc

imho no revision blocks since nothing is actually changing, things that should have been linked will be, you aren't changing approver, it was always that, but previous tooling didn't enforce however But I know before Kev had differing opinions :)

Guus: oh for context it was merged without version bumps so now there is historical precedent for this exact thing: https://github.com/xsf/xeps/pull/1265

I think that the current PRs fix all remaining validation errors

There's some non-breaking error output when XEP-0384 gets validated that has to do with nesting of certain HTML elements, I think. I'm leaving that for others to address.