jdev - 2023-11-06

singpolyma: certwatch only tries to connect to the ipv6 address for me, which isn't working. Could it be changed so that it tries both ipv4 and ipv6 and give appropriate reports/errors accordingly?

Eyeballs of happyness?

Zash: yes.

i dont see any limitations in the pubsub spec which type a pubsub event needs to have

or did i miss it? So a pubsub event could have "chat" or "groupchat"

I think it's configurable per node

<field var='pubsub#notification_type' type='list-single' label='Specify the delivery style for notifications'> <option label='Messages of type normal'> <value>normal</value> </option> <option label='Messages of type headline'> <value>headline</value> </option> </field>

but according to the form spec only to normal or headline

thats just an example though is it?

its not actually mentioned somewhere which types are allowed

no, that's the registered form

I assume that's normative

ah i see

great

do i need otp bot

i need help

meson: it tres both and fails if either fails

> or did i miss it? So a pubsub event could have "chat" or "groupchat" Groupchat would be pretty odd, but chat is a normal option for some fallback modules ✏ ↺

singpolyma: Yeah I noticed that :-/

singpolyma, I have now removed the redundant AAAA record as I don't use it currently as a workaround

Yeah, if the v6 is broken that is the correct solution

Alright, thanks for your service :)

do you think i can get away as a client in todays ecosystem with simply not supporting START TLS?

Based on https://compliance.conversations.im/test/xep0368/ I'd say no.

Especially when that's a self-selected sample of servers from people who are more likely to want get the 100% score

So one might venture a guess that the real figure is lower

direct tls still isn't default anywhere so I expect most small servers don't have it as well, for example most snikket instances probably don't set the SRV record for themselves

Tho you could do the browser way and slap scary warnings on it and gradually phase it out, but meh.

Start removing the green check for start tls?

fwiw I still haven't bothered on my own setup..

i my mind, if anybody is half serious about operating an xmpp server he needs to adpat the default config

for example i doubt server have per default websocket support, which means if the operator does not add it, webclients will not be able to use it

Haha, ports 5223 and 5270 are registered to other things

i think server operators dont add direct tls, maybe because its simply not necessary for anything ..

nothing breaks if you dont offer direct tls

443 should be the default for direct TLS anyway

Multiplexing is what ALPN is for

No

> for example i doubt server have per default websocket support, which means if the operator does not add it, webclients will not be able to use it IMO most servers should not have nonstandard stuff like websockets added, but maybe that's just my grumpiness about websocket protocol showing ;)

singpolyma, I think it's actually useful, so that people can use web clients that do 0156

whats non standard about it?

singpolyma: I about got webtransport integrated last night but both available crates are missing something so it'll be a bit longer :)

> whats non standard about it? It only exists for browsers, no other client would eve want it, it doesn't discover over DNS, etc etc ↺

moparisthebest: what's missing?

I'll spec clients and servers over that soon and everything can talk http3 over udp port 443 including browsers lol

I wouldn't do it on 443 but I know you want everything there so obviously you can if needed ;)

The most mature one won't let me have access to the certs to do sasl external

The other had something in the way but it was late, I'll look again soon

Can't your existing quic stuff handle that part?

It didn't let me have access to any quic internals was the problem

singpolyma, actually gajim does/did WS

gajim does WS last I looked, that's what I used to test xmpp-proxy's impl

> It didn't let me have access to any quic internals was the problem Oh, it tried to do everything? Yeah, ideally you just need a shim to do the handshake then transition to the regular quic codepath ↺

Yes, the other one looked more like that, gonna poke at it next, was much simpler

Oh right I remember now, it did just do the handshake over QUIC, but only supports doing it or not, when I want to sniff to support both webtransport and regular quic on the same port

The way I support starttls, direct TLS, and websocket on the same TCP port

There is no regular quic anymore, this is the way now ;)

That's solvable I think, but only by touching the library