XSF Discussion - 2017-09-12

Ge0rG: Guus: just for the record, I've not "fought" other groups, I've just have complained about the FAQ and only with Matrix. Beside that I have nothing against Matrix as a technology or any other FOSS project

goffi: sorry, my statement wasn't in any way related to you

if someone from board is around, can you please tell me whether https://github.com/xsf/xmpp.org/pull/358#issuecomment-328796484 makes it sufficiently clear why I think that board needs to be involved?

I thought it was obvious from linking #200, sorry for being unclear and wasting your time at first.

Ge0rG: no worries :). Just wanted to be sure nobody think I'm doing any kind of holy war ;)

:D

goffi, I'd be interested in a diff :)

pep., https://github.com/matrix-org/matrix-doc/commit/414ef70592a335356122052dd5952af5adbfde8e

heh, nice

You were fast, jonasw

awesomebar is being awesome

github could use a todo feature like gitlab has

right, so they did some decorative fixes, and removed a few taunts

pep.: yes it still full of wrong statements, but it's a bit better, and the sentence I was most annoyed of ("The whole subject of XMPP vs Matrix seems to bring out the worst in people.") has been removed.

yeah

if you want to see the whole story, you can check https://mastodon.social/@Goffi/17772081

thanks

it seems that mastodon has some kind of protocol split issue with GNU Social, and it's moving away from ostatus. We start to have a bunch of mostly incompatibles FOSS "social" protocols :-/

gateway all the things!

that's handy (and planed), but it's a inelegant workaround, instead of using compatible protocols.

yupp

Just migrate everything to xmpp. Or to jabber. Or, better, both of them at the same time.

:)

that's plan also: 1) gateway everything 2) ??? 3) XMPP world domination

goffi, but it's better to stay incompatible with half-arsed gateways than having to agree on something you know

pep., That's more or less the story of Internet Mail, though.

memberbot@xmpp.org doesnt answer my requests

cc @ Alex ^

edhelas: you must be whitelisted

I was

let me know your Jid and I will check

after the server crash we lost all whitelist

the list is client side only

send me an email with your Jid and I will check

I've had trouble with it too, it was not responding and I've had to insist

also check that there are no s2s issues to xmpp.org

Alex, working, thanks !

ok, you were not whitelisted then

Alex: oh just seen your message saying you've added my jid, so it was you afterall :)

(you're quick)

Ge0rG cool they allow you to connect. There isn't a good reason why they wouldn't but for whatever reason companies like to lock their stuff down. Has riot formally engaged with the xsf?

My $0.02 is that I don't think matrix is any threat to xmpp. They are the new hot shiny thing and that's fine and cool - competing open standards is a good thing and in the end there is no reason xmpp can't interoperate. People looking for a protocol that is ready today, field tested and a reasonable assurance it will be supported now and in the future will choose xmpp.

Being fairly new to xmpp/xsf I'm amazed at the number of places xmpp pops up - it's really cool.

You got sip handsets supporting xmpp!

I find it interesting that the ejabberd people are the ones arguing the loudest against the dependency between XEP-0191 and XEP-0377, or am I just misperceiving that?

not to blame anyone, I just find it curious

jonasw: Whatever that would have to do with anything :-) I implemented the current 0377 for ejabberd, I just think an artificial dependency is stupid.

And quite a few non-ejabberd people agreed on the list, no?

Holger, implicitly, I was wondering whether erlang maybe more strongly enforces separation between components, not knowing much about erlang

It's not an artificial dependency; it's expanding the blocking command feature to support providing a reason for the block.

SamWhited, I find the XEP named misleadingly then

And it's not like the world falls apart if we do it this way, so I should've shut up earlier. I'm just a little baffled how this dependency is justified with reasoning such as "why not?" or "might save a round-trip" or "might enforce my UI on others".

and the whole section about the payload can be omitted in favour of "how to use with blocking"

jonasw: Yes, I agreed to that on list… it may be better to change it or merge it into the blocking command XEP.

SamWhited: Sigh.

SamWhited: It would be a dependency if I couldn't report spam without also blocking someone.

Those things are distinct actions and I can of course do either without doing the other.

So letting one depend on the other is artificial.

If you report something is spam, why would you *not* want to block that JID as well?

*as

