XSF Discussion - 2023-08-21

Has anyone authored or planning to create an XEP for requesting an online meeting URL from an HTTP entity just as XEP-0363 is used for http file uploading I am currently using a non standard way of doing this with Jitsi Meet and plan to author an XEP that specifies a standard way of doing this that will be compatible with Galene and other commercial HTTP entities like Google Meetings, Azure Communications and Microsoft Teams.

Sounds like a perfect fit for ad hoc commands

If I was to propose an update to the xhtml xep would it be possible and pass council? Both because its deprecated and because of the history of it

Im asking because I am looking to implement xhtml primarly for easier parsing from the client and for accessibility reasons. And looking to move beyond XHTML 1.0 which would be a namespace bump to my understanding

>singpolyma : Sounds like a perfect fit for ad hoc commands Not sure about ad-hoc commands. I am going to clone http upload xep as the integration between http and xmpp would be my starting point. In an any case, my draft XEP can be found at https://igniterealtime.github.io/openfire-sparkweb-plugin/xep/xep-xxxx-http_online_meetings_01-01.xml for anyone interested

MSavoritias fae.ve: shouldn't really need a namespace bump so long as still using the same XHTML namespace (and I think there's only ever been one...)

I for one would welcome an official un-deprecation of xhtml-im

and probably a general simplification of the xep

I know there is at least a XHTML 5

XHTML5 uses the same namespace as XHTML 1.* though, because it's compatible

but from what i see it seems to just be HTML but XML which basically makes it worse imo. because then there are no benefits

right

didnt check that

There are pretty big benefits in our case, since existing XML parser every XMPP implementation must have can handle it, unlike HTML5 parser which not everyone has one of ✏

And HTML5 parsers can parse the XHTML5 syntax so it's compatible both ways which is also nice

I would be interested in adding stuff like this built in to the xep for example https://www.w3.org/TR/2010/NOTE-xhtml-access-20101216/

for accessibility

I wouldn't actually be opposed to un-deprecating xhtml, with an absolute ton of security considerations and all that

of course.

and at least a restrictions of the fields imo

its a horrible idea to just bring the whole of html into xmpp input

Restrictions of the fields were already there fwiw

MSavoritias fae.ve: that link appears to be for xhtml2 which is a different thing that never got completed and no one has adopted

hmm

not sure what "restrictions of the fields" means

so excuse the noob question but: Is there anything like that for XHTML 5 then?

singpolyma, not allowing the full xhtml

or are we supposed to get whatever html does?

and translate it

I also have no idea what the process if any looks like for un-deprecating anything, but I'm sure we can figure that out

Progress! 💪

pep.: that's up the the client's needs I guess

this is another one i found interesting

for links https://www.w3.org/TR/2010/NOTE-hlink-20101216/

well xhtml-im was already a subset of xhtml

> Restrictions of the fields were already there fwiw True but if this wasn't enough to stop nearly all the implementations from being vulnerable then it at least needs tweaked ↺

moparisthebest, no spec is going to do that

officially, sure, that's something I think was misguided in the spec. UI tookits have their own HTML cleaner / rendering stuff trying to spec it is part of the issue IMO

I think it just needs "security considerations" that say "treat the XHTML content here as user input and sanitize accordingly"

personally the security aspects are interesting sure

but i want to focus on easier parsing like links and also accessibility

On a related note I've been thinking XEPs should have a "previous CVEs related to this XEP" section

because structured text could greatly improvend

improve it*

MSavoritias fae.ve: for access module I think that's basically https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey now?

hmm. interesting

Isn't plain text best for accessibility?

Xhtml seems like a nightmare for accessibility

Plaintext is a nightmare for accessibility on the contrary

yep ^

one big reason i am going full in on xhtml is because of accessibility

Like you might be tempted to dump it into a webview and then you've got vulnerabilities again

and i want to add a big section and stuff for accessibility

What am I missing? How is plain text not better

> MSavoritias fae.ve: for access module I think that's basically https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey now? hmm thanks. so xhtml 5 it is then

i will look into it.

Because you can't deduce from "foo" that this is accentuated, say, as opposed to <foo>foo</foo>. Or you can't deduce that "bar" has a reference to the previous message. You can't add context to plaintext

I think I've been telling you the same thing for all these years, and you still don't get it :)

*foo* is accentuated , and we already have references

but you have to scan and guess on every message

same with links

its hillarious how many bugs of recognizing too much or too little of a link we still have

or gemini:// links are not linked

Presumably <script> handling not allowed? :')

qy: dealer's choice ;) but I'd suggest not

As a mental exercise id be curious how that could be done safely

