XSF Discussion - 2020-11-19

  1. stpeter has joined

  2. stpeter has left

  3. peetah has left

  4. peetah has joined

  5. Wojtek has left

  6. jcbrand has left

  7. emus has left

  8. Seve has left

  9. govanify has left

  10. govanify has joined

  11. Andrzej has joined

  12. andrey.g has left

  13. Andrzej has left

  14. Andrzej has joined

  15. Andrzej has left

  16. Andrzej has joined

  17. lskdjf has left

  18. wladmis has left

  19. LNJ has left

  20. Andrzej has left

  21. govanify has left

  22. govanify has joined

  23. Arne has left

  24. Arne has joined

  25. Alex has left

  26. paul has left

  27. govanify has left

  28. govanify has joined

  29. Andrzej has joined

  30. wurstsalat has left

  31. Andrzej has left

  32. govanify has left

  33. govanify has joined

  34. adiaholic has left

  35. adiaholic has joined

  36. Neustradamus has joined

  37. govanify has left

  38. govanify has joined

  39. Yagiza has joined

  40. adiaholic has left

  41. adiaholic has joined

  42. Andrzej has joined

  43. DebXWoody has joined

  44. NosoyHacker404 has left

  45. NosoyHacker404 has joined

  46. DebXWoody has left

  47. DebXWoody has joined

  48. Andrzej has left

  49. serge90 has left

  50. serge90 has joined

  51. j.r has left

  52. serge90 has left

  53. Seve has joined

  54. lorddavidiii has joined

  55. j.r has joined

  56. govanify has left

  57. govanify has joined

  58. serge90 has joined

  59. alex-a-soto has left

  60. alex-a-soto has joined

  61. Andrzej has joined

  62. j.r has left

  63. emus has joined

  64. wladmis has joined

  65. j.r has joined

  66. serge90 has left

  67. adiaholic has left

  68. adiaholic has joined

  69. Andrzej has left

  70. Andrzej has joined

  71. paul has joined

  72. Mikaela has joined

  73. wurstsalat has joined

  74. Andrzej has left

  75. adiaholic has left

  76. adiaholic has joined

  77. serge90 has joined

  78. lorddavidiii has left

  79. Tobias has joined

  80. serge90 has left

  81. serge90 has joined

  82. lorddavidiii has joined

  83. chronosx88 has joined

  84. gav has left

  85. Shell has left

  86. lorddavidiii has left

  87. floretta has left

  88. Andrzej has joined

  89. eevvoor has joined

  90. eevvoor has left

  91. eevvoor has joined

  92. eevvoor has left

  93. eevvoor has joined

  94. Shell has joined

  95. APach has left

  96. APach has joined

  97. Andrzej has left

  98. Andrzej has joined

  99. Alex has joined

  100. lorddavidiii has joined

  101. Zash has joined

  102. peetah has left

  103. peetah has joined

  104. pasdesushi has joined

  105. Andrzej has left

  106. pasdesushi has left

  107. Shell has left

  108. Shell has joined

  109. eevvoor has left

  110. eevvoor has joined

  111. Andrzej has joined

  112. gav has joined

  113. emus has left

  114. Daniel

    flow, > This PR introduces a breaking change of the wire protocol and hence requires a namespace bump. that's not stricly true for experimental XEPs though, right?

  115. jonas’


  116. adiaholic has left

  117. adiaholic has joined

  118. Daniel

    i mean whether or not it's a good idea to bump can be up to debate. but there is no rule that says you have to

  119. Daniel

    (and in that particular case I don’t think it's a good idea to bump)

  120. Zash

    What now?

  121. Daniel


  122. flow

    Daniel, every xep with a number should undergo a namespace bump if a breakking wire protocol change is introduced

  123. Daniel

    flow, according to your opinion or according to some rule?

  124. jonas’

    flow, quote?

  125. nyco has left

  126. Zash

    Can a thing implementing the old version interop with something implementing the new version?

  127. flow

    I think that is what was practiced in the past (look for example at the jingle namespace, I'd assume a large part was done while the xep was experimental)

  128. flow

    Zash, in this case the answer is no

  129. Alex has left

  130. Daniel

    the fact that individual authors of MAM and jingle decided to bump doesn’t mean that's always a good idea

  131. Alex has joined

  132. flow

    Daniel, I think it is always a good idea as soon as the xep becomes a number

  133. Daniel

    speaking broadly here (looking a bit at MAM) I as a client author often find it easier to just look for a different element or look out for the subtle differences between protocol versions instead implementing a whole new namespace. that might be due to how my library is set up

  134. Daniel

    but code for "is attribute x here if not behave slighlty different" is often less than replicating objects

  135. flow

    One of our objectives is to "ensure interoperability", I think we would violate that objective if we did breaking changes to the wire protocol without a namespace bump in official XEPs

  136. Ge0rG

    > whether or not it's a good idea to bump can be up to debate. It is never a good idea to bump.

  137. Daniel

    anyhow in the particular case of 420+omemo; nobody implements the current version

  138. Daniel

    so we end up increasing the namespace version to infinity without practical use

  139. flow

    Daniel, that is an argument that an namespace bump does not incur a high cost in this case

  140. sonny has left

  141. Daniel

    flow, we should ensure interop for anything that is Draft+

  142. jcbrand has joined

  143. larma

    (in which case we don't namespace bump, because namespace bump is not interoperable)

  144. flow

    Daniel, I think we should ensure interop for every standard we adopted, but we should introduce a supervised place for ProtoXEPs where things can be changed without a nemsapce bump

  145. Daniel

    that's called 'experimental'

  146. marc has left

  147. nyco has joined

  148. flow

    I think we are talking more or less about the same thing: we need a place where XEPs can be easily modified without a namespace bump, but I think if experimental becomes that place, then it would eventually hurd our reputation

  149. marc has joined

  150. flow

    "look XMPP is heavily modular and now even the single modules don't interoperate"

  151. Daniel

    experimental doesn’t become that place it is that place

  152. Daniel

    has been for 20 years

  153. Ge0rG

    flow: you remember that time when we tried to bump Carbons?

  154. larma

    I'd guess that most developers that implement experimental XEPs are well aware that they might have breaking changes...

  155. flow

    that's a guess. I for example wouldn't expect that

  156. larma

    isn't there a bold warning above experimental XEPs, telling they are only for exploratory implementations and not production?

  157. flow

    larma, there is, but that doesn't imply that after you determined via disco#info lookup that an remote entity supports the xep, it actually doesn't

  158. Ge0rG

    with the number of Experimental XEPs running in production, people must be ignoring those warnings

  159. emus has joined

  160. Daniel

    I think that's a failure on our part that we haven’t been moving XEP ups the chain fast enough

  161. flow

    again, yes I also want to have a curated place for ProtoXEPs which can undergo breaking changes without a namespace bump, but experimental isn't the place

  162. Daniel

    a failure that we have slowly been trying to correct

  163. Ge0rG

    flow: for most protocol changes a namespace bump is just the wrong tool. A new feature is much more elegant and well feasible for many protocol changes.

  164. flow

    could be a simple as adding protoxeps/ to the xsf repo and render the XEPs within there

  165. flow

    Ge0rG, if you can do it via a new feature then this is obviously the superior approach to a namespace bump

  166. flow

    Ge0rG, but sadly I don't think this is possible in the PR in question

  167. Ge0rG

    flow: I remember this same discussion from a year or two ago, and I'm pretty sure the conclusion was that all the tools are in place and we are just using Experimental and Draft wrong.

  168. Daniel

    i'm not entirely sure that we reached a conclusion. but at least that wasn’t an unpopular opinion

  169. Ge0rG

    well, there are two parties involved in "using XEP status", the author who might want to push a XEP forward, and the Council that ultimately makes the decision

  170. Ge0rG

    we even introduced Document Shepherds who can push a XEP forward on behalf of the community.

  171. Ge0rG

    but I don't see wide use of that yet.

  172. Ge0rG

    Also community feedback to LCs and CFEs is... sparse

  173. larma

    (yesterday it was discussed in council what happens when file-metadata needs a namespace bump. answer is: it doesn't. All elements are optional and adding new optional elements isn't backwards incompatible. Old implementations will just ignore the new elements. That's good enough for both experimental and draft status. In Final, new elements can be added via new XEPs by using a new namespace. So I'm not aiming to ever namespace bump that XEP.)

  174. APach has left

  175. APach has joined

  176. APach has left

  177. APach has joined

  178. flow

    larma, yes, if I understand the case with file-metadata correctly, this wouldn't require a namespace bump: since all elements are optional, interop is easy, even if new optional elements are added this wouldn't require a namespace bump. only if new required elements are added

  179. sonny has joined

  180. Ge0rG

    larma: what if you want to / have to rename elements?

  181. flow

    Ge0rG, I guess it depends if interop would become an issue in that case

  182. larma

    Beside that, we have clear rules on namespace bumps in an Active, Procedural XEP, so it's not like something for council to decide on. https://xmpp.org/extensions/xep-0053.html: > While the XEP is in the Experimental state, if appropriate and in consultation with the author(s), the XMPP Registrar shall update the namespace version number at the end of namespace (e.g., from "0" to "1"); the XMPP Registrar shall do so only if the protocol defined in the XEP has been modified in a way that is not backwards-compatible with an earlier version of the protocol.

  183. lorddavidiii has left

  184. larma

    Ge0rG, I hardly see how renaming would ever be needed...

  185. lskdjf has joined

  186. emus has left

  187. emus has joined

  188. Ge0rG

    larma: well, that was a rather hypothetical question indeed

  189. LNJ has joined

  190. Kev

    > All elements are optional and adding new optional elements isn't backwards incompatible. That's not entirely true. Someone can write a validator that ensures that the payloads match the allowed protocol (and people do this), so adding new bits of allowed protocol is not backwards compatible with such implementations.

  191. eevvoor

    I have been banned from the kuketzblog muc without having written there anything. Does anyone else has the same problem?

  192. flow

    Kev, I don't like that line of thinking. That would go against the "extensible" in XMPP

  193. flow

    A validator can only validate what he knows, not what he doesn't know

  194. flow

    And we shouldn't close the door on introducing new optional protocol parts without having to bump the namespace

  195. Kev

    flow: Extensible in XMPP has always meant in practice that you can add new namespaces, not that you can change what is allowable within a single namespace.

  196. flow

    Kev, i would challenge that in two ways: first, i am not sure if this is true in the past, and secondly, I think it shouldn't be true in the present and future

  197. Kev

    Whether you like it or not, I'm asserting that this is how the specs are used. Not typically on Internet deployments, but very much in other deployments people care about such things :)

  198. APach has left

  199. lorddavidiii has joined

  200. flow

    in any way, this should be documented

  201. flow

    but I really don't like the idea what we can't even introduce new optional attributes without having a namespace bump

  202. Kev

    flow: We have had such discussions in the past, and I have 99% sure came to the conclusion I've described above, FWIW. And I do not disagree with documenting it.

  203. Kev

    We can still add new attributes, FWIW, but by negotiation.

  204. Kev

    We just can't send them unilaterally and expect that the result will be accepted.

  205. Ge0rG

    Kev: but that effectively means that we can only add new attributes by version bump, not by new feature vars

  206. APach has joined

  207. Ge0rG

    because that would break strict parsers not knowing about the new feature

  208. flow

    Ge0rG, I assume validators validate the structure and content kind, not the concrete content type

  209. larma

    Kev, you'd say it needs to be specifically written in the XEP that more elements are allowed? Because if it is written, the validating entity is actually misbehaving by rejecting unknown elements ;)

  210. Ge0rG meant "elements", not "attributes" in the above statement, but it's actually intersting to know for both

  211. larma

    "Future versions of this XEP may add new elements. Entities are therefor required to silently ignore all unknown elements."

  212. Ge0rG

    larma: it'd be *very* interesting for EXI and other systems that require full knowledge of all supported elements

  213. flow

    Ge0rG, how?

  214. Kev

    larma: Sorry, I was picking up the general point, not a particular XEP. If it says that, all is good.

  215. larma

    It doesn't say it explicitly *yet*, but I'm open on adding it 😉

  216. eevvoor has left

  217. eevvoor has joined

  218. flow

    i feel this would probably lead to more and more future XEPs adding this a disclaimer, not sure if we shouldn't simply switch the default and have XEPs state that they won't add new things without a namespace bump

  219. eevvoor

    Is there some netiquette when to ban people?

  220. lorddavidiii has left

  221. larma

    flow, I agree on that at least for experimental XEPs. For Draft XEPs it might be not that appropriate: given that drafts include a schema, it should be possible to actually use that schema for validating/exi usage (although I personally think our current exi spec is overly complex and would be more likely to be actually implemented if severely simplified such that it's not doing any schema-based compression at all, but that's a different story)

  222. debacle has joined

  223. emus has left

  224. emus has joined

  225. flow

    larma, EXI can cope with incomplete schemas, that's not an issue. And XEP schemas describe that is there, not what is not there

  226. larma

    actually I've seen many schemas describing what is not there...

  227. flow

    larma, possibly, but given that we all aggree that one can plug in new elements under a different namespace (nearly) everywhere in xmpp…

  228. flow

    larma, actually do you have an example for that?

  229. Dele Olajide has joined

  230. larma

    https://xmpp.org/extensions/xep-0060.html item element

  231. larma

    It has explicit "<xs:any namespace='##other'/>"

  232. flow

    is that surprising given that <item/> is a container element for arbitrary payload elements?

  233. larma

    No, but still it explicitly describes what should be default

  234. Kev

    I'm not convinced that moving to a world where you can't write validators because anything goes is an optimal direction. Maybe an Experimental/Draft split there would help, but equally that would work if you consider Experimental to not be deployed, and if you consider Experimental not to be deployed then namespace bumps are also not harmful.

  235. Kev

    But I don't have bandwidth to give it much thought this morning.

  236. pasdesushi has joined

  237. lorddavidiii has joined

  238. arc has left

  239. arc has joined

  240. Zash

    Should https://xmpp.org/extensions/xep-0353.html still be in LC?

  241. APach has left

  242. APach has joined

  243. pasdesushi has left

  244. peetah has left

  245. peetah has joined

  246. pasdesushi has joined

  247. pasdesushi has left

  248. pasdesushi has joined

  249. Steve Kille has left

  250. Steve Kille has joined

  251. pasdesushi has left

  252. jonas’


  253. jonas’


  254. jonas’

    I intend on '0001-restarting those expired LCs after the next elections

  255. Shell has left

  256. pasdesushi has joined

  257. chronosx88 has left

  258. chronosx88 has joined

  259. dwd

    Kev, I think we have, in the past, assumed that adding an optional attribute in an existing namespace is OK. Whether we still should is another matter.

  260. Ge0rG

    dwd: what about adding new elements in an existing namespace?

  261. pasdesushi has left

  262. nyco has left

  263. LNJ has left

  264. dwd

    Ge0rG, I can't think of an example of that.

  265. LNJ has joined

  266. pasdesushi has joined

  267. dwd

    Ge0rG, Whereas, for adding an optional attribute, we did that in XEP-0237 (later folded into RFC 6121).

  268. Ge0rG

    Is there a principal difference between adding elements and attributes, wrt strict schema validators?

  269. dwd

    Kev, FWIW, my understanding is that we have consistently said that if you use the schemas to validate traffic at runtime, you get to keep the pieces. As I say, we may want to change this, but it would be, I think, a change, rather than "moving to a world".

  270. dwd

    Ge0rG, I don't know of one. I think it might be marginally easier to deal with unexpected attributes when processing XML in code than unexpected elements, and we do assume that certain elements only contain a single child.

  271. nyco has joined

  272. Ge0rG

    dwd: I'd say that adding unknown elements is a problem orthogonal to adding multiple elements where only one is allowed

  273. Ge0rG

    I assume you are looking at the allowed content for IQ stanzas

  274. dwd

    Ge0rG, Probably, yes, but it might explain why we've avoided it, explicitly or not.

  275. LNJ has left

  276. dwd

    Ge0rG, I was indeed thinking that, and the question-mark over multiple elements within the XEP-0060 <item/> element.

  277. Ge0rG

    One could argue that the semantic impact of unknown attributes is smaller than of unknown elements

  278. pasdesushi has left

  279. dwd

    Yes, and Kev notes that negotiation makes all this a lot safer.

  280. dwd

    Though I think XEP-0115 added attributes without negotiation.

  281. Ge0rG

    Last year we had a very interesting what-if discussion in the context of steam compression and EXI, which I'd summarize as "a given client should exactly know the schema it can process, and could communicate that to the server on login, so that a custom minimal optimized exi or compression lookup table can be used for that connection, stripping all unknown elements / attributes at the server side "

  282. dwd

    Yup, I recall that. Lead mostly by arc I think.

  283. pasdesushi has joined

  284. arc


  285. arc

    That allows simple clients with hardwired EXI, such as microcontrollers

  286. arc

    Simple client, complex server is a common xmpp protocol design principle

  287. dwd

    Ge0rG, But I don't think that a client requesting that unknown-to-it attributes are stripped by the server is breaking the end-to-end principle.

  288. Shell has joined

  289. Ge0rG

    dwd: given that the client would ignore those attributes anyway, yes. But the same is true for elements

  290. dwd

    Ge0rG, Yes, it is. But I think we developed our unwritten rules of thumb around hand-parsing XML rather than anything else.

  291. arc

    I agree with GeOrG, there's no purpose sending XML schema elements to clients which are not designed to understand them.

  292. dwd

    (And again: I'm not saying that our unwritten rules of thumb are right for today's developers)

  293. dwd

    arc, s/not designed/explicitly claim not/

  294. arc

    Sure it's *nice* to have a xml console showing the raw traffic. That is an edge case that clients can ask for with EXI.

  295. Ge0rG

    dwd: so what does that mean for writing down our unwritten rules of thumb?

  296. Ge0rG

    Should Next Council create an Informational XEP about how and when to bump namespaces?

  297. emus has left

  298. emus has joined

  299. Zash

    If one is submitted, Council will vote on it.

  300. jonas’

    I seem to recall to have proposed to do that and it got shot down

  301. jonas’

    because "it is obvious anyway"

  302. jonas’

    despite such discussions coming up again and again

  303. Zash

    If it's obvious then it should be easy to write it down

  304. Ge0rG

    jonas’: I don't remember your offer or it being shut down, but I think it's a good idea, especially if it covers schema validators and EXI

  305. arc

    EXI literally has a flag to turn on/off whether you want strict schema or not. The problem of servers sending clients unexpected xml elements is one of bandwidth. The sender does not, and should not, know what bandwidth restrictions exist on the receiving side. For example, some IoT devices may turn off support for regular message body, ie chat. They might work only on pubsub and adhoc commands, and regular chat messages can cause their tiny battery powered cpu to wake up too often for them to run on tiny solar cell power.

  306. Ge0rG

    arc: the same mechanism would help mobile clients. No need to send chat state notifications and wake up the device if the client can't display them anyway

  307. Ge0rG

    So by stripping all unknown elements, then dropping empty containers, you'd get immediate optimization

  308. pasdesushi has left

  309. Zash

    Would have been nice if "supports normal chat messages" was in disco/caps

  310. Zash

    ... 20 years ago

  311. Zash

    Ge0rG, tricky if the server doesn't know what the client considers unknown

  312. arc

    Last year I did a contract job on a garden stake that monitored sunlight and soil hygrometer, that interfaced solely with the same company's smart sprinkler system. They used a binary json protocol but did evaluate xmpp, among other protocols, and determined that it would increase the cost of the stake by as much as 70% due to needing a larger solar cell to power it.

  313. Kev

    There's too much backlog to catch up on, but re: using the schema you can keep the pieces - yes, that's true of the schemas as provided, but I know that people produce their own schemas (or schema-like -things) based on the normalitive bits of the XEPs. Which is much less keep-both-parts.

  314. Kev

    (dwd: ^)

  315. arc

    I agree GeOrG

  316. Ge0rG

    Zash: the server would know that if the client uploads its schema, eg for EXI compression

  317. Ge0rG

    Kev: that's only an argument about our schemas not being very well maintained, right?

  318. Kev

    Ge0rG: I think Dave was suggesting that people who do validation are on their own because our schemas aren't normative. I was drawing a distinction between doing validation using the normative text and using the provided non-normative schemas directly.

  319. Kev

    Our schemas aren't particularly well maintained, but I think that's an orthogonal issue to people who validate based on the bits that are well maintaned (the normative text).

  320. arc

    The only schema that matters is the one support about the client, and that doesn't necessarily match the extensions the client supports. Also, clients (eg desktop) can always turn on non-strict encoding to support receiving unexpected XML

  321. Ge0rG

    Kev: I thought that argument applies to any schema validation on xmpp and not just the official schema definitions

  322. Kev

    Ge0rG: AFAIK we have never said that it is e.g. valid to ignore MUSTs.

  323. Kev

    arc: I gather you're talking about EXI schemas here, rather than the general case that I started with.

  324. Kev

    We (or I) were originally talking about entities doing validity enforcement, particularly at security boundaries.

  325. arc

    EXI schemas are XML schemas, because EXI is XML.

  326. Ge0rG

    But there isn't any place stating that an XML stream MUST NOT have elements that aren't defined in a given indicated XEP

  327. Kev

    Ge0rG: No, indeed, but each XEP defines what is valid within its particular namespace.

  328. arc

    I would fully support an extension that allows clients to define the XML schema they want to receive, EXI or not. I actually think that this would be better, especially if it was designed with EXI in mind.

  329. Ge0rG

    Kev: yes, and the question right now is whether that definition is exhaustive by definition

  330. Kev


  331. Ge0rG

    arc: that'd be awesome, provided that we can find an easy way to collect the full supported schema at compile time somehow

  332. arc

    Note that XML schema informs EXI grammar, but these two things should not be confused. EXI grammar includes things like weighting certain elements that are seen more often in order to transfer them with fewer bits, etc.

  333. Ge0rG

    arc: well, those parts of the grammar can only be obtained from prior measurements, right?

  334. arc

    One of the major reasons peter's EXI XEPs are not workable is they confuse the two and do not define many aspects, eg, rules for how multiple schemas are combined to create a grammar.

  335. arc

    GeOrG grammar could be developed through statistical analysis, but the EXI spec doesn't require any specific method. Only the client and server understand the grammar each other are using.

  336. arc

    I would assume that in most cases software developers would design their own grammar.

  337. Ge0rG

    arc: yeah, and then we need a mechanism to upload a grammar in a normal form and have a server side cache for grammars

  338. arc


  339. Ge0rG

    How much work is needed to get that into prototype state?

  340. lorddavidiii has left

  341. arc

    I have suggested a mechanism whereas the client assumes the server already has it, defines on the EXI stream by sha256, and then if the server does not support it responds with a "common" EXI grammar known to all clients with an error message that it does not have that grammar in cache, asking the client to restart and send the grammar first.

  342. Ge0rG

    arc: yeah, but sha256 requires a normal form, and regular xml can be used if the switch fails

  343. arc

    Another big problem with the existing EXI drafts is defining the schemas by URL that they can be fetched, on a connection before the user has authorized, allowing for a form of DDoS attack by having many clients contact the server requesting large files from third party hosts.

  344. arc

    No, that'd require all clients to need support for plain text xml. There should be a standardized exi grammar for that transfer.

  345. arc

    Removing plain text XML support almost has the size of the compiled library

  346. Ge0rG

    Yeah, server side fetching of random URLs is a huge can of worms.

  347. arc

    Remember that in order for this to be commercially viable, it has to work as well as proprietary alternatives. Squeezing a <1k binary grammar onto the library can be doable.

  348. Ge0rG

    XXE is just one of the evil problems

  349. arc


  350. Ge0rG

    No idea if we can somehow make it secure nevertheless. Even if we require authentication beforehand, the vector is still there and needs to be mitigated

  351. arc

    This is absolutely nothing with the work I've been doing over the last year, but I would happily participate in a working group to draft an extension for schema/grammar exchange and exi in general

  352. eevvoor has left

  353. Zash

    Could have some set of centrally managed grammars maybe?

  354. arc

    For my current project I'm kind of sad to be using Rust's xmpp parser crate

  355. eevvoor has joined

  356. Zash

    Simliar to the pre-made caps cache project that exists/-ed

  357. Ge0rG

    Zash: that wouldn't scale, also schema can vary depending on which features a client has enabled

  358. Adi has left

  359. arc

    Zash I don't think there needs to be. For starters, it breaks the decentralized nature of xmpp. The code requirements to send the grammar is pretty small.

  360. Zash

    Ge0rG: I'm thinking Good Enough, not perfect for everyone. Something based on the Compliance Suite of the year maybe?

  361. intosi has left

  362. adiaholic has left

  363. adiaholic has joined

  364. debacle has left

  365. arc

    You're looking to solve a problem that doesn't exist. It's fine to have clients send their own grammar. What we lack is a standard grammar to transfer that grammar. And part of that, the schema for defining the grammar. That is outside of the scope of the exi standard.

  366. pasdesushi has joined

  367. lorddavidiii has joined

  368. arc

    EXI only requires that the grammar is understood by both parties. It does not even specify a standard grammar identifier, just the field in the exi header.

  369. Ge0rG

    Zash: imagine a central authoritative directory of entity caps

  370. Ge0rG

    That would be like that, but worse

  371. serge90 has left

  372. Ge0rG

    arc: could we make a first attempt with oob transfer of grammars based on white listed URLs?

  373. Ge0rG

    arc: is there any syntax available for grammars, outside of exi byte streams?

  374. arc

    Again, I don't think it's necessary. In order to do that we need to have a standard format, and once we have a standard format we basically have the mechanism to send it from any client

  375. flow

    Not sure what's so wrong about Zash's suggestion? A central catalogue of grammers seems like a good idea. It is not like you have to use it…

  376. Ge0rG

    So you need to invent a grammar to transmit grammars.

  377. arc

    Some libraries have a format they use, but as far as I've seen there is no standard.

  378. Ge0rG

    flow: it will be useless

  379. pasdesushi has left

  380. flow

    Ge0rG, that is what you have said before, but I still wonder why?

  381. Ge0rG

    arc: how much work will it be? Are you actively working on it?

  382. Ge0rG

    flow: because each compiled client artifact will have its unique grammar

  383. antranigv has left

  384. serge90 has joined

  385. Ge0rG

    At least if you want to use the grammar for server side filtering of unknown elements

  386. arc

    No right now I am actively working on a H3 library in rust and a WebGL game engine. H3 (h3geo.org) is fascinating but unrelated to this.

  387. Ge0rG

    Sounds a bit like ingress

  388. arc

    No it is a plant scale MMO of a fictional earth-sized alien world. H3, being hierarchical and hexagon-based, is just an ideal solution. The engine only uses XMPP for authentication and to establish ICE for WebRTC audio and data channels.

  389. Andrzej has left

  390. arc

    https://youtu.be/wDuKeUkNLkQ?t=754 if you want to learn more, it's fascinating stuff and there is very good language support. Even a extension for PostGIS

  391. Andrzej has joined

  392. lorddavidiii has left

  393. Andrzej has left

  394. Andrzej has joined

  395. Andrzej has left

  396. Andrzej has joined

  397. Andrzej has left

  398. Andrzej has joined

  399. Adi has joined

  400. Andrzej has left

  401. Andrzej has joined

  402. intosi has joined

  403. Andrzej has left

  404. Andrzej has joined

  405. antranigv has joined

  406. Andrzej has left

  407. Andrzej has joined

  408. arc has left

  409. pasdesushi has joined

  410. arc has joined

  411. arc

    Its been over a year since I've had any xmpp related contracts, but I'd be happy to contribute to a working group to get exi finally settled. If people want to work on it.

  412. arc

    It sounds like a lot of the contract firms that used to support xmpp have lost interest, like &yet

  413. pasdesushi has left

  414. pasdesushi has joined

  415. pasdesushi has left

  416. pasdesushi has joined

  417. pasdesushi has left

  418. Ge0rG

    arc: it's an interesting topic for me as a mobile client developer, but I have zero time to push it forward. The most I could do is writing s blog post or a wiki page outlining the status quo and the current challenges

  419. intosi has left

  420. Andrzej has left

  421. Andrzej has joined

  422. arc

    I haven't been paying much attention because it's outside the scope of my work, but how is MIX progressed over the last year?

  423. lorddavidiii has joined

  424. Andrzej has left

  425. Andrzej has joined

  426. intosi has joined

  427. alex-a-soto has left

  428. alex-a-soto has joined

  429. flow

    a bit, I guess we are at the state where we need more MIX implemenations to gather implementation experience. but besides an older (and potentially incomplete) ejabberd, there is only one, more recent one, in tigase. but hey, it's better than none :)

  430. flow

    I think Daniel also has a MIX branch for conversations but I could imagine that this branch also stalled due the lack of MIX support in ejabberd

  431. adiaholic has left

  432. j.r has left

  433. adiaholic has joined

  434. MattJ

    Someone reported recently that they have been working on a MIX plugin for Prosody

  435. Guus

    There's an old implementation in Openfire somewhere too

  436. flow

    hmm hopefully that doesn't summarize the state of MIX: there is an old implemenation somehwere, maybe, but maybe not :)

  437. dwd

    Guus, There's the partial Surevine one in github.com/surevine/Openfire I think, yes.

  438. Guus

    Have not used it myself though

  439. Andrzej has left

  440. dwd

    Guus, Though I also think that everyone involved with that has moved on from Surevine, in line with The Curse Of MIX.

  441. Andrzej has joined

  442. APach has left

  443. APach has joined

  444. Guus

    There have reportedly been people moved on that had not even been involved with their MIX implementation. That's how bad The Curse is...

  445. dwd

    Surevine was afflicted by multiple curses. :-)

  446. Zash

    Is falling asleep every time I try to read the MIX XEPs part of the curse?

  447. floretta has joined

  448. Nekit has left

  449. Guus

    No, that's just a lack of attention span.

  450. Guus

    @board: I'm sadly unlikely to make the meeting later today

  451. Guus

    I'll try to lurk, but I've been pulled into a meeting

  452. Nekit has joined

  453. Andrzej has left

  454. Andrzej has joined

  455. j.r has joined

  456. Andrzej has left

  457. Andrzej has joined

  458. lorddavidiii has left

  459. chronosx88 has left

  460. chronosx88 has joined

  461. Andrzej has left

  462. Andrzej has joined

  463. ralphm bangs gavel

  464. ralphm

    0. Welcome

  465. ralphm

    Hi all. Welcome to the last Board meeting of this term.

  466. ralphm

    Who do we have?

  467. dwd

    Well, not Guus.

  468. ralphm


  469. Seve says hi!

  470. MattJ


  471. ralphm

    Quorum, yay.

  472. ralphm

    Unless y'all disagree, I don't think there's much to discuss today.

  473. Seve agrees.

  474. MattJ


  475. Seve

    Do you have something, MattJ?

  476. Seve


  477. ralphm

    Cool. Then, I'd like to thank everyone for their efforts this term!

  478. MattJ

    Thank you for chairing :)

  479. lskdjf has left

  480. Seve

    And good luck to the next one! :)

  481. lskdjf has joined

  482. ralphm


  483. ralphm

    1. Date of Next

  484. ralphm

    Tentatively +1W, with the newly elected Directors.

  485. ralphm

    2. Close

  486. ralphm


  487. Seve

    Perfect, thank you!!

  488. ralphm bangs gavel

  489. lorddavidiii has joined

  490. lskdjf has left

  491. Guus

    And I'm out my meeting

  492. Guus

    just in time, I see. 🙂

  493. Guus

    sorry for that.

  494. lskdjf has joined

  495. lskdjf has left

  496. lskdjf has joined

  497. lskdjf has left

  498. lskdjf has joined

  499. Andrzej has left

  500. lskdjf has left

  501. serge90 has left

  502. Andrzej has joined

  503. goffi has joined

  504. serge90 has joined

  505. Andrzej has left

  506. Andrzej has joined

  507. APach has left

  508. APach has joined

  509. Wojtek has joined

  510. lskdjf has joined

  511. lorddavidiii has left

  512. lskdjf has left

  513. lskdjf has joined

  514. Andrzej has left

  515. Andrzej has joined

  516. raghavgururajan has left

  517. adiaholic has left

  518. adiaholic has joined

  519. raghavgururajan has joined

  520. Shell has left

  521. lskdjf has left

  522. lskdjf has joined

  523. lskdjf has left

  524. lskdjf has joined

  525. lorddavidiii has joined

  526. Dele Olajide has left

  527. Dele Olajide has joined

  528. emus has left

  529. emus has joined

  530. NosoyHacker404 has left

  531. lovetox has joined

  532. NosoyHacker404 has joined

  533. Andrzej has left

  534. Andrzej has joined

  535. lskdjf has left

  536. adiaholic has left

  537. adiaholic has joined

  538. Andrzej has left

  539. Andrzej has joined

  540. lskdjf has joined

  541. stpeter has joined

  542. stpeter has left

  543. lskdjf has left

  544. lskdjf has joined

  545. APach has left

  546. APach has joined

  547. Andrzej has left

  548. Andrzej has joined

  549. Shell has joined

  550. Andrzej has left

  551. Andrzej has joined

  552. APach has left

  553. APach has joined

  554. lskdjf has left

  555. lskdjf has joined

  556. lskdjf has left

  557. lskdjf has joined

  558. papatutuwawa has joined

  559. APach has left

  560. APach has joined

  561. lskdjf has left

  562. lskdjf has joined

  563. NosoyHacker404 has left

  564. intosi has left

  565. NosoyHacker404 has joined

  566. lskdjf has left

  567. lskdjf has joined

  568. papatutuwawa has left

  569. lskdjf has left

  570. lskdjf has joined

  571. intosi has joined

  572. Guus has left

  573. Guus has joined

  574. krauq has left

  575. debacle has joined

  576. krauq has joined

  577. LNJ has joined

  578. akkiko has joined

  579. speedball has joined

  580. wladmis has left

  581. sonny has left

  582. sonny has joined

  583. antranigv has left

  584. Andrzej has left

  585. intosi has left

  586. adiaholic has left

  587. lskdjf has left

  588. Steve Kille has left

  589. floretta has left

  590. Andrzej has joined

  591. Steve Kille has joined

  592. intosi has joined

  593. lskdjf has joined

  594. nad287 has joined

  595. pasdesushi has joined

  596. intosi has left

  597. pasdesushi has left

  598. pasdesushi has joined

  599. Andrzej has left

  600. Andrzej has joined

  601. pasdesushi has left

  602. speedball has left

  603. papatutuwawa has joined

  604. intosi has joined

  605. lorddavidiii has left

  606. lorddavidiii has joined

  607. eevvoor has left

  608. Nekit has left

  609. antranigv has joined

  610. floretta has joined

  611. pasdesushi has joined

  612. pasdesushi has left

  613. pasdesushi has joined

  614. lorddavidiii has left

  615. pasdesushi has left

  616. Andrzej has left

  617. Andrzej has joined

  618. j.r has left

  619. lorddavidiii has joined

  620. j.r has joined

  621. j.r has left

  622. j.r has joined

  623. j.r has left

  624. pasdesushi has joined

  625. j.r has joined

  626. Andrzej has left

  627. pasdesushi has left

  628. pasdesushi has joined

  629. j.r has left

  630. j.r has joined

  631. lorddavidiii has left

  632. pasdesushi has left

  633. chronosx88 has left

  634. chronosx88 has joined

  635. pasdesushi has joined

  636. lorddavidiii has joined

  637. Arne has left

  638. Arne has joined

  639. pasdesushi has left

  640. chronosx88 has left

  641. raghavgururajan has left

  642. raghavgururajan has joined

  643. raghavgururajan has left

  644. Dele Olajide has left

  645. Dele Olajide has joined

  646. Dele Olajide has left

  647. Dele Olajide has joined

  648. Dele Olajide has left

  649. adiaholic has joined

  650. Dele Olajide has joined

  651. Dele Olajide has left

  652. Dele Olajide has joined

  653. lorddavidiii has left

  654. lorddavidiii has joined

  655. pasdesushi has joined

  656. raghavgururajan has joined

  657. Dele Olajide has left

  658. Mikaela has left

  659. pasdesushi has left

  660. pasdesushi has joined

  661. pasdesushi has left

  662. pasdesushi has joined

  663. lorddavidiii has left

  664. raghavgururajan has left

  665. Dele Olajide has joined

  666. pasdesushi has left

  667. pasdesushi has joined

  668. pasdesushi has left

  669. pasdesushi has joined

  670. pasdesushi has left

  671. pasdesushi has joined

  672. pasdesushi has left

  673. pasdesushi has joined

  674. pasdesushi has left

  675. pasdesushi has joined

  676. pasdesushi has left

  677. pasdesushi has joined

  678. pasdesushi has left

  679. pasdesushi has joined

  680. pasdesushi has left

  681. pasdesushi has joined

  682. pasdesushi has left

  683. pasdesushi has joined

  684. krauq has left

  685. krauq has joined

  686. pasdesushi has left

  687. pasdesushi has joined

  688. pasdesushi has left

  689. pasdesushi has joined

  690. DebXWoody has left

  691. raghavgururajan has joined

  692. jcbrand has left

  693. pasdesushi has left

  694. raghavgururajan has left

  695. raghavgururajan has joined

  696. lskdjf has left

  697. lskdjf has joined

  698. lskdjf has left

  699. lskdjf has joined

  700. lskdjf has left

  701. lskdjf has joined

  702. Wojtek has left

  703. raghavgururajan has left

  704. raghavgururajan has joined

  705. raghavgururajan has left

  706. raghavgururajan has joined

  707. pasdesushi has joined

  708. akkiko has left

  709. lskdjf has left

  710. pasdesushi has left

  711. Tobias has left

  712. goffi has left

  713. pasdesushi has joined

  714. peetah has left

  715. peetah has joined

  716. Nekit has joined

  717. peetah has left

  718. peetah has joined

  719. papatutuwawa has left

  720. antranigv has left

  721. antranigv has joined

  722. krauq has left

  723. krauq has joined

  724. krauq has left

  725. krauq has joined

  726. krauq has left

  727. krauq has joined

  728. raghavgururajan has left

  729. raghavgururajan has joined

  730. antranigv has left

  731. Link Mauve

    “13:06:51 arc> For my current project I'm kind of sad to be using Rust's xmpp parser crate”, why sad?

  732. antranigv has joined

  733. adiaholic has left

  734. Alex has left

  735. lovetox has left

  736. nad287 has left

  737. pasdesushi has left

  738. pasdesushi has joined

  739. pasdesushi has left

  740. Yagiza has left

  741. pasdesushi has joined

  742. paul has left

  743. wladmis has joined

  744. pasdesushi has left

  745. pasdesushi has joined

  746. pasdesushi has left

  747. pasdesushi has joined

  748. Dele Olajide has left

  749. alameyo has left

  750. pasdesushi has left

  751. Vaulor has left