jdev - 2022-08-31


  1. al has left
  2. thomaslewis has joined
  3. emus has left
  4. thomaslewis has left
  5. thomaslewis has joined
  6. thomaslewis has left
  7. Maranda has joined
  8. Mjolnir Archon has joined
  9. thomaslewis has joined
  10. thomaslewis has left
  11. debacle has left
  12. debacle has joined
  13. debacle has left
  14. al has joined
  15. xnamed has left
  16. xnamed has joined
  17. Mx2 has left
  18. Kev has left
  19. Kev has joined
  20. kikuchiyo has joined
  21. Mx2 has joined
  22. andrew has joined
  23. thomaslewis has joined
  24. hearty has left
  25. al has left
  26. nik has joined
  27. raghavgururajan has joined
  28. hearty has joined
  29. Millesimus has left
  30. Millesimus has joined
  31. Schimon has joined
  32. spiral has left
  33. spiral has joined
  34. xnamed has left
  35. spectrum has left
  36. spectrum has joined
  37. u has left
  38. Yagizа has joined
  39. spiral has left
  40. spiral has joined
  41. SouL has joined
  42. atomicwatch has joined
  43. MSavoritias (fae,ve) has joined
  44. marc0s has left
  45. marc0s has joined
  46. goffi has joined
  47. wurstsalat has joined
  48. jgart has left
  49. atomicwatch has left
  50. emus has joined
  51. nephele has joined
  52. atomicwatch has joined
  53. nephele has left
  54. rubi has left
  55. rubi has joined
  56. marc has joined
  57. rubi has left
  58. atomicwatch has left
  59. Apollo has left
  60. Laura has left
  61. rubi has joined
  62. rubi has left
  63. rubi has joined
  64. pulkomandy has left
  65. adx has joined
  66. rubi has left
  67. rubi has joined
  68. Patiga has left
  69. Apollo has joined
  70. thomaslewis has left
  71. larma has joined
  72. iink has left
  73. iink has joined
  74. iink has left
  75. iink has joined
  76. raghavgururajan has left
  77. raghavgururajan has joined
  78. mh has left
  79. pulkomandy has joined
  80. norayr has left
  81. norayr has joined
  82. mh has joined
  83. antranigv has joined
  84. antranigv has left
  85. nik has left
  86. nik has joined
  87. pulkomandy has left
  88. antranigv has joined
  89. antranigv has left
  90. antranigv has joined
  91. Mario Sabatino has left
  92. Mario Sabatino has joined
  93. norayr has left
  94. antranigv has left
  95. xnamed has joined
  96. SouL has left
  97. Mario Sabatino has left
  98. Mario Sabatino has joined
  99. gregory has joined
  100. norayr has joined
  101. SouL has joined
  102. norayr has left
  103. atomicwatch has joined
  104. al has joined
  105. debacle has joined
  106. pulkomandy has joined
  107. PapaTutuWawa has joined
  108. Patiga has joined
  109. norayr has joined
  110. antranigv has joined
  111. antranigv has left
  112. pulkomandy has left
  113. antranigv has joined
  114. sonny has left
  115. jubalh has left
  116. Wojtek has joined
  117. mh has left
  118. mh has joined
  119. u has joined
  120. antranigv has left
  121. pulkomandy has joined
  122. rubi has left
  123. rubi has joined
  124. pulkomandy has left
  125. antranigv has joined
  126. u has left
  127. u has joined
  128. Laura has joined
  129. SouL has left
  130. xnamed has left
  131. xnamed has joined
  132. mh has left
  133. MattJ Holger, is xpath currently used in ejabberd? Would there be any objection if it was a XEP dependency? (or at least a subset)
  134. mh has joined
  135. MattJ I'm pretty wary of XPath, but also wary of NIH something equivalent
  136. MattJ https://github.com/clopen/xpath-receive-email
  137. norayr has left
  138. norayr has joined
  139. Schimon has left
  140. Schimon has joined
  141. Kev I'm pretty wary of XPath. I don't think there's any danger of us needing to NIH something *equivalent*, which is where the danger in it lies.
  142. Sam Was trying to figure out a good way to say just that. What Kev said.
  143. Kev What we're likely to need is to NIH a way of referencing a path to an XML element, which ... is a long way short of XPath.
  144. antranigv has left
  145. Mx2 has left
  146. Kev Bonus points if we used constrained XPath so that you could either use an xpath library, or implement something non-insane yourself just to do basic path lookups.
  147. Sam {space:local}/local/{space:*}>someattr there, wrote a whole spec with all the features you could want.
  148. Kev I think even xpath 1 lets you define functions etc. doesn't it? The path formats themselves aren't insane, I think, and are implementable oneself without excessive pain, unless I misremember.
  149. Kev But anything that lets you define functions seems...ill-advised.
  150. Sam "constrained XPath" sounds exactly as bad as "constrained XML" which I have had multiple bugs as a result of us doing (and found multiple issues in other things). That way leads to madness and implementations just ignoring the constraints.
  151. Sam Or security issues when they accidentally ignore the constraints or there's some way to smuggle some escaped function past their constraining code.
  152. mh has left
  153. Kev There ... is some truth in that.
  154. Kev Actually, looking at XPath, I think even the Location Paths are probably more than anything we'd need in XMPP.
  155. Kev MattJ What's the problem getting solved?
  156. mh has joined
  157. al has left
  158. norayr has left
  159. norayr has joined
  160. norayr has left
  161. norayr has joined
  162. anubis has joined
  163. anubis has left
  164. anubis has joined
  165. anubis has left
  166. jubalh has joined
  167. MattJ Kev, clients need to tell their server what information should be sent to their push notification server when offline
  168. MattJ Current spec approach is "just send <body/>", which nobody actually does because of privacy
  169. Kev So something a lot lot simpler than xpath would work fine, presumably?
  170. MattJ Non-standard approach by Tigase is to extract some specific stuff, transform it into JSON, and send that
  171. MattJ But that loses all extensibility
  172. MattJ Yes, definitely (hence why I said "subset")
  173. MattJ But as Sam said, "just" supporting a subset when available libraries implement the full thing can be dangerous
  174. MattJ People will pick off-the-shelf libraries and either fail to disable the dangerous parts or make inadequate attempts to sanitize things
  175. Kev Even ignoring Sam's (I think valid) concerns, using an xpath library for this on the server sounds like some amount of pain - at least for us it'd involve serialising temporarily, parsing that into an appropriate XML doc, running the XPath on it, and then converting into the internal format again, for then reserialising later (or similar).
  176. MattJ Sure, it would be some amount of pain for Prosody too
  177. Kev Probably (with no data to support this) doubling the cost of processing each stanza or something.
  178. MattJ That's a bit over the top, since this wouldn't run on every stanza
  179. nik has left
  180. Kev Every eligible stanza, right.
  181. Kev But I think that's probably every message, as 'most people' don't have their phone app open 'most of the time'.
  182. Kev But you're right, and that's not on its own a reason to not do it. The inconvenience might be, and the security concerns probably are.
  183. MattJ Okay, so say you're right and it doubles... it goes from how many microseconds to how many microseconds?
  184. Kev ^
  185. jubalh has left
  186. MattJ I'm not saying bringing in XPath is something I'd enjoy. But I'm trying to get a feel for all our options, because this issue has been stalling progress in this area for years now.
  187. MattJ We have an internal custom "XPath lite" in Prosody, which is of course non-standard
  188. MattJ and as you say, just allows a path to an element, attribute or text content
  189. MattJ As far as I'm concerned, standardizing that (or something like it) is the NIH approach
  190. MattJ Which is not to say it's automatically wrong, if nothing else is suitable
  191. MattJ Thankfully this is also something that would only be needed on servers
  192. larma has left
  193. Mx2 has joined
  194. Kev I’m pretty comfortable with NIHing something that’s just {NS}ele/… or similar if the alternative is xpath. I think integrating full xpath would actively be a mistake if we only need the former, and Sam’s concerns about subsetting it seem valid.
  195. MattJ So do we have consensus for XEP-xxxx: Element Path Queries?
  196. Kev WFM
  197. MattJ I'll write something up for discussion
  198. Mx2 has left
  199. Matrix Traveler (bot) has left
  200. homebeach has left
  201. homebeach has joined
  202. Matrix Traveler (bot) has joined
  203. antranigv has joined
  204. Alex has left
  205. Alex has joined
  206. anubis has joined
  207. antranigv has left
  208. anubis has left
  209. Kev Ta.
  210. iink has left
  211. iink has joined
  212. Sam Excellent, thanks MattJ
  213. Mx2 has joined
  214. mh has left
  215. raghavgururajan has left
  216. mh has joined
  217. MSavoritias (fae,ve) has left
  218. omighty has joined
  219. mh has left
  220. PapaTutuWawa has left
  221. anubis has joined
  222. anubis has left
  223. anubis has joined
  224. anubis has left
  225. SouL has joined
  226. lovetox Sorry for my ignorance, what is the use case for that?
  227. lovetox it that not something on the xml lib level, and not the xmpp?
  228. MattJ Use case: > clients need to tell their server what information should be sent to their push notification server when offline
  229. MattJ And XML libraries provide XPath, if they provide anything at all
  230. SouL has left
  231. MattJ SAX parsers like expat (a popular choice for XMPP) tend not to provide XPath because they don't store the document or expose any kind of DOM
  232. lovetox ok thanks
  233. goffi MattJ: As you're working on this use case, I would like to use push notification with a trusted component to send email to users when they get a pubsub notification while offline. For instance says that you have a new comment on a blog post, I would need the pubsub element to construct the email. Privacy is not a problem here as it would be a trusted component with the same admins as the server itself.
  234. hearty has left
  235. goffi MattJ: thus if the protoXEP you're working on or planning to work on would take this use case into account, it would be great
  236. kurtain has joined
  237. MattJ Yes, it should suffice for that use-case too
  238. kurtain has left
  239. goffi neat
  240. rubi has left
  241. rubi has joined
  242. atomicwatch has left
  243. mh has joined
  244. goffi MattJ: regarding XPath, I think too that we don't need a full features XPATH and can make our own stuff. XPath is handy to check complex XML trees, but in the case of XMPP it's often not deep, and we can probably filter with simple stuff like element name/namespace + optionally attribute or maybe a index if there are several elements with same name/namespace. Do we need something that can be put in an attribute, or can we use dedicated element for that? Something like `<find_element name="body">` ? Advantage is that we could extend it if necessary in the future.
  245. hearty has joined
  246. stuart.j.mackintosh has left
  247. stuart.j.mackintosh has joined
  248. jubalh has joined
  249. goffi MattJ: we could also use `id` to put them in attribude, something like: `<something-useful use-element="find_123" /><find-element id="find_123" name="something-useful" ns="urn:example:bla:0" xmlns="urn:example:find-element:0" />`
  250. MattJ That can easily start to get very complex to implement
  251. mh has left
  252. goffi I don't think so, you end up with simple filtering data that you can either use directly in a loop, or transform easily to an XPATH or equivalent internally. But anyway, it was just random thought, you'll end up with something cool I'm sure.
  253. mh has joined
  254. MattJ https://pad.nixnet.services/s/g9orugzSq is an initial draft
  255. Kev Would it be easier to not have implicit namespace inheritance?
  256. MattJ My feeling is "no" :)
  257. MattJ But maybe
  258. MattJ It would be easier if we actually had a single standard root namespace in XMPP
  259. Kev Ah. Because of stream namespace. Right.
  260. MattJ But we can always specify in the downstream XEPs that everything is in jabber:client or something
  261. MattJ But if it's about implementation complexity for the components without a namespace, we already do that in Prosody and it's not much effort (but I'd be curious to hear if that's not the case in other codebases)
  262. SouL has joined
  263. rubi has left
  264. Ingolf has left
  265. rubi has joined
  266. antranigv has joined
  267. SouL has left
  268. SouL has joined
  269. rubi has left
  270. goffi MattJ: what about several elements with same name/namespace (e.g. in your example, you would have an extra `<entry title="The Hobbit" />`
  271. goffi )
  272. MattJ Yeah, I intentionally avoided that for now :)
  273. goffi but we need to know if we get first or last elements
  274. goffi in this case
  275. rubi has joined
  276. pep. It only matters if the order of elements is guaranteed I guess. But this spec can still specify it
  277. goffi with <message> it's important as we can have several bodies (with different languages), for blog we have text and xhtml content
  278. MattJ Prosody gives the first
  279. MattJ But I suspect we may want to add indexing and predicates
  280. anubis has joined
  281. MattJ I think we're doing this for extensibility, people are going to find uses for those things
  282. pep. Registering to your server features you don't want to see? Curious if that'd be a use-case
  283. pep. "no chatstates, no chat markers, no receipts plz"
  284. MattJ pep., meet https://xmpp.org/extensions/xep-0273.html :)
  285. pep. That title sounds..
  286. MattJ It's from 2009, assume innocence
  287. jubalh has left
  288. pep. ^^'
  289. SouL has left
  290. PapaTutuWawa has joined
  291. norayr has left
  292. norayr has joined
  293. antranigv has left
  294. Sam has left
  295. anubis has left
  296. Sam has joined
  297. jonas’ has left
  298. Sam has left
  299. anubis has joined
  300. Sam has joined
  301. Ingolf has joined
  302. rubi has left
  303. rubi has joined
  304. spiral has left
  305. spiral has joined
  306. antranigv has joined
  307. Mx2 has left
  308. antranigv has left
  309. eu has left
  310. eu has joined
  311. SouL has joined
  312. iink has left
  313. iink has joined
  314. e-snail has left
  315. e-snail has joined
  316. MSavoritias (fae,ve) has joined
  317. MattJ Okay, I got a bit daring and added some more advanced stuff: https://pad.nixnet.services/s/g9orugzSq
  318. omighty has left
  319. omighty has joined
  320. norayr has left
  321. norayr has joined
  322. Mx2 has joined
  323. goffi MattJ: It looks good to me. It's very similar to lxml's ElementPath.
  324. antranigv has joined
  325. Zash speccing stanza:find() ?
  326. MattJ Something like that
  327. Zash except it's more limited
  328. Zash except stanza:find() is more limited
  329. MattJ But still, I'm now going back to https://hg.prosody.im/prosody-modules/file/8231774f5bfd/mod_cloud_notify_encrypted/mod_cloud_notify_encrypted.lua#l88 to see what that logic would look like translated to XML/paths, and... I don't know
  330. Sam Is there a behavioral difference between entries/entry@title and entries/entry[title]@title?
  331. Zash or upload an util.datamapper schema?
  332. Zash my guess would be that the former may match a tag without the attribute?
  333. MattJ Exactly
  334. moparisthebest Just have the client upload some JavaScript the server can execute to construct what to send...
  335. Sam So one returns empty string one returns no match?
  336. Sam If the attribute doesn't exist do they both return no match?
  337. thomaslewis has joined
  338. MattJ Yes
  339. thomaslewis has left
  340. spiral has left
  341. Wojtek has left
  342. Zash Any need to collect lists of things?
  343. antranigv has left
  344. pulkomandy has joined
  345. MattJ I'm not sure
  346. MattJ I suspect that the answer is "maybe" but can usually be deduced from the context rather than needing some operator
  347. MattJ i.e. if only one result is expected, just take the first
  348. MattJ Which is probably going to be the most common
  349. MattJ But as I say, unless we can figure out how to actually apply this, I'm unconvinced it's useful
  350. spiral has joined
  351. antranigv has joined
  352. Link Mauve I remember a discussion recently where someone wanted to send wasm blobs to other entities for processing. :°)
  353. moparisthebest Hey that's better than JavaScript let's do it
  354. Wojtek has joined
  355. jgart has joined
  356. Yagizа has left
  357. norayr has left
  358. norayr has joined
  359. Yagizа has joined
  360. antranigv has left
  361. antranigv has joined
  362. SouL has left
  363. antranigv has left
  364. Wojtek has left
  365. antranigv has joined
  366. thomaslewis has joined
  367. SouL has joined
  368. thomaslewis has left
  369. thomaslewis has joined
  370. thomaslewis has left
  371. antranigv has left
  372. selurvedu has left
  373. selurvedu has joined
  374. selurvedu has left
  375. MattJ goffi, I think in your case you'd be happy bouncing the whole stanza to the push server, I assume
  376. MattJ Because you're going to email it, and I assume that won't be encrypted, so you don't have anything to hide from the push service
  377. thomaslewis has joined
  378. goffi MattJ: indeed, I would be happy with the whole stanza, the component is trustable no privacy problem there.
  379. MattJ The problem for the Siskin-style push notifications is that they need to be 1) summarized (Apple has size limits on notifications) and 2) encrypted (so neither Apple nor the push service see any message details)
  380. thomaslewis has left
  381. MattJ #2 is easy enough, but #1 is currently implemented using logic on the server side that isn't extensible and right now even depends on experimental XEPs
  382. MattJ Some discussion is at https://github.com/tigase/tigase-xeps/issues/4
  383. MattJ An alternative approach is to spec the summarization process, and make sure that can be negotiated and evolved over time
  384. SouL has left
  385. marc has left
  386. antranigv has joined
  387. marc has joined
  388. Wojtek has joined
  389. antranigv has left
  390. Zash Per XEP treatment? Would be sorta in line with MAM, CSI, Carbons etc
  391. sonny has joined
  392. thomaslewis has joined
  393. SouL has joined
  394. PapaTutuWawa has left
  395. Matrix Traveler (bot) has left
  396. homebeach has left
  397. homebeach has joined
  398. Matrix Traveler (bot) has joined
  399. thomaslewis has left
  400. hearty has left
  401. mh has left
  402. hearty has joined
  403. Laura has left
  404. mh has joined
  405. antranigv has joined
  406. atomicwatch has joined
  407. spiral has left
  408. Apollo has left
  409. TheCoffeMaker has left
  410. TheCoffeMaker has joined
  411. spiral has joined
  412. iink has left
  413. iink has joined
  414. TheCoffeMaker has left
  415. thomaslewis has joined
  416. TheCoffeMaker has joined
  417. debacle has left
  418. techmetx11 has left
  419. thomaslewis has left
  420. techmetx11 has joined
  421. sonny has left
  422. TheCoffeMaker has left
  423. MattJ Okay, so instead of all the path query stuff: https://pad.nixnet.services/s/GPBR4xa4k
  424. MattJ Encode some rules directly into the server, handling all current use cases, allow for future extensibility if new ones arise
  425. Mx2 has left
  426. TheCoffeMaker has joined
  427. thomaslewis has joined
  428. thomaslewis has left
  429. Mx2 has joined
  430. thomaslewis has joined
  431. thomaslewis has left
  432. marc has left
  433. marc has joined
  434. PapaTutuWawa has joined
  435. thomaslewis has joined
  436. thomaslewis has left
  437. TheCoffeMaker has left
  438. mirux has left
  439. pep. "MattJ> Because you're going to email it, and I assume that won't be encrypted, so you don't have anything to hide from the push service" I want to challenge the reasoning about not having to hide from the push service if it's not encrypted :x
  440. pep. I mean, I don't find this as obvious
  441. larma has joined
  442. Wojtek has left
  443. mh has left
  444. mh has joined
  445. MattJ Read it as "you don't have anything that can be hidden"
  446. pep. from whom
  447. MattJ The push service
  448. xnamed has left
  449. pep. Well you may trust your server and the MTA but not the push service
  450. MattJ Okay. So what are you going to do about it?
  451. pep. I don't know, I'm just saying I don't find it as obvious as you made it sound
  452. MattJ Okay
  453. TheCoffeMaker has joined
  454. thomaslewis has joined
  455. thomaslewis has left
  456. pep. Text as sibling isn't valid in XMPP right? So you don't need to worry about it?
  457. MattJ I don't think anything actually forbids it, other than our collective common sense
  458. MattJ I meant to note that it would result in undefined behaviour
  459. pep. Good job for the spec :)
  460. MattJ I've been working with SASL2, and just wanted to see how much of this tangle of semi-related XEPs we could sort out at the same time
  461. mirux has joined
  462. Link Mauve Email actually has some deployed e2ee, namely OpenPGP and S/MIME.
  463. Link Mauve Both could be used also with a gateway.
  464. MattJ Link Mauve: someone else can have the fun of specifying and implementing that 🙂
  465. Link Mauve Yup.
  466. MattJ For the 5 users it will ve used by
  467. Link Mauve I’ve successfully avoided e2ee on XMPP altogether so far, hoping to keep under the radar. o:)
  468. MattJ For the 5 users it will be used by
  469. anubis has left
  470. jubalh has joined
  471. antranigv has left
  472. norayr has left
  473. inky has left
  474. inky has joined
  475. norayr has joined
  476. thomaslewis has joined
  477. antranigv has joined
  478. thomaslewis has left
  479. antranigv has left
  480. spiral has left
  481. antranigv has joined
  482. atomicwatch has left
  483. spiral has joined
  484. Apollo has joined
  485. Syndace has left
  486. Syndace has joined
  487. norayr has left
  488. norayr has joined
  489. antranigv has left
  490. Apollo has left
  491. Apollo has joined
  492. antranigv has joined
  493. antranigv has left
  494. antranigv has joined
  495. debacle has joined
  496. antranigv has left
  497. rubi has left
  498. rubi has joined
  499. atomicwatch has joined
  500. mirux has left
  501. mirux has joined
  502. rubi has left
  503. rubi has joined
  504. MSavoritias (fae,ve) has left
  505. MSavoritias (fae,ve) has joined
  506. Yagizа has left
  507. Yagizа has joined
  508. Mx2 has left
  509. thomaslewis has joined
  510. thomaslewis has left
  511. thomaslewis has joined
  512. Apollo has left
  513. thomaslewis has left
  514. Cthulhu has joined
  515. Apollo has joined
  516. thomaslewis has joined
  517. Mx2 has joined
  518. mirux has left
  519. mirux has joined
  520. thomaslewis has left
  521. Yagizа has left
  522. techmetx11 has left
  523. mathieui has left
  524. techmetx11 has joined
  525. techmetx11 has left
  526. techmetx11 has joined
  527. MSavoritias (fae,ve) has left
  528. moparisthebest has left
  529. xnamed has joined
  530. sonny has joined
  531. moparisthebest has joined
  532. spiral has left
  533. Kev has left
  534. thomaslewis has joined
  535. goffi has left
  536. thomaslewis has left
  537. PapaTutuWawa has left
  538. mirux has left
  539. Kev has joined
  540. Kev has left
  541. Schimon has left
  542. u has left
  543. marc0s has left
  544. Cthulhu has left
  545. al has joined
  546. marc0s has joined
  547. Kev has joined
  548. Laura has joined
  549. Mx2 has left
  550. SouL has left
  551. spiral has joined
  552. al has left
  553. Mx2 has joined
  554. Kev has left
  555. Kev has joined
  556. mathieui has joined
  557. Kev has left
  558. Kev has joined
  559. Schimon has joined
  560. xnamed has left
  561. Kev has left
  562. Kev has joined
  563. Mx2 has left
  564. Mx2 has joined
  565. selurvedu has joined
  566. selurvedu has left
  567. marc0s has left
  568. marc0s has joined
  569. Kev has left
  570. xnamed has joined
  571. Vaulor has left
  572. Vaulor has joined
  573. larma has left
  574. krit has left
  575. krit has joined
  576. xecks has left
  577. Kev has joined
  578. pulkomandy has left
  579. pulkomandy has joined
  580. thomaslewis has joined
  581. thomaslewis has left
  582. thomaslewis has joined
  583. thomaslewis has left
  584. Kev has left
  585. thomaslewis has joined
  586. Kev has joined
  587. thomaslewis has left
  588. debacle has left
  589. Schimon has left
  590. techmetx11 has left
  591. techmetx11 has joined
  592. Kev has left
  593. Kev has joined
  594. emus has left