I don't know of any UI framework or sanitization library that allows it anyway, for obvious reasons

"the document" would be the message

Well, you could look at WebXDC as an example of an attempt to make that safe-ish

where they intentionally *don't* treat the content as user input in the normal ways, but sandbox the crap out of it instead

but it also doesn't auto-render

what would be the point of sending scripts anyway /thinking

you might as well embed chromium then

or something

Huh

MSavoritias fae.ve: yes, that's basically what you have to do for this "mini apps" use case. but it's really quite a different case from xhtml-im just overlapping tech

Clientside bots could be one. A timer, for example

That is one hell of a reach though

singpolyma, yeah. that could be interesting based on wasm

a wasm specs for embeddable apps in xmpp. and i have a mini ide for lisp

:P

wasm xep*

that could be the only thing that can make it half secure at least imo

F!vx444444444444677gkhj>i<<?gyygyyyyyyyggggygyggyyyyy

Thanks Trung 🤣

Oh crap sory! =]]]

Lmao

> wasm xep* >> WASM XEP * I wonder if this would get Jason interested in XMPP finally, hes been bouncing that idea around for years ↺

they have? could be interesting at some point

I know some of the core WASM people if that would be helpful…

Why not a XEP for executing JVM bytecode

Lua bytecode or I'm out!

I guess we can just use this XEP for running JavaScript as root to implement all these thingshttps://xmpp.org/extensions/xep-0464.html#sect-idm46661752549680 ✏

> On a related note I've been thinking XEPs should have a "previous CVEs related to this XEP" section You meant like https://xmpp.org/extensions/xep-0280.html#security ? ↺

I guess we can just use this XEP for running JavaScript as root to implement all these things https://xmpp.org/extensions/xep-0464.html#sect-idm46661752549680 ✏

>> On a related note I've been thinking XEPs should have a "previous CVEs related to this XEP" section > You meant like https://xmpp.org/extensions/xep-0280.html#security ? Exactly like that, awesome! ↺

moparisthebest, if you have CVE IDs on hand, add them like https://github.com/xsf/xeps/commit/c724ddc348a9d1a2264522a8056a34c456dabf4e

Thanks will do

Anyway, i wonder if instead theres a lighter markup language than xhtml that could be vaguely standardised. Apparently none that use xml, but commonmark has become very common for example

No!

We're not having this war again

If "links" are all needed, i feel like id prefer that, since at least its coherent plaintext too

> We're not having this war again 😯 ↺

XHTML-IM or XEP-0393

xhtml \o/

Relay me the headlines from last argument?

It's bad enough when people mistake '393 for Markdown and end up passing unsanitized HTML trough.

qy: markdown is an html superset

All valid html documents are also valid markdown

> I guess we can just use this XEP for running JavaScript as root to implement all these things https://xmpp.org/extensions/xep-0464.html#sect-idm46661752549680 I refuse to run any JavaScript. ↺

root: sorry, it's a MUST you have no choice: > If a set-cookie child has an attribute js='true' then the value of the cookie MUST be executed in a JavaScript interpreter with the highest priveleges possible, preferably as root, and MUST NOT be executed in a sandbox.

root: I will translate it to machine code for you ;)

Oh xhtml cool! UI will be so pretty

> root: sorry, it's a MUST you have no choice: >> If a set-cookie child has an attribute js='true' then the value of the cookie MUST be executed in a JavaScript interpreter with the highest priveleges possible, preferably as root, and MUST NOT be executed in a sandbox. This is forced labor. I will complain to the authorities. ↺

> root: I will translate it to machine code for you ;) This I will do ↺

`insmod v8.ko`

Forced labor? Child labor too? Kindly proceed directly to The Hauge

> Forced labor? Child labor too? Kindly proceed directly to The Hauge ☝️ ↺

(my message probably arrived just now, out of context)

pep.: your explanation arrived without the context of your delayed message 🤷

muha

Nice feature(tm) of clients

I would so wish at some points (or all the time?) clients would tell me "do you still want to send?"

Whenever they get disconnected

There's no way to cancel a message in Conversations even though I see it "Waiting", and nor gajim nor show the messages to be sent

I guess that's tricky because if you are only disconnected some seconds you probably expect it to just send, but hours or days maybe not, so gotta decide on a threshold?

fwiw even just 2 seconds sometimes and you need precision..

Yea... Even worse context dependent

Say you meant to answer someone directly and didn't bother mentioning them. Now someone answers in between. Even threads don't fix this really. Someone can still answer in between in the thread. Replies maybe.. but replies are just as annoying

What is, nowadays, the way for an occupant in a MUC room to have an avatar?