this is interesting. is it common / considered "ok" to have one xep extend the content of another xep without the first xep explicitly saying so? (i have a similair challenge)

iam thinking about the schemas

first, it appears to be ineffective and thus a waste of resources. second, if it *isn’t* ineffective, I could be an operator of a service which also uses machine learning to learn spam messages. I would want to know if I receive further spam from the same JID or if I see it being caught by the spam filters

stefandxm, I think if your extension lives in a different namespace, it is safe to do that

but it must still be allowed in the top schema

What resource is being wasted? I do agree it's probably ineeffective since they're probably using tons of throwaway JIDs, but I don't see it as hurting anything or wasting resources either

(of course, you need to ensure that entities are on the same page on what is supported and understood, but an entity which doesn’t understand the new namespaced element should simply discard)

by using any or so?

stefandxm, the schemas are not normative in anycase

SamWhited, storage for the blocklist

jonasw, isnt that up to the xep?

SamWhited: Maybe the server doesn't support blocking, maybe we'll decide to replace blocking with yet another XEP, maybe the server still does 0016, maybe we come to the conclusion that blocking isn't useful due to changing JIDs, I don't know. My point is that it doesn't matter whether your assumption holds. Independent XEPs will work either way.

jonasw: If you have that little storage you have other problems, that doesn't even seem worth considering

SamWhited, sure.

Holger: I think that's where we disagree, in any of those cases you should be using something else. Us trying to make general purpose XEPs that are one-size-fits-all is why XMPP is almost entirely broken all the time

waste of resources is not my primary argument. I generally concur with what Holger writes on list

SamWhited, you are right about that, but I don’t think this is one of those cases

I do. If we separate them to support everything else under the sun then everything immediately becomes more complicated:

SamWhited: I'm totally against those monster XEPs. But I'm arguing for an extremely simple XEP that does one thing well.

Now you have to decide where to send the blocking IQ; does it go to the server? Another client? A spam reporting service? These aren't options I want to exist.

I would want it to exist :)

SamWhited, why the heck would the blocking IQ not go to the server?

SamWhited: To the local server of course.

i would want to subscribe to a reporting service that i may chose myself

SamWhited: The XEP should state that, just as the blocking XEP does.

only the local server can block stanzas for you O_o

and then i would use the data from that reporting service to make private blocking decisions

just as with spam lists in mail

Now Stefan comes along and everthing falls apart, as usual!

:D

where the spam reporting goes, that should be the local server by default as Holger says, even if only because the only the local server has enough context to make use of that report

stefandxm: That works with the current system :)

(and would continue to work with the system Holger and jonasw are talking about)

stefandxm: Are you following the standards@ list?

SamWhited, how does that work with the current system, unless you’re sending something semantically different from a simple spam report to report spam?

stefandxm: Evgeniy (zinid) was complaining about the same Schema issues you mentioned.

holger: not anymore :) and i didnt comment on the broad topic just to the generic sense =)

jonasw: Right, sorry, what I should have said was "either way we would need to include the payload, but then it can be forwarded wherever you want"

holger: I understand he did. mixing schemas like that without having the parent schema explicitly saying its allowe breaks the schemas completely

Or you need to know the payload

stefandxm: But I think the general consensus is that you can throw new stuff into existing XML because you're expected to ignore unknown stuff.

thats not how xml works

It's how XMPP works :-)

stefandxm, I think it’s how XMPP … exactly

where is that written?

I thought 6120 specifically said you had to tolerate unknown namespaces, but I can't find it with a quick search

It does, for clients.

But regardless, it's how XMPP works in practice these days even if the original RFC doesn't specifically say it

Holger, only with a stretch

(Was mentioned in the thread.)

Holger, I did mention it, and I find my own argument rather weak

jonasw: Yeah well we're doing the same thing elsewhere and Evgeniy keeps being frustrated about this.

Holger, I also think that it is kind of a design smell when we do this

it is here, and it is in MIX with the roster query

in both cases, client side, I’ll have to mix components which have nothing to do with each other

I don't understand why you'd have to "mix" anything. Just build this into whatever your blocking command module is.

I agree that this is the general consensus and that 6120 allows this. I'm not so sure whether the idea behing 6120 really was that XEPs should consciously do this, rather than just "be liberal in what you expect".

