XSF Discussion - 2017-11-09

btw dwd why is being sick prevent someone from attending a board meeting?

a few weeks ago i went, and i was vomiting all night and coming down from a fever from shingles

its not like meetings are physically stressful

I don't think we should be forcing people into things when they are sick

Arc, looking at a computer when you’re very tired or have any kind of physical ailment is not a pleasure

Zash: i didnt say force, let them decide

http://www.sheut.net/Difference_Engine_-_Beige_With_Noodles.ogg

Arc: you didn't see the council meeting earlier about bolding things

Link Mauve: Can't you just chmod a+r the xep84 node, like people want with omemo?

moparisthebest: ?

https://lists.fosdem.org/pipermail/fosdem/2017-October/002627.html FYI, in addition to the usual RTC room, FOSDEM also has a "Decentralized Internet & Privacy" which is also relevant for XMPP

i just submitted a general 'what is xmpp and why do we need it' kind of talk to that devroom

Has anyone else submitted something to either that room or the realtime room?

(not that I'm aware of - It'd be nice if you could add your talk to our wiki page, so that we can keep track)

done

Thanks (I changed the table format a little for additional prettiness)

daniel: I submitted something about the compliance suites

SamWhited, re XEP-0114, I think if it needs changing at all, it could be moved to Advanced Server or Advanced IM Server, but given that it’s the only way to add components, and components can bring great value, I think it should stay in the compliance suites.

*nods* I don't know that it's critical or anything either and could be convinced either way

it’s very useful for sure

I'm not convinced it needs to be in the compliance suites, really.

I'm not going to cry that it is, but I don't see a need.

Kev, Depends what you see a Compliance Suite as being. I see the Basic stuff as being stuff you be surprised wasn't supported, and I think that covers XEP-0114.

I *think* if you use that as a metric, you can never remove anything from a compliance suite.

Because you would expect anyone implementing a new server to do all of Basic, and that makes it surprising that anything in Basic isn't implemented, which means it goes into Basic, and ...

Saying that, M-Link does have customers who use 114 still, so perhaps it really does belong in there.

Kev, I don't, to borrow your phrase, disagree.

Kev, But even Metre does XEP-0114, so I don't really see why it'd be contentious to include.

+1

Yeah, I've changed my mind. It probably does belong in there, although I'd be low-F about it being removed.

It's moderately widely used and useful.

it makes for a nice tool to platform-independently add server-sided functionality. I've never quite got why it didn't take-off more.

Guus, lack of auth and crypto

requires you to have things on the same host basically

jonasw: "take off" as in developed further.

ah

then maybe because that’s still good enough for many people

I think component support is much more important than avatars. But then again...

although you can do direct-tls easily

Guus, with extra proxies?

?

how’d you do direct-tls?

open a server-sided socket that immediately does TLS?

c2s 5223-like?

sure, but that’s not specified, is it?

ah, no, not as far as I know

actually, wasn't there a follow-up xep somehwere?

jonasw, It has TLS, at least on most servers.

dwd, maybe I missed that

jonasw, As for auth, yes. Failing issue, there. XEP-0225 tried to address that, but nobody used that.

jonasw, So XEP-0114's examples all use 0.9 - no version number, so no features. But in practise, if a component sends a version='1.0', then it gets features, usually including TLS.

I admit that I’m not familiar with how components work that way

I assumed that they only do what’s written in XEP-0114 :)

Pretty sure Prosody only does what's in XEP-0114, but fippo had a patch for it

Not really sure how I feel about it

I can't actually recall what Openfire does, despite having a look ages ago.

Is there a difference between 114 + features and 225?

I'm pretty sure that Openfire doesn't do much beyond 114 either.

Zash, Authentication is SASL. And the namespace is jabber:client.

nice though, wouldn’t that allow multiplexing of component and client connections on the same port without magic?

jonasw, Yes, and I'm really not sure that's sensible either.

Abolish jabber:{client,server}! Single unified namespace!

The Real XMPP 2.0! :)

Zash, As with so many things, it's a solved problem now.

Zash, Well, except when I cock it up.

Hm?

Did you mean: "It's such a minor problem that nobody will ever bother fixing it"

Zash, I mean, no matter how big a problem it is when starting out, everyone has solved it now so there's little point in going through the effort of changing it now.

Does xep225 allow multiplexing multiple component domains over the same component connection?

Flow: yes

iirc :)

at least I remember something about it when I was implementing it

Doesn't everyone just ignore the namespace anyways? (I'm actually curious, I can't think why it matters but maybe stone people respect it)?

*some people

Flow: https://xmpp.org/extensions/xep-0225.html#bind

Ignore the namespace? What blasphemy is this?!

SamWhited, Openfire ignores and strips it, whereas Metre (and maybe others?) internally dispatch elements based on the namespace.

it cannot be ignored everywhere

in some places you need to know the namespace

SamWhited, Well, I say "maybe others", but M-Link dispatched based on the qualified name as a whole when I worked on it.

Makes sense; I do dispatch based on payload namespaces but not the stanza level ones, but I guess you could mix server/client handlers and use the stanza level ones too

zinid, hmm, ok, but it doesn't explicitly mention that multiple <bind/>s are allowed

or did I miss that?

Flow: "A component can send a subsequent bind request to bind another hostname (a server MUST support binding of multiple hostnames)."

Flow, Oh, multiple bind was another thing. Not sure where that ended up, but it was a terribly idea I thought.

ahh its in there

good

zinid, Oh, it stayed in there?

dwd: as you see :)

Section 4, example 4

dwd, what's wrong with it?

It's a nice path for many security vulns

Flow, From a security standpoint, it makes lots of things awkward. We were talking about having it on C2S sessions more generally, which is worse.

actually a customer wanted this multiple binding, that's why we implemented xep-0225 in commercial version of ejabberd

Multiple binding for c2s used to be standardized, possibly in the RFCs, I forget

MattJ, I thought we documented it and then abandoned. ProtoXEP perhaps, or possibly I-D?

https://xmpp.org/extensions/xep-0193.html

All the way to Draft.

I was confused by the whack API seemingly letting you bind a transport to multiple hostnames, I'd never heard of that before

that explains it though

uh, bind a component*

hmm got my first xmpp spam that was just a link to pastebin.com

good luck filtering that on keywords