So many XEPs...

vcard-temp?

You could possibly try to do '84 to the room-nick JID

I think with some servers pep avatar also works in muc, but clients seem to basically all use vcard-temp

temporary = forever

There's nothing as permanent as a temporary solution.

Truth

its just one IQ to request the data

its as good as any other IQ with different namespace

We've got this weird issue with Openfire that users of it in MUC rooms sometimes have, but sometimes do not appear to have an avatar. Things get worse with federation, somehow.

I see occasional reports of that just everwhere. I don't really understand it

it's an annoyingly visible issue, that upsets people that use clients with avatar support.

Yeah happens a lot here too

often the users or there clients are at fault

like does anyone see a avatar for MattJ ?

Conversations doesn't appear to show one in the room info screen.

They have an avatar? I have never seen it

My primary clients do not support avatars

If we are using vcard temp for avatars does it mean that with the move to vcard4 all avatars will be there now?

no. they move to pep avatar

Ah

A pubsub thing

MattJ: are you saying you don't have an avatar set so it's not a bug? Because sometimes you have an avatar set, but maybe that's a different jid?

> no. they move to pep avatar What xep is that? ↺

There seems to be only pep bookmarks

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

Ah it was old so i thought it was obsolete :P thanks

Do I have an avatar here?

Spark suggests that I have a vcard-temp with avatar (but does not render avatars in MUCs at all), but Conversations does not show an avatar for my account at all.

singpolyma: no, I have an avatar at least in vcard-temp, not sure about a PEP avatar

But my clients don't advertise it

Well, I suspect poezio might on initial presence

Because people always remark at me having an avatar after I restart it

> Do I have an avatar here? Not for me on cheogram ↺

Oh interesting. So it's just that your client isn't sending the thing in <presence> that makes the other clients bother to check for an avatar

But given that my clients don't support displaying/setting avatars, I've never really considered it a bug

It would be nice if they did advertise it regardless, but given that I don't see avatars at all anyway it's never been a priority to ensure other people see mine 🙂

Could have MUC component poll the vcard-temp and add it to presence at join time or something fun

Poezio used to support sending an avatar fwiw

MSavoritias fae.ve: thanks. Are you in a position to debug my traffic? I'm assuming that cheogram expects a vcard-temp

No idea how i could do it in android sorry :/

MSavoritias fae.ve: thanks. Are you in a position to debug my traffic? I'm assuming that cheogram expects a vcard-temp:x:update element in a Join stanza that you receive from me. Id' like to see if it's in there.

ah ok, no worries.

But its the very latest development build. That came out today

Guus: I don't see an avatar for you in gajim either

i can debug your avatar Guus :)

give me a minute

I think that Spark does not include the avatar hash in the join presence

Which does not explain why conversations does not detect my own vcard at all, but that's probably a separate issue.

currently you do not advertise one

at least not in this room

but i can tell you for example, Gajim would also not look into your vcard-temp

we only use pep with 0084

could be that conversation does the same

ejabberd and prosody have conversation mods for vcard-temp <-> 0084

Ok, one thing at a time. I'm going to dig into Smack first, to see if I can get that metadata included.

one thing that i wanted to mention regarding missing avatars is also prosodys conversation mod, which respects the pubsub privacy setting

which is a good thing, but if a user in Gajim sets his avatar for example to private, this means no MUC participant will see it

Last I checked conversations uses only vcard-temp for MUC participant. lovetox you're saying in Gajim it sees the vcard-temp advertisement in presence and uses that to do a user avatar pep fetch?

no

for a client to advertise a hash, it needs first detect that the user has a avatar published

where does it look for it?

Gajim only looks on pubsub

i reacted to Guus > Which does not explain why conversations does not detect my own vcard

maybe his avatar is published in the vcard-temp store, but conversations only looks on pubusb

oh, yes, that's very likely

There aught to be a conversion in Openfire

Do I have an avatar now?

oh, I was already here on another device with the same nickname - unsure if that messes things up

probably happened a thousand times before

also still shwos up as G here

yes Guus, your avatar shows now

Here too

yey

I closed down Conversations to cause a fresh rejoin of the room. Modified Spark to actually send avatar updates as part of the join stanza.

Rejoining with Conversations...

Does XEP-0084 require specific support from the server, other than supporting PEP?

Guus: no

Thanks MattJ.

I wonder if part of the avatar issues that we're seeing are caused by the addressing that Openfire applies. This suggests that each client uses a _different_ avatar. I believe that's perfectly following the spec, but may lead to confusion among users. https://xmpp.org/extensions/xep-0163.html#notify-addressing