jdev - 2022-03-13

Who is planning to implement 0461 ?

edhelas: there's already https://fosstodon.org/@polynomdivision/107921082993522502 apparently

moparisthebest, what is now the prefered solution for websocket?

should i remove it completely?

is there a use case for desktop clients?

i originally replaced bosh with it

but i ask myself now if there is a situation where you would want to use websocket instead of tcp on a desktop

lovetox, when you have a really bad firewall on your network usually.

Or when the server only has that configured.

the firewall thing is stated often, but im not particular inclined to provide a software for people that circumvent their work enviroments

lovetox, the preferred solution for discovering WebSocket (and BOSH) endpoints is to follow the HTTP workflow of XEP-0156.

It’s not just work, it’s also airports, schools, universities, some cafés.

Link Mauve, why you disabled websocket on jabber.fr?

Oh did we?

IIRC there was an issue with some version of Converse, which started preferring it to BOSH, and I didn’t have time to investigate.

At the time, BOSH was generally better than WebSocket, now that XEP-0198 can be done over WebSocket it’s probably the opposite. ✏

Do you do 0198 in that case?

It would be better if this /.well-known/host-meta had a way to tell clients about preferences, but alas the web always has to reinvent SRV poorly…

Converse doesn’t seem to notice websocket being blocked by CSP.

CSP?

i mean in your hostmeta file websocket is commented out

meaning i have no way of testing my code :)

Content-Security-Policy, a browser thing

yes i do 0198 over websocket

is this useless?

because we always know if a message reached the server?

No, 198 is good

The thing is that BOSH has equivalent functionality built in, so WS needs 198 to be comparable

lovetox, it isn’t commented out any longer, but also still not working.

k thanks, yeah its enough for me to retrieve the uri from somewhere

Heh, module:list() | grep websocket → *crickets*

But since we haven’t updated since the previous CVE, I won’t enable it today.

lovetox, I will comment it out again in the host-meta, unless you want to continue debugging.

I will uncomment it once we are ready to reboot the server for upgrades.

hm would be cool if you could leave it until tomorrow

im just finishing the code

That prevents our web users from being able to connect at all. :/

Couldn’t you pick any of the other correctly-configured servers here? https://compliance.conversations.im/test/xep0156/

no, your users can wait till tomorrow

:) of course then comment it out, i take another server

lovetox: websocket is valuable, just needs looked up via host-meta, and I'd probably suggest standardizing on host-meta json, it's in the RFC

In fact I'm going to propose an update to '156 saying that...

but thats to late

now everyone implemented updated it and probably everybody uses whats in the xep the xml

just leave it at that

as this are xmpp clients, all software deals with xml anyway

i dont even know why there is a second solution here

lovetox: because it's in the host-meta RFC

?

And all XMPP clients should be doing posh anyway which is json only

and its also in the XEp

why do you need to standardize on json

The json representation is in the host-meta RFC too I mean

ok you mean thats why its in the XEP

It makes sense to standardize on one instead of always grab both

but it does not explain why you want to remove the xml represantation

moparisthebest, no need to fetch both, as the XRD version is required to be present.

moparisthebest, we dont need to grab both, because one is optional and the other not currently

And fun fact: the example XML in the host-meta RFC is invalid according to the XRD spec, it doesn't validate

if you change this now, THEN we definitly need to grab both

You already have to grab both, I'd like to strongly recommend only grabbing the json

no

json is optional

Also the XRD spec website has a "always valid link to the latest xsd" that returns 404 lol ✏