jdev - 2025-04-29

I somehow assumed it is possible to respond to a command with a command list. Possibly because I recall some deeply nested service discovery tree in Tkabber, or something (possibly unrelated to Ad-Hoc). Is this actually the case though?

No. You can reply with a form with a list-single for example though

> 2025-04-29T01:45:09Z - singpolyma: > No. You can reply with a form with a list-single for example though List-single won't allow to pick further commands. Duh. Will have to make a huge list if commands cannot be nested then. ↺

bodqhrohro: would you not pick one then next stage is the next list

lovetox: hmm, I'll try. Just afraid it would be less usable than just clicking an item.

Gajim has special GUI for this use case

Just try it

Yes, us too. List-single by itself gets special UI

Really the best thing is to use whatever is semantically best and then badger apps to improve the UI if it doesn't look good

This is a bit of weird question, but does anyone know what SNI and ALPN information clients usually send when connecting to xmpp via websocket?

websocket usually from browser, so SNI must be the server name instead of service name. not sure if alpn is set at all

i try to fix a test in Gajim which fails on xmpp:user@[::1] , it says this is not a valid IRI, it means this should be excaped xmpp:me@%5B::1%5D

now i tried to prove the opposite by ready https://datatracker.ietf.org/doc/html/rfc3987#section-2.2

> websocket usually from browser, so SNI must be the server name instead of service name. not sure if alpn is set at all 👍 ↺

there is says ihost can be a IP-Literal and if i interpret the ABNF correctly it allows the [ ] chars

> ✏ ↺

> ✏

<

&lt;

> This is a bit of weird question, but does anyone know what SNI and ALPN information clients usually send when connecting to xmpp via websocket? Browsers would send SNI and alpn of http1.1 or h2 almost surely, ancient libraries might not send alpn ↺

brand new stuff might send these in ECH 🎉

>> This is a bit of weird question, but does anyone know what SNI and ALPN information clients usually send when connecting to xmpp via websocket? > Browsers would send SNI and alpn of http1.1 or h2 almost surely, ancient libraries might not send alpn 👍 ↺

Any ECH stuff that I could use to test? I wonder if my multiplexing setup supports that ✏

>> This is a bit of weird question, but does anyone know what SNI and ALPN information clients usually send when connecting to xmpp via websocket? > Browsers would send SNI and alpn of http1.1 or h2 almost surely, ancient libraries might not send alpn Surely any http alpn would be wrong for websockets ↺

No, because websockets are http

> Any ECH stuff that I could use to test? I wonder if my multiplexing setup supports that aereaux: what multiplexing stuff do you use ↺

I was using sslh, but I've been trying out just using nginx for it

No they are not

Websockets are not in any way HTTP

I don't care what you call them, all I can tell you is that basically any http client from the last decade and all browsers will send an alpn with 'h2' and 'http/1.1' and then upgrade to websocket how those respective RFCs say https://www.rfc-editor.org/rfc/rfc8441 for http2, https://www.rfc-editor.org/rfc/rfc6455 for 1.1

You'll notice here on the alpn protocol registry no websocket is mentioned https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids nor will you find mention of alpn in the above RFCs

> I don't care what you call them, all I can tell you is that basically any http client from the last decade and all browsers will send an alpn with 'h2' and 'http/1.1' and then upgrade to websocket You'll notice zero http clients exist than can speak or upgrade to websocket so this statement is nonsense

Websocket has its own protocol discovery mechanism that predates alpn so probably why they don't bother with it

Oops I missed http3 websockets exist now https://www.rfc-editor.org/rfc/rfc9220

singpolyma: not sure what you mean, browsers, curl, and a ton of http libraries do websocket

browsers are hardly http clients. they do contain one. curl also supports imap, ldap, ftp, gopher... so also contains and http client but many other things. no http libraries do websocket

If you would like to be triggered even more, Webtransport uses an alpn of h3 and claims to be http3 and has protocol negotiation *inside* of it https://www.ietf.org/archive/id/draft-ietf-webtrans-overview-09.html#RFC9220

I don't know what your point is, http servers do websockets over the http port with http alpn upgraded to using http protocol, those are facts. Whether you want to call it http or not is up to you

> If you would like to be triggered even more, Webtransport uses an alpn of h3 and claims to be http3 and has protocol negotiation *inside* of it https://www.ietf.org/archive/id/draft-ietf-webtrans-overview-09.html#RFC9220 Yes, since http3 is a general purpose transport with a profile for doing legacy http things, this makes sense ↺

I thought quic was the general purpose transport that http3 was built on