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


  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


  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


  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


  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


  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


  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


  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


  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