SamWhited, sure, but semantically spam reporting has not much to do with blocking, in my opinion

stefandxm: > Clients are advised not to rely on the ability to send data that does not conform to the schemas, and SHOULD ignore any non-conformant elements or attributes https://tools.ietf.org/html/rfc6120#section-11.4

Holger, yes, I think this claim (in context) only applies to the schemas in RFC 6120

Leaving the decision about whether to report as spam and/or block to implementators instead of the XEP ...

> An implementation MAY choose to accept or send only data that has been explicitly validated against the schemas provided in this document, but such behavior is OPTIONAL.

i dont get it :)

i mean, i dont get why a client that knows about a namespace (and its schema) should let through garbage

Because we have a lot of different clients and servers and enough interoperability problems without denying every element that has some clients proprietary extension in it.

jonasw: And I also doubt the idea was that an XEP would consciously invalidate an 6120 schema.

samwhited: so because clients are sucky and doesnt support schemas properly good clients should ditch the schema because of because?

Holger, it’s not an 6120 schema though (but I agree that a XEP SHOULD NOT conciously violate another XEPs schema, too)

Yes no that's not what I meant ... whatever :-)

if i know of a namespace and i have a schema i would of course enforce it. and that is because of the interoperability not because of lack of it

stefandxm: Yes

for sending it makes sense, and I agree, but for receiving, being strict in most of the cases causes more pain than it does good

Except scratch the "sucky" and just say "some clients and services might be doing their own thing and it's common practice to allow them to do so"

But what jonasw said; if you know a schema, feel free to enforce it on payloads you send. That's very nice of you.

tbh i will enforce it on receiving aswell

That's a terrible idea

stefandxm, from my experience, you won’t like that

no, it makes stuff crash and burn faster

yes, but it’ll look as if it was your fault

Possibly the most basic principle of any network protocol design is to be liberal in what you receive and strict in what you send

https://www.computer.org/csdl/mags/sp/2012/02/msp2012020087.html

Also, it's common practice to include custom elements (provided that they're properly namespaced), this has nothing to do with this particular spec.

I.e. I'm not sure that's still the consensus.

Holger: That's fair, if I were designing a new protocol I'd probably make it more strict and less extensible than XMPP, but I'm not and it's already common practice in XMPP.

https://tools.ietf.org/html/draft-thomson-postel-was-wrong-01

well, for XML-based systems, it's not uncommon to enforce schema validitry (think of SOAP et al). We've long lost that battle in XMPP though.

i dont see anything that would break xmpp because i chose to to use the schemas supplied

Zash: Heh that one was the one I was meaning to reference :-) Mis-searched.

only broken xeps will break

and the broken xeps should probably be given attention to by xsf

stefandxm: and any implementation that's not yours.

Zash: Yah, I do agree with that, but still, not something that makes sense for XMPP unless we want to start over

guus, better have error than confusion

But yes, my earlier statement should perhapse be softened to be more tightly scoped to existing protocols that have expected that for years

if i find elements i cannot parse because it does not exist in the schema it will just generate more sneaky errors

stefandxm: I'd agree with you if this would have been enforced from '99. But it hasn't. There's no saving it now.

i'd rather have the explicit error yelled at asap

guus, there is. we use xmpp for modern new stuff. xmpp is much bigger than IM

stefandxm, simple and practical example: RFC 6120 schemas do not define the "code" attribute on stanza errors. however, RFC 3921 does.

stefandxm, some implementations still emit that code attribute

if you’re strict about the schema from RFC 6120, you’d not be able to interoperate with implementations still emitting that

and thats fine by me

(which is explicitly allowed by the text of RFC 6120)

well not allowed, but mentioned

so you won’t be able to talk to ejabberd IIRC

wat

(holger may be able to correct me, but LTIC ejabberd emitted that)

(but it may have been a legacy installation of ejabberd; it also required legacy sessions)

ive not seen "code" :o

Recent ejabberd versions are currently trying to validate incoming XML and it's working better as expected, BTW. So I'm not sure the "everything is lost since we didn't enforce things for over a decode" story holds.

Holger, nice!

Either way, moving it into the blocking command XEP would solve this issue for you right stefandxm? (because then it would be a part of the blocking command schema)

Holger: Validate how strictly?

