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’ yes
  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 https://github.com/xsf/xeps/pull/998
  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’ 2019
  253. jonas’ no.
  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 Yup
  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 Quite.
  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 Yup.
  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 Absolutely.
  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 o/
  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 Yep
  475. Seve Do you have something, MattJ?
  476. Seve Ok
  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 :-D
  483. ralphm 1. Date of Next
  484. ralphm Tentatively +1W, with the newly elected Directors.
  485. ralphm 2. Close
  486. ralphm Cheers!
  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