XSF Discussion - 2017-09-12

  1. goffi

    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

  2. Ge0rG

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

  3. 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?

  4. jonasw

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

  5. goffi

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

  6. SouL


  7. pep.

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

  8. jonasw

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

  9. pep.

    heh, nice

  10. SouL

    You were fast, jonasw

  11. jonasw

    awesomebar is being awesome

  12. jonasw

    github could use a todo feature like gitlab has

  13. pep.

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

  14. 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.

  15. pep.


  16. goffi

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

  17. SouL


  18. 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 :-/

  19. jonasw

    gateway all the things!

  20. goffi

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

  21. jonasw


  22. Ge0rG

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

  23. goffi


  24. goffi

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

  25. pep.

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

  26. dwd

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

  27. edhelas

    memberbot@xmpp.org doesnt answer my requests

  28. jonasw

    cc @ Alex ^

  29. Alex

    edhelas: you must be whitelisted

  30. edhelas

    I was

  31. Alex

    let me know your Jid and I will check

  32. Alex

    after the server crash we lost all whitelist

  33. Alex

    the list is client side only

  34. Alex

    send me an email with your Jid and I will check

  35. goffi

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

  36. Alex

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

  37. edhelas

    Alex, working, thanks !

  38. Alex

    ok, you were not whitelisted then

  39. goffi

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

  40. goffi

    (you're quick)

  41. 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?

  42. 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.

  43. jjrh

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

  44. jjrh

    You got sip handsets supporting xmpp!

  45. 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?

  46. jonasw

    not to blame anyone, I just find it curious

  47. 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.

  48. Holger

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

  49. jonasw

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

  50. SamWhited

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

  51. jonasw

    SamWhited, I find the XEP named misleadingly then

  52. 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".

  53. jonasw

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

  54. SamWhited

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

  55. Holger

    SamWhited: Sigh.

  56. Holger

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

  57. Holger

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

  58. Holger

    So letting one depend on the other is artificial.

  59. SamWhited

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

  60. SamWhited


  61. 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)

  62. stefandxm

    iam thinking about the schemas

  63. 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

  64. jonasw

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

  65. stefandxm

    but it must still be allowed in the top schema

  66. 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

  67. 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)

  68. stefandxm

    by using any or so?

  69. jonasw

    stefandxm, the schemas are not normative in anycase

  70. jonasw

    SamWhited, storage for the blocklist

  71. stefandxm

    jonasw, isnt that up to the xep?

  72. 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.

  73. SamWhited

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

  74. jonasw

    SamWhited, sure.

  75. 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

  76. jonasw

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

  77. jonasw

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

  78. SamWhited

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

  79. Holger

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

  80. 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.

  81. stefandxm

    I would want it to exist :)

  82. jonasw

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

  83. Holger

    SamWhited: To the local server of course.

  84. stefandxm

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

  85. Holger

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

  86. jonasw

    only the local server can block stanzas for you O_o

  87. stefandxm

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

  88. stefandxm

    just as with spam lists in mail

  89. Holger

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

  90. stefandxm


  91. 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

  92. SamWhited

    stefandxm: That works with the current system :)

  93. SamWhited

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

  94. Holger

    stefandxm: Are you following the standards@ list?

  95. 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?

  96. Holger

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

  97. stefandxm

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

  98. 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"

  99. stefandxm

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

  100. SamWhited

    Or you need to know the payload

  101. 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.

  102. stefandxm

    thats not how xml works

  103. Holger

    It's how XMPP works :-)

  104. jonasw

    stefandxm, I think it’s how XMPP … exactly

  105. stefandxm

    where is that written?

  106. SamWhited

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

  107. Holger

    It does, for clients.

  108. SamWhited

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

  109. jonasw

    Holger, only with a stretch

  110. Holger

    (Was mentioned in the thread.)

  111. jonasw

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

  112. Holger

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

  113. jonasw

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

  114. jonasw

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

  115. jonasw

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

  116. SamWhited

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

  117. 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".

  118. jonasw

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

  119. 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

  120. jonasw

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

  121. Zash

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

  122. 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.

  123. stefandxm

    i dont get it :)

  124. stefandxm

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

  125. 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.

  126. Holger

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

  127. stefandxm

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

  128. jonasw

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

  129. Holger

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

  130. 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

  131. SamWhited

    stefandxm: Yes

  132. 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

  133. 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"

  134. 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.

  135. stefandxm

    tbh i will enforce it on receiving aswell

  136. SamWhited

    That's a terrible idea

  137. jonasw

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

  138. stefandxm

    no, it makes stuff crash and burn faster

  139. jonasw

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

  140. 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

  141. Holger


  142. SamWhited

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

  143. Holger

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

  144. 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.

  145. Zash


  146. Guus

    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.

  147. stefandxm

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

  148. Holger

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

  149. stefandxm

    only broken xeps will break

  150. stefandxm

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

  151. Guus

    stefandxm: and any implementation that's not yours.

  152. SamWhited

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

  153. stefandxm

    guus, better have error than confusion

  154. SamWhited

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

  155. stefandxm

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

  156. 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.

  157. stefandxm

    i'd rather have the explicit error yelled at asap

  158. stefandxm

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

  159. jonasw

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

  160. jonasw

    stefandxm, some implementations still emit that code attribute

  161. jonasw

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

  162. stefandxm

    and thats fine by me

  163. jonasw

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

  164. jonasw

    well not allowed, but mentioned

  165. jonasw

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

  166. Holger


  167. jonasw

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

  168. jonasw

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

  169. stefandxm

    ive not seen "code" :o

  170. 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.

  171. jonasw

    Holger, nice!

  172. 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)

  173. Zash

    Holger: Validate how strictly?

  174. Holger

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

  175. SamWhited

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

  176. stefandxm

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

  177. Guus

    that's unexpectedly pleasant news.

  178. stefandxm

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

  179. jonasw

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

  180. jonasw

    stefandxm, schemas as written in XEPs rarely reflect the reality

  181. stefandxm

    i know, schemas are not perfect :)

  182. stefandxm

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

  183. jonasw

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

  184. jonasw

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

  185. stefandxm

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

  186. jonasw

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

  187. 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

  188. jonasw

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

  189. jonasw

    stefandxm, patches welcome or so?

  190. jonasw

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

  191. stefandxm

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

  192. stefandxm

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

  193. jonasw

    stefandxm, I tend to agree

  194. 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

  195. SamWhited

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

  196. 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

  197. SamWhited

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

  198. stefandxm

    i agree with removing/making broken schemas more leniant

  199. Holger

    So yes this is not enforcing strict 6120 or anything.

  200. Holger

    Just trying to reject unknown crap.

  201. stefandxm

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

  202. jonasw

    Holger, that’s fine

  203. Zash

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

  204. jonasw

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

  205. Holger

    Zash: Yes.

  206. Holger

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

  207. 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)

  208. Holger

    jonasw: I'm not sure ...

  209. SamWhited

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

  210. Holger

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

  211. Holger

    And Evgeniy did all this work.

  212. 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

  213. SamWhited

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

  214. 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>)

  215. Zash

    jonasw: wha

  216. jonasw

    SamWhited, there’s clear wording on that

  217. 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

  218. Zash

    What about IQ and presence?

  219. stefandxm

    (in a unique individual namespace that is)

  220. Holger

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

  221. Holger

    *That's* what people stumble over anyway.

  222. 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 (<https://tools.ietf.org/html/rfc6120#section-8.2.3>)

  223. 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

  224. 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

  225. 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.

  226. Holger

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

  227. jonasw

    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>)

  228. jonasw

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

  229. Holger

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

  230. jonasw

    I see

  231. jonasw

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

  232. jonasw


  233. jonasw

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

  234. stefandxm

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

  235. Holger

    jonasw: ACK.

  236. 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).

  237. jonasw

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

  238. Holger

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

  239. Zash

    jonasw: My head!

  240. Holger

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

  241. jonasw

    Zash, I’m sorry!

  242. stefandxm

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

  243. jonasw

    Holger, you need Last Message Correction :-)

  244. jonasw


  245. jonasw

    stefandxm, didn’t know that existed.

  246. stefandxm

    we have made some funky way to get around that

  247. stefandxm

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

  248. stefandxm

    during a valid session

  249. Holger

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

  250. Holger goes reading code.

  251. stefandxm

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

  252. stefandxm

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

  253. stefandxm

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

  254. jonasw

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

  255. Zash

    stefandxm: thanks for volonteering ;)

  256. stefandxm

    iam swamped :p

  257. jonasw

    who isn’t

  258. stefandxm

    but i am basically writing such stuff anyhow

  259. jonasw

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

  260. stefandxm

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

  261. stefandxm

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

  262. jonasw

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

  263. stefandxm

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

  264. 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

  265. Ge0rG

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

  266. jonasw

    Ge0rG, yes and no

  267. 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)

  268. jonasw

    and it violates our (non-normative) schemas

  269. MattJ

    Schemas are per namespace, no?

  270. jonasw


  271. jonasw

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

  272. Flow

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

  273. Zash

    +1, everyone already believes it

  274. SamWhited

    It is official, isn't it?

  275. Flow

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

  276. Flow

    uh, i have a deja vu

  277. SamWhited

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

  278. Flow

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

  279. Guus

    Edwin fixed the logs

  280. Zash

    Praise be Edwin

  281. 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.

  282. 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.

  283. 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

  284. 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

  285. stefandxm

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

  286. stefandxm

    but i see no other way to be dynamic with types

  287. stefandxm

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

  288. 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.

  289. Steve Kille

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

  290. stefandxm

    replace any broken ones with <any> ;-)

  291. Zash

    Is this like the static vs dynamic typing war?

  292. stefandxm

    there has never been a static vs dynamic typing war

  293. stefandxm

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

  294. SouL

    stefandxm, brofist

  295. SouL smiles :)

  296. Flow

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

  297. SamWhited

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

  298. 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

  299. Flow

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

  300. 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

  301. 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

  302. SamWhited

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

  303. Steve Kille

    So, why have the schema??

  304. Flow

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

  305. SamWhited

    Steve Kille: exactly

  306. Flow

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

  307. Flow

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

  308. 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

  309. 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

  310. 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.

  311. tux

    Hey there!

  312. SouL

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

  313. Alex

    hey guys, everybody ready for our member meeting?

  314. Alex

    lets get started

  315. Alex bangs the gavel

  316. stefandxm

    schemas are great and they have to be correct

  317. stefandxm

    btu cannot exist if broken

  318. Alex

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

  319. Alex

    1) Call for Quorum

  320. Alex

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

  321. Alex

    2) Items Subject to a Vote

  322. Alex

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

  323. Alex

    3) Opportunity for XSF Members to Vote in the Meeting

  324. Alex

    anyone here who has not voted yet via memberbot?

  325. stefandxm

    and by broken i mean they give false negatives

  326. stefandxm

    false positives is imo not a problem

  327. SamWhited

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

  328. Alex

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

  329. jonasw

    thanks for your work, Alex :-)

  330. jonasw

    I’m mostly AFK this time though

  331. Alex

    4) Announcement of Voting Results

  332. 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

  333. Alex

    all new and retruning members were accepted, congrats to everyone

  334. Alex

    5) Any Other Business?

  335. Alex

    looks like there is none

  336. Alex

    6) Formal Adjournment

  337. Alex

    I motion that we adjourn

  338. SamWhited


  339. tux


  340. Alex bangs the gavel

  341. SamWhited

    Thanks Alex; much appreciated.

  342. Alex

    thanks everyone

  343. tux

    thanks for making me a member. :)

  344. Alex

    board and council election are coming up

  345. Alex

    will create the application page ASAP

  346. SouL

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

  347. SouL

    Congratulations tux :D

  348. tux

    SouL: to you, too!

  349. Zash

    Thanks Alex

  350. SouL

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

  351. SouL

    Thank you Alex of course :)

  352. Guus

    Welcome, newbies. 😉

  353. jonasw

    congrats, SouL et al

  354. Ge0rG

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

  355. tux


  356. edhelas

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

  357. Ge0rG

    And a free dinner!

  358. mathieui

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

  359. 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.

  360. SamWhited

    emxp: wrong link, I think

  361. emxp


  362. emxp


  363. emxp

    --> https://chaoss.community/

  364. moparisthebest

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