jonasw: It's probably liberal in accepting also 3920, I'll check your example.

Holger: Oh? I'd love to know more about that

samwhited; i am not commenting on the topic itself. i just dont want broken schemas :)

that's unexpectedly pleasant news.

samwhited; as long as the schema is not broken / conforms iam happy :)

Holger, when I had aioxmpp be strict about inbound stuff (raise errors on unknown attributes and child elements), it broke rather quickly

stefandxm, schemas as written in XEPs rarely reflect the reality

i know, schemas are not perfect :)

but if anythign they should be leniant then not give false errors

stefandxm, sometimes they’re outright in conflict with the text

and then you’re getting told that they’re not normative

i know, and thats funky. i'd call them broken and they should be attended to

Holger, could you (as ejabberd) maybe write up an XSF blogpost on this?

yah, that's a whole different issue, but most of us don't understand schemas and there's no one to attend to them, sadly

I’d be interested to learn about the scope of the validation you do and the results you see

stefandxm, patches welcome or so?

reminds me I wanted to write a tool which uses the schemas in XEPs to validate the code examples.

i dont have time, i focus on the schemas for the protocls i am making ;)

but i think xsf should encourage to update/fix the schemas rather than saying its best practice to break schemas

stefandxm, I tend to agree

Just to stir the fire a bit more: this is why I think we should remove schemas from existing XEPs and make them optional. In theory they're great, in practice only a few authors actually know what they're doing enough to add them

(though if the author does know what they're doing, sure, why not, it's nice when they're right)

jonasw: Here's the definition of 'error', which includes the 'code' attribute: https://github.com/processone/xmpp/blob/1.1.14/specs/xmpp_codec.spec#L655

No one's saying it's best practice to break the schemas.

i agree with removing/making broken schemas more leniant

So yes this is not enforcing strict 6120 or anything.

Just trying to reject unknown crap.

false negatives is stupid. but a false positive will always happen because no xml schema protocol can provide enough business logic rules

Holger, that’s fine

Holger: Like <message type="I made this up"> and whatever?

Holger, still, care to write a blogpost with some insights and results and what exactly you’re doing?

Zash: Yes.

Zash: That's the most common case sites with custom stuff seem to stumble over, of course :-)

> no xml schema protocol can provide enough business logic rules Is this true? I thought I saw an implementation of a lisp-like language purely in XMLSchema at one point (proving that it was turing complete, and therefore can probably provide as much business logic as you could with anything else you'd be using)

jonasw: I'm not sure ...

Not that it matters at all or that you'd want to do that, I'm just curious

jonasw: I'm not a good blog article writer. Takes me ages.

And Evgeniy did all this work.

Zash: the message type thing is actually an interesting problem I ran into recently; I can't tell if the RFC is specifically allowing or disallowing custom types

There's a weird interconnect between 6120 which doesn't define types and 6121 which defines a few types there

Holger, if you reject unknown message types, you may be violating RFC 6121: > If an application receives a message with no 'type' attribute or the application does not understand the value of the 'type' attribute provided, it MUST consider the message to be of type "normal" (i.e., "normal" is the default). (<https://tools.ietf.org/html/rfc6121#section-5.2.2>)

jonasw: wha

SamWhited, there’s clear wording on that

samwhited; i have many examples of my oppinion "nice" xml that cannot be made robust in xml schemas (or ng relax). for instance when you use inheritance. the only way to make it robust is to put every element in a namespace ;-) other than that there are business logic that only the receiver may now/being able to verify. for instance global uniquness

What about IQ and presence?

(in a unique individual namespace that is)

jonasw: Ah yes we're probably not doing that actually. Just <message custom_attr="foo"/> is rejected.

*That's* what people stumble over anyway.

Zash, IQ is in RFC 6120: > 2. The 'type' attribute is REQUIRED for IQ stanzas. The value MUST be one of the following; if not, the recipient or an intermediate router MUST return a <bad-request/> stanza error (Section 8.3.3.1). (<https://tools.ietf.org/html/rfc6120#section-8.2.3>)

stefandxm: Ah, okay, interesting; I don't know enough xmlschema to even start doing something that complicated, but I guess it's just not possible after a point. Thanks

samwhited; ng relax doesnt even support inheritance. but xml schemas does it in what i would call reverse order which is very irritating if you are used to oop

samwhited, but for the business logic it cannot be done because the schema only has memory of what data it has in the xml stream not in what happens outside.

jonasw: https://github.com/processone/xmpp/blob/1.1.14/specs/xmpp_codec.spec#L4173 :-)

Zash, for presence, again RFC 6121: > If the value of the 'type' attribute is not one of the foregoing values, the recipient or an intermediate router SHOULD return a stanza error of <bad-request/>. (<https://tools.ietf.org/html/rfc6121#section-4.7.1>)

Holger, I fail to be able to understand what this does :)

jonasw: If type is unkown, then type is normal.

I see

so you’re actually doing that. neat. aioxmpp throws an error at you.

*sigh*

(I find defaulting to "normal" on unknown values a bad style btw.)

speaking of shoulds.. does ejabberd route iq messages between entities not sharing presence?

jonasw: ACK.

Holger, Zash, wait; maybe my reading of RFC6121 is off, the full paragraph is this: > An IM application SHOULD support all of the foregoing message types. > If an application receives a message with no 'type' attribute or the > application does not understand the value of the 'type' attribute > provided, it MUST consider the message to be of type "normal" (i.e., > "normal" is the default).

maybe what is meant is that if an application does not implement one of the foregoing, it should be treated like "normal"?

stefandxm: Er I don't think it looks at think at presence subscription when routing IQs. Or does/should it?

jonasw: My head!

(Not sure I'll ever manage to write two correct sentences in a row.)

Zash, I’m sorry!

holger; https://tools.ietf.org/html/rfc6121#section-8.5.3.1

Holger, you need Last Message Correction :-)

what.

stefandxm, didn’t know that existed.

we have made some funky way to get around that

we have to make our entitled data sessions force the entities to set up presence

during a valid session

stefandxm: Ah right. And doesn't it behave that way? :-)

holger, i think not. at least not last time i checked :)

jonasw, its not easily spotted but quite sever if you design a protocol and dont know about it

"someone" should compile a cheat sheet for xmpp >D

stefandxm, I think this invalidates quite a few security consideratinos I have thought about recently.

stefandxm: thanks for volonteering ;)

iam swamped :p

who isn’t

but i am basically writing such stuff anyhow

I like it when discussions in xsf@ result in bugreports against myself.

for our proffesional campaign. i'll see if i can collect enough of items to make it usefull

jonasw, hehe. thats why i try not to read too much here ;)

