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
Steve Killehas left
jubalhhas joined
Steve Killehas left
jcbrandhas joined
efrithas joined
edhelashas left
edhelashas joined
edhelashas left
edhelashas joined
ralphmhas joined
tim@boese-ban.dehas joined
Ge0rG
goffi: sorry, my statement wasn't in any way related to you
tim@boese-ban.dehas joined
Guushas left
jubalhhas joined
jubalhhas left
Guushas left
vanitasvitaehas joined
lskdjfhas joined
Valerianhas left
Valerianhas joined
Valerianhas left
mimi89999has joined
stefandxmhas joined
Valerianhas joined
tim@boese-ban.dehas joined
tim@boese-ban.dehas joined
stefandxmhas left
ralphmhas joined
Alexhas joined
Holgerhas left
efrithas left
intosihas left
ralphmhas joined
jonasw
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?
jonasw
I thought it was obvious from linking #200, sorry for being unclear and wasting your time at first.
vanitasvitaehas left
goffihas left
andrey.ghas joined
vanitasvitaehas joined
goffi
Ge0rG: no worries :). Just wanted to be sure nobody think I'm doing any kind of holy war ;)
right, so they did some decorative fixes, and removed a few taunts
ralphmhas joined
goffi
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.
pep.
yeah
goffi
if you want to see the whole story, you can check https://mastodon.social/@Goffi/17772081
jubalhhas joined
SouL
thanks
goffi
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 :-/
jonasw
gateway all the things!
goffi
that's handy (and planed), but it's a inelegant workaround, instead of using compatible protocols.
jonasw
yupp
Ge0rG
Just migrate everything to xmpp. Or to jabber. Or, better, both of them at the same time.
goffi
:)
goffi
that's plan also: 1) gateway everything 2) ??? 3) XMPP world domination
pep.
goffi, but it's better to stay incompatible with half-arsed gateways than having to agree on something you know
pep.has left
pep.has left
dwd
pep., That's more or less the story of Internet Mail, though.
efrithas joined
pep.has joined
Valerianhas left
Valerianhas joined
Valerianhas left
vanitasvitaehas left
vanitasvitaehas joined
Martinhas left
jabberatdemohas joined
lumihas joined
jabberatdemohas left
jabberatdemohas joined
Guushas left
tim@boese-ban.dehas joined
jabberatdemohas left
Guushas left
jcbrandhas left
Guushas left
ralphmhas joined
tim@boese-ban.dehas joined
Guushas left
Valerianhas joined
suzyohas joined
jerehas joined
la|r|mahas left
waqashas joined
edhelashas left
edhelashas joined
lskdjfhas joined
ralphmhas joined
Flowhas left
jabberatdemohas joined
jabberatdemohas left
jabberatdemohas joined
tim@boese-ban.dehas joined
jabberatdemohas left
jabberatdemohas joined
testhas joined
testhas left
jabberatdemohas left
stefandxmhas joined
Alexhas left
stefandxmhas left
jcbrandhas joined
ralphmhas joined
tim@boese-ban.dehas joined
Flowhas joined
ralphmhas left
Yagizahas joined
tim@boese-ban.dehas joined
Alexhas joined
ralphmhas joined
Martinhas joined
fp-testerhas left
fp-testerhas joined
tim@boese-ban.dehas joined
ralphmhas joined
Steffen Larsenhas joined
Steffen Larsenhas left
stefandxmhas joined
moparisthebesthas joined
lumihas left
lumihas joined
stefandxmhas left
stefandxmhas joined
edhelas
memberbot@xmpp.org doesnt answer my requests
jonasw
cc @ Alex ^
Alex
edhelas: you must be whitelisted
Ge0rGhas joined
edhelas
I was
Alex
let me know your Jid and I will check
Alex
after the server crash we lost all whitelist
Alex
the list is client side only
Alex
send me an email with your Jid and I will check
goffi
I've had trouble with it too, it was not responding and I've had to insist
Alex
also check that there are no s2s issues to xmpp.org
goffihas left
goffihas joined
edhelas
Alex, working, thanks !
Alex
ok, you were not whitelisted then
Valerianhas left
Valerianhas joined
Valerianhas left
goffi
Alex: oh just seen your message saying you've added my jid, so it was you afterall :)
goffi
(you're quick)
lskdjfhas left
Martinhas left
efrithas left
Ge0rGhas left
efrithas joined
tim@boese-ban.dehas joined
ralphmhas joined
Martinhas joined
goffihas left
Valerianhas joined
ralphmhas left
Valerianhas left
Valerianhas joined
lovetoxhas joined
jerehas left
jjrhhas left
jerehas joined
Valerianhas left
Valerianhas joined
jjrh
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?
Ge0rGhas left
ralphmhas joined
jubalhhas left
sonnyhas left
sonnyhas joined
efrithas left
sonnyhas joined
sonnyhas joined
sonnyhas left
sonnyhas joined
jjrh
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.
jjrh
Being fairly new to xmpp/xsf I'm amazed at the number of places xmpp pops up - it's really cool.
jjrh
You got sip handsets supporting xmpp!
jjrhhas left
stefandxmhas left
stefandxmhas joined
jjrhhas left
jjrhhas left
jjrhhas left
stefandxmhas left
stefandxmhas joined
efrithas joined
Ge0rGhas left
jabberatdemohas joined
jonasw
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?
jonasw
not to blame anyone, I just find it curious
Holger
jonasw: Whatever that would have to do with anything :-) I implemented the current 0377 for ejabberd, I just think an artificial dependency is stupid.
Holger
And quite a few non-ejabberd people agreed on the list, no?
jonasw
Holger, implicitly, I was wondering whether erlang maybe more strongly enforces separation between components, not knowing much about erlang
SamWhited
It's not an artificial dependency; it's expanding the blocking command feature to support providing a reason for the block.
jonasw
SamWhited, I find the XEP named misleadingly then
Holger
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".
jonasw
and the whole section about the payload can be omitted in favour of "how to use with blocking"
SamWhited
jonasw: Yes, I agreed to that on list⦠it may be better to change it or merge it into the blocking command XEP.
Holger
SamWhited: Sigh.
suzyohas left
Holger
SamWhited: It would be a dependency if I couldn't report spam without also blocking someone.
jubalhhas joined
Holger
Those things are distinct actions and I can of course do either without doing the other.
Holger
So letting one depend on the other is artificial.
SamWhited
If you report something is spam, why would you *not* want to block that JID as well?
SamWhited
*as
stefandxm
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)
stefandxm
iam thinking about the schemas
jonasw
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
Wiktorhas joined
jonasw
stefandxm, I think if your extension lives in a different namespace, it is safe to do that
stefandxm
but it must still be allowed in the top schema
SamWhited
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
jonasw
(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)
stefandxm
by using any or so?
jonasw
stefandxm, the schemas are not normative in anycase
jonasw
SamWhited, storage for the blocklist
stefandxm
jonasw, isnt that up to the xep?
Holger
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.
SamWhited
jonasw: If you have that little storage you have other problems, that doesn't even seem worth considering
jonasw
SamWhited, sure.
SamWhited
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
jonasw
waste of resources is not my primary argument. I generally concur with what Holger writes on list
jubalhhas left
jonasw
SamWhited, you are right about that, but I donāt think this is one of those cases
SamWhited
I do. If we separate them to support everything else under the sun then everything immediately becomes more complicated:
Holger
SamWhited: I'm totally against those monster XEPs. But I'm arguing for an extremely simple XEP that does one thing well.
SamWhited
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.
stefandxm
I would want it to exist :)
jonasw
SamWhited, why the heck would the blocking IQ not go to the server?
Holger
SamWhited: To the local server of course.
stefandxm
i would want to subscribe to a reporting service that i may chose myself
Holger
SamWhited: The XEP should state that, just as the blocking XEP does.
jonasw
only the local server can block stanzas for you O_o
stefandxm
and then i would use the data from that reporting service to make private blocking decisions
stefandxm
just as with spam lists in mail
Holger
Now Stefan comes along and everthing falls apart, as usual!
stefandxm
:D
jonasw
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
SamWhited
stefandxm: That works with the current system :)
SamWhited
(and would continue to work with the system Holger and jonasw are talking about)
Holger
stefandxm: Are you following the standards@ list?
jonasw
SamWhited, how does that work with the current system, unless youāre sending something semantically different from a simple spam report to report spam?
Holger
stefandxm: Evgeniy (zinid) was complaining about the same Schema issues you mentioned.
stefandxm
holger: not anymore :) and i didnt comment on the broad topic just to the generic sense =)
SamWhited
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"
stefandxm
holger: I understand he did. mixing schemas like that without having the parent schema explicitly saying its allowe breaks the schemas completely
SamWhited
Or you need to know the payload
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.
stefandxm
thats not how xml works
Holger
It's how XMPP works :-)
jonasw
stefandxm, I think itās how XMPP ⦠exactly
stefandxm
where is that written?
SamWhited
I thought 6120 specifically said you had to tolerate unknown namespaces, but I can't find it with a quick search
Holger
It does, for clients.
SamWhited
But regardless, it's how XMPP works in practice these days even if the original RFC doesn't specifically say it
jonasw
Holger, only with a stretch
Holger
(Was mentioned in the thread.)
jonasw
Holger, I did mention it, and I find my own argument rather weak
Holger
jonasw: Yeah well we're doing the same thing elsewhere and Evgeniy keeps being frustrated about this.
jonasw
Holger, I also think that it is kind of a design smell when we do this
jonasw
it is here, and it is in MIX with the roster query
Wiktorhas left
jonasw
in both cases, client side, Iāll have to mix components which have nothing to do with each other
jabberatdemohas left
SamWhited
I don't understand why you'd have to "mix" anything. Just build this into whatever your blocking command module is.
Holger
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".
jonasw
SamWhited, sure, but semantically spam reporting has not much to do with blocking, in my opinion
Holger
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
Martinhas left
Ge0rGhas left
jonasw
Holger, yes, I think this claim (in context) only applies to the schemas in RFC 6120
Zash
Leaving the decision about whether to report as spam and/or block to implementators instead of the XEP ...
jonasw
> 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.
stefandxm
i dont get it :)
stefandxm
i mean, i dont get why a client that knows about a namespace (and its schema) should let through garbage
SamWhited
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.
Holger
jonasw: And I also doubt the idea was that an XEP would consciously invalidate an 6120 schema.
stefandxm
samwhited: so because clients are sucky and doesnt support schemas properly good clients should ditch the schema because of because?
jonasw
Holger, itās not an 6120 schema though (but I agree that a XEP SHOULD NOT conciously violate another XEPs schema, too)
Holger
Yes no that's not what I meant ... whatever :-)
stefandxm
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
SamWhited
stefandxm: Yes
jonasw
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
SamWhited
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"
SamWhited
But what jonasw said; if you know a schema, feel free to enforce it on payloads you send. That's very nice of you.
stefandxm
tbh i will enforce it on receiving aswell
SamWhited
That's a terrible idea
jonasw
stefandxm, from my experience, you wonāt like that
Martinhas joined
stefandxm
no, it makes stuff crash and burn faster
jonasw
yes, but itāll look as if it was your fault
SamWhited
Possibly the most basic principle of any network protocol design is to be liberal in what you receive and strict in what you send
Also, it's common practice to include custom elements (provided that they're properly namespaced), this has nothing to do with this particular spec.
Holger
I.e. I'm not sure that's still the consensus.
SamWhited
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.
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.
stefandxm
i dont see anything that would break xmpp because i chose to to use the schemas supplied
Holger
Zash: Heh that one was the one I was meaning to reference :-) Mis-searched.
stefandxm
only broken xeps will break
stefandxm
and the broken xeps should probably be given attention to by xsf
Guus
stefandxm: and any implementation that's not yours.
SamWhited
Zash: Yah, I do agree with that, but still, not something that makes sense for XMPP unless we want to start over
stefandxm
guus, better have error than confusion
SamWhited
But yes, my earlier statement should perhapse be softened to be more tightly scoped to existing protocols that have expected that for years
stefandxm
if i find elements i cannot parse because it does not exist in the schema it will just generate more sneaky errors
Guus
stefandxm: I'd agree with you if this would have been enforced from '99. But it hasn't. There's no saving it now.
stefandxm
i'd rather have the explicit error yelled at asap
stefandxm
guus, there is. we use xmpp for modern new stuff. xmpp is much bigger than IM
jonasw
stefandxm, simple and practical example: RFC 6120 schemas do not define the "code" attribute on stanza errors. however, RFC 3921 does.
jubalhhas joined
jonasw
stefandxm, some implementations still emit that code attribute
jubalhhas left
jonasw
if youāre strict about the schema from RFC 6120, youād not be able to interoperate with implementations still emitting that
stefandxm
and thats fine by me
jonasw
(which is explicitly allowed by the text of RFC 6120)
jonasw
well not allowed, but mentioned
jonasw
so you wonāt be able to talk to ejabberd IIRC
Holger
wat
jonasw
(holger may be able to correct me, but LTIC ejabberd emitted that)
jonasw
(but it may have been a legacy installation of ejabberd; it also required legacy sessions)
stefandxm
ive not seen "code" :o
Holger
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.
jonasw
Holger, nice!
SamWhited
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)
Zash
Holger: Validate how strictly?
Holger
jonasw: It's probably liberal in accepting also 3920, I'll check your example.
SamWhited
Holger: Oh? I'd love to know more about that
stefandxm
samwhited; i am not commenting on the topic itself. i just dont want broken schemas :)
Guus
that's unexpectedly pleasant news.
stefandxm
samwhited; as long as the schema is not broken / conforms iam happy :)
jonasw
Holger, when I had aioxmpp be strict about inbound stuff (raise errors on unknown attributes and child elements), it broke rather quickly
jonasw
stefandxm, schemas as written in XEPs rarely reflect the reality
stefandxm
i know, schemas are not perfect :)
stefandxm
but if anythign they should be leniant then not give false errors
jonasw
stefandxm, sometimes theyāre outright in conflict with the text
jonasw
and then youāre getting told that theyāre not normative
stefandxm
i know, and thats funky. i'd call them broken and they should be attended to
jonasw
Holger, could you (as ejabberd) maybe write up an XSF blogpost on this?
SamWhited
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
jonasw
Iād be interested to learn about the scope of the validation you do and the results you see
jonasw
stefandxm, patches welcome or so?
jonasw
reminds me I wanted to write a tool which uses the schemas in XEPs to validate the code examples.
stefandxm
i dont have time, i focus on the schemas for the protocls i am making ;)
stefandxm
but i think xsf should encourage to update/fix the schemas rather than saying its best practice to break schemas
jonasw
stefandxm, I tend to agree
SamWhited
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
SamWhited
(though if the author does know what they're doing, sure, why not, it's nice when they're right)
Holger
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
SamWhited
No one's saying it's best practice to break the schemas.
stefandxm
i agree with removing/making broken schemas more leniant
Holger
So yes this is not enforcing strict 6120 or anything.
Holger
Just trying to reject unknown crap.
stefandxm
false negatives is stupid. but a false positive will always happen because no xml schema protocol can provide enough business logic rules
jonasw
Holger, thatās fine
Zash
Holger: Like <message type="I made this up"> and whatever?
jonasw
Holger, still, care to write a blogpost with some insights and results and what exactly youāre doing?
Holger
Zash: Yes.
Holger
Zash: That's the most common case sites with custom stuff seem to stumble over, of course :-)
SamWhited
> 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)
Holger
jonasw: I'm not sure ...
SamWhited
Not that it matters at all or that you'd want to do that, I'm just curious
Holger
jonasw: I'm not a good blog article writer. Takes me ages.
Holger
And Evgeniy did all this work.
SamWhited
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
SamWhited
There's a weird interconnect between 6120 which doesn't define types and 6121 which defines a few types there
jonasw
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>)
ralphmhas joined
Zash
jonasw: wha
jonasw
SamWhited, thereās clear wording on that
stefandxm
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
Zash
What about IQ and presence?
stefandxm
(in a unique individual namespace that is)
Holger
jonasw: Ah yes we're probably not doing that actually. Just <message custom_attr="foo"/> is rejected.
Holger
*That's* what people stumble over anyway.
jonasw
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>)
SamWhited
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
stefandxm
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
stefandxm
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.
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>)
jonasw
Holger, I fail to be able to understand what this does :)
Holger
jonasw: If type is unkown, then type is normal.
jonasw
I see
jonasw
so youāre actually doing that. neat. aioxmpp throws an error at you.
jonasw
*sigh*
Guushas left
jonasw
(I find defaulting to "normal" on unknown values a bad style btw.)
stefandxm
speaking of shoulds.. does ejabberd route iq messages between entities not sharing presence?
Holger
jonasw: ACK.
vanitasvitaehas left
jonasw
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).
jonasw
maybe what is meant is that if an application does not implement one of the foregoing, it should be treated like "normal"?
Holger
stefandxm: Er I don't think it looks at think at presence subscription when routing IQs. Or does/should it?
Zash
jonasw: My head!
Holger
(Not sure I'll ever manage to write two correct sentences in a row.)
we have to make our entitled data sessions force the entities to set up presence
stefandxm
during a valid session
Holger
stefandxm: Ah right. And doesn't it behave that way? :-)
Holgergoes reading code.
stefandxm
holger, i think not. at least not last time i checked :)
stefandxm
jonasw, its not easily spotted but quite sever if you design a protocol and dont know about it
stefandxm
"someone" should compile a cheat sheet for xmpp >D
jonasw
stefandxm, I think this invalidates quite a few security consideratinos I have thought about recently.
Zash
stefandxm: thanks for volonteering ;)
stefandxm
iam swamped :p
jonasw
who isnāt
stefandxm
but i am basically writing such stuff anyhow
jonasw
I like it when discussions in xsf@ result in bugreports against myself.
stefandxm
for our proffesional campaign. i'll see if i can collect enough of items to make it usefull
stefandxm
jonasw, hehe. thats why i try not to read too much here ;)
jonasw
I prefer to know about issues instead of having buggy software out there.
Ge0rGhas left
stefandxm
yeah, but ignorance is bliss if your backlog is too big ;)
efrithas left
jcbrandhas left
waqashas left
sonnyhas left
sonnyhas joined
Guushas left
Lancehas joined
ralphmhas joined
Valerianhas left
Guushas left
Lancehas left
danielhas left
moparisthebesthas joined
danielhas joined
moparisthebesthas joined
jerehas left
jerehas joined
waqashas joined
tim@boese-ban.dehas joined
goffihas left
tim@boese-ban.dehas left
Flow
> ā[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
danielhas left
Wiktorhas joined
danielhas joined
jerehas left
jerehas joined
Guushas left
Guushas left
Holgerhas left
Steve Killehas left
Ge0rG
But isn't the protocol designed for that, except maybe adding new element values like message type?
tim@boese-ban.dehas joined
jonasw
Ge0rG, yes and no
jonasw
we rarely do that in practice, and when we do, I often feel it is a mistake (see MIX and the Spam Reporting thing)
jonasw
and it violates our (non-normative) schemas
MattJ
Schemas are per namespace, no?
jonasw
yes
jonasw
but schemas normally need to include an <xs:any/> if they can contain children from foreign namespaces if Iām not mistaken
Martinhas left
Steve Killehas left
Steve Killehas joined
sonnyhas left
sonnyhas joined
Flowhas joined
andrey.ghas left
Guushas left
stefandxmhas left
Valerianhas joined
Tobiashas joined
Steve Killehas left
Steve Killehas left
Steve Killehas left
vanitasvitaehas left
la|r|mahas joined
Vaulorhas joined
Lancehas joined
Yagizahas joined
Zashhas left
jjrhhas left
Lancehas left
jjrhhas left
Steve Killehas left
stefandxmhas joined
ralphmhas joined
Steve Killehas left
Steve Killehas left
tim@boese-ban.dehas joined
valohas joined
stefandxmhas left
waqashas left
Valerianhas left
goffihas joined
fp-testerhas left
fp-testerhas joined
Guushas left
Flowhas joined
Zashhas left
Flowhas joined
Flowhas joined
Tobiashas joined
Guushas left
Valerianhas joined
emxphas left
emxphas joined
Wiktorhas left
Wiktorhas joined
sonnyhas joined
Guushas left
Flow
since everyone seems to repeat that schemas are not normative again and again, why not make it offical?
Zash
+1, everyone already believes it
andrey.ghas joined
SamWhited
It is official, isn't it?
Flow
SamWhited: then there would be place where it's mentioned
Flow
uh, i have a deja vu
SamWhited
Oh, is it not? I assumed it was in one of the XEP XEPs somewhere. Guess not.
Flow
logs.xmpp.org does work again? what else have I missed while I was on vacation?
jjrhhas left
jjrhhas left
ralphmhas joined
Guus
Edwin fixed the logs
stefandxmhas joined
Zash
Praise be Edwin
sonnyhas joined
Steve Kille
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.
SamWhited
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.
SamWhited
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
stefandxm
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
stefandxm
Ironically i am making a xep (maybe, dunno if xsf will like it) that is self-extending with xml schemas >D
stefandxm
but i see no other way to be dynamic with types
jjrhhas left
stefandxm
schemas makes the most sense if you make the server verify it
Steve Kille
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.
Steve Kille
Current XEPs is harder. The draconian way would be to move to historical anything with a broken schema
valohas joined
stefandxm
replace any broken ones with <any> ;-)
Zash
Is this like the static vs dynamic typing war?
stefandxm
there has never been a static vs dynamic typing war
stefandxm
just programmers using static typing and n00bs using dynamic typing =)
SouL
stefandxm, brofist
SouLsmiles :)
Flow
Plus, what has priorityif the normative text and the normative schema contradict each other?
SamWhited
Flow: Is that any different from when the normative text and the normative text contradict each other?
Flow
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
Flow
SamWhited: Good question, I think it's different assuming that usually the text is correct and not the schema in my experience
Flow
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
SamWhited
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
jjrhhas left
SamWhited
Yah, me too; I'm not ever going to read the schema, I will read the text.
ralphmhas joined
Steve Kille
So, why have the schema??
Flow
well schemas come in handy in case the text is not clear, that's the common case where I look at it
SamWhited
Steve Kille: exactly
Flow
Steve Kille: Because it's an excellent addition to the text
jjrhhas left
Valerianhas left
Flow
and makes it easy to model and implement stanzas and nonzas in the programming language of your choice
SamWhited
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
Flow
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
SamWhited
"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.
ralphmhas left
ralphmhas joined
tuxhas joined
magixhas joined
tux
Hey there!
SouL
Sooo... Is now the moment when new applications for XSF members are voted?
magixhas left
Alex
hey guys, everybody ready for our member meeting?
Alex
lets get started
Alexbangs the gavel
stefandxm
schemas are great and they have to be correct
stefandxm
btu cannot exist if broken
Alex
here is our agenda for today:
https://wiki.xmpp.org/web/Meeting-Minutes-2017-09-12
Alex
1) Call for Quorum
Alex
as you can see 38 members voted via memberbot. So we have a quorum
Alex
2) Items Subject to a Vote
Alex
we were voting on new and returning applicants. You can see all applicants here:
https://wiki.xmpp.org/web/Membership_Applications_Q3_2017
Alex
3) Opportunity for XSF Members to Vote in the Meeting
Alex
anyone here who has not voted yet via memberbot?
nycohas left
uchas joined
stefandxm
and by broken i mean they give false negatives
stefandxm
false positives is imo not a problem
SamWhited
stefandxm: the meeting has started, let's hold the discussion we were having until Alex closes it.
Alex
I think everbody voted already via memberbot. So let me work on the results
jonasw
thanks for your work, Alex :-)
jonasw
Iām mostly AFK this time though
nycohas joined
Alex
4) Announcement of Voting Results
Alex
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
Alex
all new and retruning members were accepted, congrats to everyone
Alex
5) Any Other Business?
Alex
looks like there is none
Alex
6) Formal Adjournment
Alex
I motion that we adjourn
SamWhited
Seconded
tux
+1
Alexbangs the gavel
SamWhited
Thanks Alex; much appreciated.
Alex
thanks everyone
tux
thanks for making me a member. :)
Alex
board and council election are coming up
Alex
will create the application page ASAP
SouL
Suuuper happy to part of the XSF! Thank you all, really!
Lancehas joined
Lancehas left
SouL
Congratulations tux :D
tux
SouL: to you, too!
vanitasvitaehas left
Zash
Thanks Alex
SouL
Thanks tux, with the excitement I forgot to write "to be part" in my previous message :D
ralphmhas joined
SouL
Thank you Alex of course :)
ralphmhas joined
lovetoxhas left
Tobiashas joined
ralphmhas left
ralphmhas joined
Guus
Welcome, newbies. š
jonasw
congrats, SouL et al
Ge0rG
today, the number of XSF members I know in person increased, without me meeting any new people. Congratulations :)
tux
*g*
edhelas
SouL, welcome to the party, we have XEPs, beers and pizzas
ralphmhas joined
jabberatdemohas joined
Ge0rG
And a free dinner!
tuxhas left
tuxhas joined
jcbrandhas joined
tuxhas left
Tobiashas joined
Ge0rGhas joined
tuxhas joined
tuxhas left
tim@boese-ban.dehas joined
goffihas left
tuxhas joined
jabberatdemohas left
Vaulorhas left
jerehas left
jerehas joined
jcbrandhas left
Flowhas left
jubalhhas joined
SamWhitedhas left
efrithas joined
blablahas joined
fp-testerhas left
fp-testerhas joined
jcbrandhas joined
mathieui
Damn, missed the members meeting. Thanks for the work, Alex
Guushas left
emxp
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.
SamWhited
emxp: wrong link, I think
emxp
ups
emxp
yes
emxp
--> https://chaoss.community/
tim@boese-ban.dehas joined
Lancehas joined
SamWhitedhas left
Lancehas left
tuxhas left
Ge0rGhas joined
jubalhhas joined
moparisthebest
emxp: confusing l thought it was open source software for healthcare