goffiGe0rG: 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
Ge0rGgoffi: 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
jonaswif 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?
jonaswI 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
goffiGe0rG: no worries :). Just wanted to be sure nobody think I'm doing any kind of holy war ;)
jonaswgithub could use a todo feature like gitlab has
pep.right, so they did some decorative fixes, and removed a few taunts
ralphmhas joined
goffipep.: 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
goffiif you want to see the whole story, you can check https://mastodon.social/@Goffi/17772081
jubalhhas joined
SouLthanks
goffiit 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 :-/
jonaswgateway all the things!
goffithat's handy (and planed), but it's a inelegant workaround, instead of using compatible protocols.
jonaswyupp
Ge0rGJust migrate everything to xmpp. Or to jabber. Or, better, both of them at the same time.
goffi:)
goffithat'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
dwdpep., 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
edhelasmemberbot@xmpp.org doesnt answer my requests
jonaswcc @ Alex ^
Alexedhelas: you must be whitelisted
Ge0rGhas joined
edhelasI was
Alexlet me know your Jid and I will check
Alexafter the server crash we lost all whitelist
Alexthe list is client side only
Alexsend me an email with your Jid and I will check
goffiI've had trouble with it too, it was not responding and I've had to insist
Alexalso check that there are no s2s issues to xmpp.org
goffihas left
goffihas joined
edhelasAlex, working, thanks !
Alexok, you were not whitelisted then
Valerianhas left
Valerianhas joined
Valerianhas left
goffiAlex: 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
jjrhGe0rG 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
jjrhMy $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.
jjrhBeing fairly new to xmpp/xsf I'm amazed at the number of places xmpp pops up - it's really cool.
jjrhYou 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
jonaswI 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?
jonaswnot to blame anyone, I just find it curious
Holgerjonasw: Whatever that would have to do with anything :-) I implemented the current 0377 for ejabberd, I just think an artificial dependency is stupid.
HolgerAnd quite a few non-ejabberd people agreed on the list, no?
jonaswHolger, implicitly, I was wondering whether erlang maybe more strongly enforces separation between components, not knowing much about erlang
SamWhitedIt's not an artificial dependency; it's expanding the blocking command feature to support providing a reason for the block.
jonaswSamWhited, I find the XEP named misleadingly then
HolgerAnd 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".
jonaswand the whole section about the payload can be omitted in favour of "how to use with blocking"
SamWhitedjonasw: Yes, I agreed to that on list… it may be better to change it or merge it into the blocking command XEP.
HolgerSamWhited: Sigh.
suzyohas left
HolgerSamWhited: It would be a dependency if I couldn't report spam without also blocking someone.
jubalhhas joined
HolgerThose things are distinct actions and I can of course do either without doing the other.
HolgerSo letting one depend on the other is artificial.
SamWhitedIf you report something is spam, why would you *not* want to block that JID as well?
SamWhited*as
stefandxmthis 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)
stefandxmiam thinking about the schemas
jonaswfirst, 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
jonaswstefandxm, I think if your extension lives in a different namespace, it is safe to do that
stefandxmbut it must still be allowed in the top schema
SamWhitedWhat 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)
stefandxmby using any or so?
jonaswstefandxm, the schemas are not normative in anycase
jonaswSamWhited, storage for the blocklist
stefandxmjonasw, isnt that up to the xep?
HolgerSamWhited: 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.
SamWhitedjonasw: If you have that little storage you have other problems, that doesn't even seem worth considering
jonaswSamWhited, sure.
SamWhitedHolger: 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
jonaswwaste of resources is not my primary argument. I generally concur with what Holger writes on list
jubalhhas left
jonaswSamWhited, you are right about that, but I don’t think this is one of those cases
SamWhitedI do. If we separate them to support everything else under the sun then everything immediately becomes more complicated:
HolgerSamWhited: I'm totally against those monster XEPs. But I'm arguing for an extremely simple XEP that does one thing well.
SamWhitedNow 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.
stefandxmI would want it to exist :)
jonaswSamWhited, why the heck would the blocking IQ not go to the server?
HolgerSamWhited: To the local server of course.
stefandxmi would want to subscribe to a reporting service that i may chose myself
HolgerSamWhited: The XEP should state that, just as the blocking XEP does.
jonaswonly the local server can block stanzas for you O_o
stefandxmand then i would use the data from that reporting service to make private blocking decisions
stefandxmjust as with spam lists in mail
HolgerNow Stefan comes along and everthing falls apart, as usual!
stefandxm:D
jonaswwhere 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
SamWhitedstefandxm: That works with the current system :)
SamWhited(and would continue to work with the system Holger and jonasw are talking about)
Holgerstefandxm: Are you following the standards@ list?
jonaswSamWhited, how does that work with the current system, unless you’re sending something semantically different from a simple spam report to report spam?
Holgerstefandxm: Evgeniy (zinid) was complaining about the same Schema issues you mentioned.
stefandxmholger: not anymore :) and i didnt comment on the broad topic just to the generic sense =)
SamWhitedjonasw: 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"
stefandxmholger: I understand he did. mixing schemas like that without having the parent schema explicitly saying its allowe breaks the schemas completely
SamWhitedOr you need to know the payload
Holgerstefandxm: But I think the general consensus is that you can throw new stuff into existing XML because you're expected to ignore unknown stuff.
stefandxmthats not how xml works
HolgerIt's how XMPP works :-)
jonaswstefandxm, I think it’s how XMPP … exactly
stefandxmwhere is that written?
SamWhitedI thought 6120 specifically said you had to tolerate unknown namespaces, but I can't find it with a quick search
HolgerIt does, for clients.
SamWhitedBut regardless, it's how XMPP works in practice these days even if the original RFC doesn't specifically say it
jonaswHolger, only with a stretch
Holger(Was mentioned in the thread.)
jonaswHolger, I did mention it, and I find my own argument rather weak
Holgerjonasw: Yeah well we're doing the same thing elsewhere and Evgeniy keeps being frustrated about this.
jonaswHolger, I also think that it is kind of a design smell when we do this
jonaswit is here, and it is in MIX with the roster query
Wiktorhas left
jonaswin both cases, client side, I’ll have to mix components which have nothing to do with each other
jabberatdemohas left
SamWhitedI don't understand why you'd have to "mix" anything. Just build this into whatever your blocking command module is.
HolgerI 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".
jonaswSamWhited, sure, but semantically spam reporting has not much to do with blocking, in my opinion
Holgerstefandxm:
> 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
jonaswHolger, yes, I think this claim (in context) only applies to the schemas in RFC 6120
ZashLeaving 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.
stefandxmi dont get it :)
stefandxmi mean, i dont get why a client that knows about a namespace (and its schema) should let through garbage
SamWhitedBecause 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.
Holgerjonasw: And I also doubt the idea was that an XEP would consciously invalidate an 6120 schema.
stefandxmsamwhited: so because clients are sucky and doesnt support schemas properly good clients should ditch the schema because of because?
jonaswHolger, it’s not an 6120 schema though (but I agree that a XEP SHOULD NOT conciously violate another XEPs schema, too)
HolgerYes no that's not what I meant ... whatever :-)
stefandxmif 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
SamWhitedstefandxm: Yes
jonaswfor sending it makes sense, and I agree, but for receiving, being strict in most of the cases causes more pain than it does good
SamWhitedExcept 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"
SamWhitedBut what jonasw said; if you know a schema, feel free to enforce it on payloads you send. That's very nice of you.
stefandxmtbh i will enforce it on receiving aswell
SamWhitedThat's a terrible idea
jonaswstefandxm, from my experience, you won’t like that
Martinhas joined
stefandxmno, it makes stuff crash and burn faster
jonaswyes, but it’ll look as if it was your fault
SamWhitedPossibly the most basic principle of any network protocol design is to be liberal in what you receive and strict in what you send
SamWhitedAlso, it's common practice to include custom elements (provided that they're properly namespaced), this has nothing to do with this particular spec.
HolgerI.e. I'm not sure that's still the consensus.
SamWhitedHolger: 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.
Guuswell, 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.
stefandxmi dont see anything that would break xmpp because i chose to to use the schemas supplied
HolgerZash: Heh that one was the one I was meaning to reference :-) Mis-searched.
stefandxmonly broken xeps will break
stefandxmand the broken xeps should probably be given attention to by xsf
Guusstefandxm: and any implementation that's not yours.
SamWhitedZash: Yah, I do agree with that, but still, not something that makes sense for XMPP unless we want to start over
stefandxmguus, better have error than confusion
SamWhitedBut yes, my earlier statement should perhapse be softened to be more tightly scoped to existing protocols that have expected that for years
stefandxmif i find elements i cannot parse because it does not exist in the schema it will just generate more sneaky errors
Guusstefandxm: I'd agree with you if this would have been enforced from '99. But it hasn't. There's no saving it now.
stefandxmi'd rather have the explicit error yelled at asap
stefandxmguus, there is. we use xmpp for modern new stuff. xmpp is much bigger than IM
jonaswstefandxm, simple and practical example: RFC 6120 schemas do not define the "code" attribute on stanza errors. however, RFC 3921 does.
jubalhhas joined
jonaswstefandxm, some implementations still emit that code attribute
jubalhhas left
jonaswif you’re strict about the schema from RFC 6120, you’d not be able to interoperate with implementations still emitting that
stefandxmand thats fine by me
jonasw(which is explicitly allowed by the text of RFC 6120)
jonaswwell not allowed, but mentioned
jonaswso you won’t be able to talk to ejabberd IIRC
Holgerwat
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)
stefandxmive not seen "code" :o
HolgerRecent 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.
jonaswHolger, nice!
SamWhitedEither 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)
ZashHolger: Validate how strictly?
Holgerjonasw: It's probably liberal in accepting also 3920, I'll check your example.
SamWhitedHolger: Oh? I'd love to know more about that
stefandxmsamwhited; i am not commenting on the topic itself. i just dont want broken schemas :)
Guusthat's unexpectedly pleasant news.
stefandxmsamwhited; as long as the schema is not broken / conforms iam happy :)
jonaswHolger, when I had aioxmpp be strict about inbound stuff (raise errors on unknown attributes and child elements), it broke rather quickly
jonaswstefandxm, schemas as written in XEPs rarely reflect the reality
stefandxmi know, schemas are not perfect :)
stefandxmbut if anythign they should be leniant then not give false errors
jonaswstefandxm, sometimes they’re outright in conflict with the text
jonaswand then you’re getting told that they’re not normative
stefandxmi know, and thats funky. i'd call them broken and they should be attended to
jonaswHolger, could you (as ejabberd) maybe write up an XSF blogpost on this?
SamWhitedyah, that's a whole different issue, but most of us don't understand schemas and there's no one to attend to them, sadly
jonaswI’d be interested to learn about the scope of the validation you do and the results you see
jonaswstefandxm, patches welcome or so?
jonaswreminds me I wanted to write a tool which uses the schemas in XEPs to validate the code examples.
stefandxmi dont have time, i focus on the schemas for the protocls i am making ;)
stefandxmbut i think xsf should encourage to update/fix the schemas rather than saying its best practice to break schemas
jonaswstefandxm, I tend to agree
SamWhitedJust 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)
Holgerjonasw: 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
SamWhitedNo one's saying it's best practice to break the schemas.
stefandxmi agree with removing/making broken schemas more leniant
HolgerSo yes this is not enforcing strict 6120 or anything.
HolgerJust trying to reject unknown crap.
stefandxmfalse negatives is stupid. but a false positive will always happen because no xml schema protocol can provide enough business logic rules
jonaswHolger, that’s fine
ZashHolger: Like <message type="I made this up"> and whatever?
jonaswHolger, still, care to write a blogpost with some insights and results and what exactly you’re doing?
HolgerZash: Yes.
HolgerZash: 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)
Holgerjonasw: I'm not sure ...
SamWhitedNot that it matters at all or that you'd want to do that, I'm just curious
Holgerjonasw: I'm not a good blog article writer. Takes me ages.
HolgerAnd Evgeniy did all this work.
SamWhitedZash: 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
SamWhitedThere's a weird interconnect between 6120 which doesn't define types and 6121 which defines a few types there
jonaswHolger, 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
Zashjonasw: wha
jonaswSamWhited, there’s clear wording on that
stefandxmsamwhited; 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
ZashWhat about IQ and presence?
stefandxm(in a unique individual namespace that is)
Holgerjonasw: Ah yes we're probably not doing that actually. Just <message custom_attr="foo"/> is rejected.
Holger*That's* what people stumble over anyway.
jonaswZash, 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>)
SamWhitedstefandxm: 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
stefandxmsamwhited; 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
stefandxmsamwhited, 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.
jonaswZash, 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>)
jonaswHolger, I fail to be able to understand what this does :)
Holgerjonasw: If type is unkown, then type is normal.
jonaswI see
jonaswso 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.)
stefandxmspeaking of shoulds.. does ejabberd route iq messages between entities not sharing presence?
Holgerjonasw: ACK.
vanitasvitaehas left
jonaswHolger, 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).
jonaswmaybe what is meant is that if an application does not implement one of the foregoing, it should be treated like "normal"?
Holgerstefandxm: Er I don't think it looks at think at presence subscription when routing IQs. Or does/should it?
Zashjonasw: My head!
Holger(Not sure I'll ever manage to write two correct sentences in a row.)
jonaswHolger, you need Last Message Correction :-)
jonaswwhat.
jonaswstefandxm, didn’t know that existed.
stefandxmwe have made some funky way to get around that
stefandxmwe have to make our entitled data sessions force the entities to set up presence
stefandxmduring a valid session
Holgerstefandxm: Ah right. And doesn't it behave that way? :-)
Holgergoes reading code.
stefandxmholger, i think not. at least not last time i checked :)
stefandxmjonasw, 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
jonaswstefandxm, I think this invalidates quite a few security consideratinos I have thought about recently.
Zashstefandxm: thanks for volonteering ;)
stefandxmiam swamped :p
jonaswwho isn’t
stefandxmbut i am basically writing such stuff anyhow
jonaswI like it when discussions in xsf@ result in bugreports against myself.
stefandxmfor our proffesional campaign. i'll see if i can collect enough of items to make it usefull
stefandxmjonasw, hehe. thats why i try not to read too much here ;)
jonaswI prefer to know about issues instead of having buggy software out there.
Ge0rGhas left
stefandxmyeah, 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
Ge0rGBut isn't the protocol designed for that, except maybe adding new element values like message type?
tim@boese-ban.dehas joined
jonaswGe0rG, yes and no
jonaswwe rarely do that in practice, and when we do, I often feel it is a mistake (see MIX and the Spam Reporting thing)
jonaswand it violates our (non-normative) schemas
MattJSchemas are per namespace, no?
jonaswyes
jonaswbut 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
Flowsince 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
SamWhitedIt is official, isn't it?
FlowSamWhited: then there would be place where it's mentioned
Flowuh, i have a deja vu
SamWhitedOh, is it not? I assumed it was in one of the XEP XEPs somewhere. Guess not.
Flowlogs.xmpp.org does work again? what else have I missed while I was on vacation?
jjrhhas left
jjrhhas left
ralphmhas joined
GuusEdwin fixed the logs
stefandxmhas joined
ZashPraise be Edwin
sonnyhas joined
Steve KilleNon-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.
SamWhitedI 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.
SamWhitedEspecially given that we know a lot of them are actually broken right now. That's not going to get better by making them normative
stefandxmanother 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
stefandxmIronically i am making a xep (maybe, dunno if xsf will like it) that is self-extending with xml schemas >D
stefandxmbut i see no other way to be dynamic with types
jjrhhas left
stefandxmschemas makes the most sense if you make the server verify it
Steve KilleNew 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 KilleCurrent XEPs is harder. The draconian way would be to move to historical anything with a broken schema
valohas joined
stefandxmreplace any broken ones with <any> ;-)
ZashIs this like the static vs dynamic typing war?
stefandxmthere has never been a static vs dynamic typing war
stefandxmjust programmers using static typing and n00bs using dynamic typing =)
SouLstefandxm, brofist
SouLsmiles :)
FlowPlus, what has priorityif the normative text and the normative schema contradict each other?
SamWhitedFlow: Is that any different from when the normative text and the normative text contradict each other?
FlowI 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
FlowSamWhited: Good question, I think it's different assuming that usually the text is correct and not the schema in my experience
FlowAnd 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
SamWhitedI 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
SamWhitedYah, me too; I'm not ever going to read the schema, I will read the text.
ralphmhas joined
Steve KilleSo, why have the schema??
Flowwell schemas come in handy in case the text is not clear, that's the common case where I look at it
SamWhitedSteve Kille: exactly
FlowSteve Kille: Because it's an excellent addition to the text
jjrhhas left
Valerianhas left
Flowand makes it easy to model and implement stanzas and nonzas in the programming language of your choice
SamWhitedIt'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
FlowSamWhited: 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
tuxHey there!
SouLSooo... Is now the moment when new applications for XSF members are voted?
magixhas left
Alexhey guys, everybody ready for our member meeting?
Alexlets get started
Alexbangs the gavel
stefandxmschemas are great and they have to be correct
stefandxmbtu cannot exist if broken
Alexhere is our agenda for today:
https://wiki.xmpp.org/web/Meeting-Minutes-2017-09-12
Alex1) Call for Quorum
Alexas you can see 38 members voted via memberbot. So we have a quorum
Alex2) Items Subject to a Vote
Alexwe were voting on new and returning applicants. You can see all applicants here:
https://wiki.xmpp.org/web/Membership_Applications_Q3_2017
Alex3) Opportunity for XSF Members to Vote in the Meeting
Alexanyone here who has not voted yet via memberbot?
nycohas left
uchas joined
stefandxmand by broken i mean they give false negatives
stefandxmfalse positives is imo not a problem
SamWhitedstefandxm: the meeting has started, let's hold the discussion we were having until Alex closes it.
AlexI think everbody voted already via memberbot. So let me work on the results
jonaswthanks for your work, Alex :-)
jonaswI’m mostly AFK this time though
nycohas joined
Alex4) Announcement of Voting Results
Alexwhen you reload teh page you can see teh results at:
https://wiki.xmpp.org/web/Meeting-Minutes-2017-09-12#Announcement_of_Voting_Results
Alexall new and retruning members were accepted, congrats to everyone
Alex5) Any Other Business?
Alexlooks like there is none
Alex6) Formal Adjournment
AlexI motion that we adjourn
SamWhitedSeconded
tux+1
Alexbangs the gavel
SamWhitedThanks Alex; much appreciated.
Alexthanks everyone
tuxthanks for making me a member. :)
Alexboard and council election are coming up
Alexwill create the application page ASAP
SouLSuuuper happy to part of the XSF! Thank you all, really!
Lancehas joined
Lancehas left
SouLCongratulations tux :D
tuxSouL: to you, too!
vanitasvitaehas left
ZashThanks Alex
SouLThanks tux, with the excitement I forgot to write "to be part" in my previous message :D
ralphmhas joined
SouLThank you Alex of course :)
ralphmhas joined
lovetoxhas left
Tobiashas joined
ralphmhas left
ralphmhas joined
GuusWelcome, newbies. 😉
jonaswcongrats, SouL et al
Ge0rGtoday, the number of XSF members I know in person increased, without me meeting any new people. Congratulations :)
tux*g*
edhelasSouL, welcome to the party, we have XEPs, beers and pizzas
ralphmhas joined
jabberatdemohas joined
Ge0rGAnd 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
mathieuiDamn, missed the members meeting. Thanks for the work, Alex
Guushas left
emxpHello, 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.
SamWhitedemxp: wrong link, I think
emxpups
emxpyes
emxp--> https://chaoss.community/
tim@boese-ban.dehas joined
Lancehas joined
SamWhitedhas left
Lancehas left
tuxhas left
Ge0rGhas joined
jubalhhas joined
moparisthebestemxp: confusing l thought it was open source software for healthcare
XSF Discussion - 2017-09-12