I prefer to know about issues instead of having buggy software out there.

yeah, but ignorance is bliss if your backlog is too big ;)

> ‎[16:55:46] ‎Holger‎: stefandxm: But I think the general consensus is that you can throw new stuff into existing XML because you're expected to ignore unknown stuff. You can throw in new stuff if the protocol still works if the recipient ignores it, otherwhise it has to be negotiated prior

But isn't the protocol designed for that, except maybe adding new element values like message type?

Ge0rG, yes and no

we rarely do that in practice, and when we do, I often feel it is a mistake (see MIX and the Spam Reporting thing)

and it violates our (non-normative) schemas

Schemas are per namespace, no?

yes

but schemas normally need to include an <xs:any/> if they can contain children from foreign namespaces if I’m not mistaken

since everyone seems to repeat that schemas are not normative again and again, why not make it offical?

+1, everyone already believes it

It is official, isn't it?

SamWhited: then there would be place where it's mentioned

uh, i have a deja vu

Oh, is it not? I assumed it was in one of the XEP XEPs somewhere. Guess not.

logs.xmpp.org does work again? what else have I missed while I was on vacation?

Edwin fixed the logs

Praise be Edwin

Non-normative schema seems odd to me. I was advised to defer doing the MIX schema, as it was non-normative. Having the schema normative seems to offer significant advantage. Not least, the schema can be validated by a range of available tools, whereas examples and descriptive text cannot.

I think that sounds nice in theory, but unless you (or someone who understands schemas) is willing to write one for every new XEP it doesn't seem realistic to me.

Especially given that we know a lot of them are actually broken right now. That's not going to get better by making them normative

another problem is that unless you make your xml to be compliant with a schema then it may be very difficult to make a good one

Ironically i am making a xep (maybe, dunno if xsf will like it) that is self-extending with xml schemas >D

