XSF Discussion - 2017-09-22

that's what my mom told me yes

That CFE that was issued for XEP-0368 got me thinking about multiplexing services, using the ALPN TLS extension.

I'm new to this, so if I'm asking silly questions, feel free to point that out

That's all silly

(please wait until I've actually started questions)

can we multiplex Direct TLS and STARTTLS somehow?

In theory

as the latter doesn't start out as a TLS connection, I'm assuming ALPN isn't usable there?

More like redundant, like SNI

sni is redundant?

I don't get that last statement

I'm somewhat anti all those things. As I see it, all it does is move stuff into the TLS library.

second question: if we'd add BOSH to the multiplexing-mix, would that need a new ALPN protocol ID, or use one of the HTTP-ones? The latter would prevent multiplexing with another (non-XMPP) webservice, right?

XMPP, HTTP, TLS are all fairly easily identifiable from the first few bytes, so they can be multiplexed

third question for Zash: if not use SNI / ALPN, what's the alternative for multiplexing protocols (and hosts) on one port?

with existing tooling?

Prosody does it just fine, except TLS and STARTTLS can't be on the same port.

Duno if there are other tools

TCPMUX on Port 1!

https://en.wikipedia.org/wiki/TCP_Port_Service_Multiplexer

Guus: There's sslh, for example: http://www.rutschle.net/tech/sslh.shtml

Holger: Yeah, now we get TLSMUX on port 443 instead. All this has happened before etc.

History is repeating itself.

you cannot offload TLS efficiently with starttls

Because?

because how?

Has anyone used http://tsung.erlang-projects.org/1/01/about/?

Zash: will you write your own balancer understanding starttls?

Is it really that hard?

Zash: writing haproxy or nginx?

zinid: I did that once, FWIW.

I think yes, it's hard

nobody interested in your handmade toys

SouL: I used tsung a lot of course

Hrrr

Doesn't nginx have starttls for its email things?

And didn't that Fastmail guy add XMPP support to nginx?

so you will use SMTP STARTTLS for XMPP STARTTLS?

if "add support" means writing shitty patch, then yes, he did

I don't think I want to hear this argument agaidn

what do you want to here?

nginx out of the box doesn't support xmpp starttls

also, some guys prefer haproxy

they will not change it only because of xmpp starttls

second question: if we'd add BOSH to the multiplexing-mix, would that need a new ALPN protocol ID, or use one of the HTTP-ones? The latter would prevent multiplexing with another (non-XMPP) webservice, right?

I'd say bosh is http

Guus, I thnik you’d multiplex based on the requested resource then

layer 7 routing etc.

that makes sense

Did ALPN allow the client to set multiple types?

I like how you talk in the past tense :)

(and: I don't know)

Looks like it does. > "ProtocolNameList" contains the list of protocols advertised by the > client, in descending order of preference.

So, registering bosh wouldn't be too crazy.

is there any "larger" collective of error-messages than the one in xmpp core?

i am thinking now we get a lot of extended error codes that could probably be more generic if they were not in core.

so then maybe it already exists :)

Ge0rG: I was thinking more about tying message attaching to XEP-0359 IDs. I'm not sure that it gets us all that much anymore, because you have to support attaching by origin ID and by IDs set by the server, which feels just as weird as attaching based on the id attribute which may or may not exist.

Yeah, non-mandatory non-unique IDs are what brought us into the trouble

I'm not actually a fan of having two different entities that can set IDs either.

Two entities, three kinds of IDs. What could go wrong?

Oh, all of them are optional.

hm, right, you couldn’t attach something on a message without ID :/

you can’t use the MAM ID anyways, thinking of it, because other clients don’t know it

maybe it would be useful to enforce origin-id == message-id.

interesting idea

bring that up on standards@

There seems to be no discussion of that XEP on standards at all.

oh, nevermind. my filter-fu is bad

Why even have origin-id at that point? Clients could just set message-id

because message-ids are not guaranteed to be unique, random or even present

I don't follow. If you're going to say in the spec "set both of these to the same thing and make it unique and random" why not just say "set the message-id and make sure it's unique and random"

?

SamWhited: because as a receiving entity, you don't know the rules that the sender used to generate the ID

Sure you do, they say they support stanza-id in their disco

Right, that's why it exists

Actually, no, I lied

and yes, it's optional, but I think it's fine for a XEP to fail gracefully on that

You're getting stuff from a MAM archive, and the client that sent it originally is online… you don't have the disco info for context.

is offline, even.

You don't need disco, just the element existing or not

MattJ: only if there is an origin-id in the message.

MattJ: I was suggesting the element didn't need to exist (if you're going to set it in both places, just use the id attr), but I was confused, that doesn't provide enough context.

Oh right, yeah, you can't rely on that

So yah, I agree, if you're going to support stanza-id forcing the origin-id and the id attr to be the same sounds sensible to me.

Also some servers think it's ok to modify that whenever they want anyway :)

Yeah.

But then the value of message-id doesn't matter anyway.

And other servers (transports) tend to remove XML payload from MUC messages.

It matters for things that don't support stanza-id

So we are fu... doomed anyway.

This doesn't "fix" anything, it just makes things slightly more consistent at the cost of a tiny bit of weird useless duplication

has anyone running a public server ever tried to run yahoos open_nsfw image classifier on the avatar data?

(you can probably guess what this classifier does)

Hey that's funny. I've read the "Opportunistic TLS" proposal, then thought the term isn't correct, then thought that would be bike shedding. And now that exact discussion has happened anyway.

Guus: yes I use sslh to multiplex everything