XSF Discussion - 2021-02-23

==== Reminder to add your news 📝 If you have something to say for February Newsletter now is the perfect time! Newsletter draft on Github: https://github.com/xsf/xmpp.org/milestone/3 Or drop your news text to our online pad: https://yopad.eu/p/xmpp-newsletter-365days We are always happy for supporters at the end of the month to finalize the draft! 🎛 ============ ✏

this is finally available, update on SRV2 and encrypted client hello (replaces encrypted SNI and ALPN) https://www.ripe.net/participate/ripe/wg/active-wg/dns/remote-sessions/svcb_https_-ripe-2020.pdf

> The page you requested is undergoing maintenance and is temporarily unavailable.

What‽

Can't serve a PDF without Javascript???

works for me in firefox and wget

It worked after enabling JS

I think firefox's built-in pdf viewer needs JS

I doubt that

I mean, it's written in JS, but I don't think that would have caused RIPE to send me an error page

yea that doesn't make sense I agree

worksforme

i guess Zash enabling JS in his browser coincided with ripe fixing their crap

Still screams "the web stubbornly refused to go with SRV records and now NIHed an overcomplicated hack for it" to me

SRV records don't support "use key X for host Y but key B for host A"

But you can publish full keys with DANE

well it's not *only* keys either

Hence "overcomplicated"

it can also say "use http2 with host Y but http1.1 with host X"

moparisthebest: don't they? _foo.bar.baz and _foo.rab.baz are different contents for different hosts

which will actually be very helpful for XMPP too

L29Ah, right, but for 1 domain, not 2

1 domain = 1 host

As a cynic, I have to say that I doubt it will be of any use for anyhing but https.

Since HTTPS gets a special record of its own, I'm counting on that being the only thing supported

L29Ah, no, google.com is not hosted on 1 server/host

I don't think 1 domain = 1 host has been true for any multi-host service that I've ever run or helped work on :)

ahh

and sharing a key is not an option; what about sharing a CA though?

though X.509 stuff is an abomination anyway

the key used to encrypt the client hello isn't shared across hosts, necessarily anyway

oh hey, one of my coworkers is an author on this; I should ask him to give me the rundown

*former coworkers

but roughly, XMPP-wise, we can replace RFC SRV, xep-368 SRV, and xep-0156 TXT, with a much better single-SRV2 lookup

then get encrypted client hello for free, and future QUIC support is easily implemented the same way

the main thing I'm not understanding is everything seems to say SVCB and HTTPS record types are identical, except for the record type code

yes

anyway it might make sense for XMPP to use the HTTPS record specifically for the reasons Zash mentioned above :D

so shose shitty consumer router vendors will do what, you think?

you know, those that don't support SRV records. at all.

right but that'll be fixed quickly when people have a degraded facebook/gmail experience

tho it would be good to do deeper investigation into those ~10% of users behaving as if no SRV exists

There is nothing preventing available presences to come from bare JIDs, right?

(looking at https://dev.gajim.org/gajim/gajim/-/issues/10461)

The RFC does not disallow it (and it makes sense for components), but it explicitly allows unavailable presence

i think we've discussed this recently and the vibe in the room was that this is not ok

i have seen gateways do this though and Conversations has support for this

but i'm really unsure that this is correct behaviour

unavailable from bare means all resources though

Yes

so the fact that this is allowed doesn’t mean available should be allowed

on the contrary this might be an argument to not allow it

XEP-0100 makes use of this though

https://xmpp.org/extensions/xep-0100.html#usecases-jabber-addcontact-pri at step 4

so gateway users have no resource Oo

lovetox, well, lots of networks have no concept of "resource"

yeah and others have

in which case the gateways can reflect that

well the fact that some gateways might decide to omit the resource doesn’t mean all gateways have to

but of course they could also decide to go for a static resource

Of course, if that is relevant to the gateway, I don’t think anything forbids sending gatewayed presence from full-jids

hey, I write a gateway

i really dont like that

this is again something i need to special case

answer: using no resource

I didn't know that was bad

well we don’t know if that's bad :-)

it's certainly unusual

i find this is the job of the bridge, like i dont care some other chat network has no concept of resource

I send presence subscription requests from the barejid too fwiw

and creates weird corner cases like: can you have a resource from bare and one from a full

aehm presence i mean

eta, that does not matter as much, afaik

although I think messages do come from a resource

because subscription requests are expected to be resource-less

but available presences are used to display things in UI, generally

foo@bar.tld type=available, foo@bar.tld/something type=available foo@bar.tld type=unavailable is foo@bar.tld online or offline now?

Daniel, offline, per 6121 :p

though an entity sending both resourced and bare presences would have a weird thing going on