but i see no other way to be dynamic with types

schemas makes the most sense if you make the server verify it

New XEPs (and progression beyond experimental is easy. You only allow progress if the schema is good. I suspect that this would be a lot of work for me/MIX, but it feels right to do it.

Current XEPs is harder. The draconian way would be to move to historical anything with a broken schema

replace any broken ones with <any> ;-)

Is this like the static vs dynamic typing war?

there has never been a static vs dynamic typing war

just programmers using static typing and n00bs using dynamic typing =)

stefandxm, brofist

Plus, what has priorityif the normative text and the normative schema contradict each other?

Flow: Is that any different from when the normative text and the normative text contradict each other?

I think the normative text eventually has to have priority of a hyptothetical normative schema, which just means we can just say that the schema is not normative

SamWhited: Good question, I think it's different assuming that usually the text is correct and not the schema in my experience

And I rather have a well written normative text instead of a well formed normative schema, because the former is easier to parse for me as human

I feel like the text is just as likely to contradict other text, and that's just a mistake that needs to be fixed (same as if the schema contradicts the text). That being said, I don't disagree with you that the text needs to be normative and the schema doesn't, just with the reasoning

Yah, me too; I'm not ever going to read the schema, I will read the text.

So, why have the schema??

well schemas come in handy in case the text is not clear, that's the common case where I look at it

Steve Kille: exactly

Steve Kille: Because it's an excellent addition to the text

and makes it easy to model and implement stanzas and nonzas in the programming language of your choice

It's an excellent addition when it's correct. Any schema I write is probably not going to be correct though, so I don't see why I should be required to put one in there

SamWhited: There is only one required for the XEP to enter draft, which is a good tradeof and how I would want it to be

"an excellent addition in theory" anyways. I'm not against people who know what they're doing adding a schema section, I just don't think it should be a requirement in general.

Hey there!

Sooo... Is now the moment when new applications for XSF members are voted?

hey guys, everybody ready for our member meeting?

lets get started

schemas are great and they have to be correct

btu cannot exist if broken

here is our agenda for today: https://wiki.xmpp.org/web/Meeting-Minutes-2017-09-12

1) Call for Quorum

as you can see 38 members voted via memberbot. So we have a quorum

2) Items Subject to a Vote

we were voting on new and returning applicants. You can see all applicants here: https://wiki.xmpp.org/web/Membership_Applications_Q3_2017

3) Opportunity for XSF Members to Vote in the Meeting

anyone here who has not voted yet via memberbot?

and by broken i mean they give false negatives

false positives is imo not a problem

stefandxm: the meeting has started, let's hold the discussion we were having until Alex closes it.

I think everbody voted already via memberbot. So let me work on the results

thanks for your work, Alex :-)

I’m mostly AFK this time though

4) Announcement of Voting Results

when you reload teh page you can see teh results at: https://wiki.xmpp.org/web/Meeting-Minutes-2017-09-12#Announcement_of_Voting_Results

all new and retruning members were accepted, congrats to everyone

5) Any Other Business?

looks like there is none

6) Formal Adjournment

I motion that we adjourn

Seconded

+1

Thanks Alex; much appreciated.

thanks everyone

thanks for making me a member. :)

board and council election are coming up

will create the application page ASAP

Suuuper happy to part of the XSF! Thank you all, really!

Congratulations tux :D

SouL: to you, too!

Thanks Alex

Thanks tux, with the excitement I forgot to write "to be part" in my previous message :D

Thank you Alex of course :)

Welcome, newbies. 😉

congrats, SouL et al

today, the number of XSF members I know in person increased, without me meeting any new people. Congratulations :)

*g*

SouL, welcome to the party, we have XEPs, beers and pizzas

And a free dinner!

Damn, missed the members meeting. Thanks for the work, Alex

Hello, have you heard about this project? https://wiki.xmpp.org/web/Meeting-Minutes-2017-09-12 - As it's harder to get an overview and facts about dezentralised networks (than centralised) this might be helpful in the future to argue (for XMPP) based on statistics. Furthermore, we might get more detailed information about developments which havent been in our view so far.

emxp: wrong link, I think

ups

yes

--> https://chaoss.community/

emxp: confusing l thought it was open source software for healthcare