XSF Discussion - 2020-03-09


  1. moparisthebest has left
  2. moparisthebest has joined
  3. mukt2 has left
  4. emus has left
  5. calvin has left
  6. neshtaxmpp has joined
  7. andy has left
  8. wurstsalat has left
  9. krauq has left
  10. krauq has joined
  11. neshtaxmpp has left
  12. arc has left
  13. arc has joined
  14. mukt2 has joined
  15. mukt2 has left
  16. debacle has left
  17. larma has left
  18. andrey.g has left
  19. larma has joined
  20. karoshi has left
  21. calvin has joined
  22. pdurbin has joined
  23. pdurbin has left
  24. mukt2 has joined
  25. arc has left
  26. arc has joined
  27. arc has left
  28. arc has joined
  29. adiaholic_ has joined
  30. adiaholic_ has left
  31. adiaholic_ has joined
  32. adiaholic_ has left
  33. adiaholic_ has joined
  34. mukt2 has left
  35. adiaholic_ has left
  36. adiaholic_ has joined
  37. arc has left
  38. arc has joined
  39. raghavgururajan has left
  40. raghavgururajan has joined
  41. neshtaxmpp has joined
  42. neshtaxmpp has left
  43. neshtaxmpp has joined
  44. eta has left
  45. mukt2 has joined
  46. adiaholic_ has left
  47. adiaholic_ has joined
  48. calvin has left
  49. andrey.g has joined
  50. mukt2 has left
  51. pdurbin has joined
  52. adiaholic_ has left
  53. adiaholic_ has joined
  54. andy has joined
  55. pdurbin has left
  56. mukt2 has joined
  57. DebXWoody has joined
  58. mukt2 has left
  59. rion has left
  60. rion has joined
  61. mukt2 has joined
  62. lorddavidiii has joined
  63. paul has joined
  64. Jeybe has joined
  65. Nekit has joined
  66. Yagiza has joined
  67. Tobias has joined
  68. emus has joined
  69. wurstsalat has joined
  70. Jeybe has left
  71. Jeybe has joined
  72. adiaholic_ has left
  73. adiaholic_ has joined
  74. mukt2 has left
  75. LNJ has joined
  76. arc has left
  77. arc has joined
  78. arc has left
  79. arc has joined
  80. Marc has joined
  81. eta has joined
  82. mukt2 has joined
  83. marc has joined
  84. marc has left
  85. Nekit has left
  86. marc has joined
  87. Yagiza has left
  88. Yagiza has joined
  89. mukt2 has left
  90. emus has left
  91. emus has joined
  92. karoshi has joined
  93. Jeybe has left
  94. Jeybe has joined
  95. waqas has left
  96. Steve Kille has joined
  97. mukt2 has joined
  98. mukt2 has left
  99. adiaholic_ has left
  100. emus has left
  101. adiaholic_ has joined
  102. goffi has joined
  103. Link Mauve has left
  104. mimi89999 has left
  105. mimi89999 has joined
  106. mukt2 has joined
  107. flow just to check if my memory serves me right: there is no way to query the xmpp server for pending in subscription requests after you have send the initial presence, right?
  108. mukt2 has left
  109. lorddavidiii has left
  110. lorddavidiii has joined
  111. debacle has joined
  112. Link Mauve has joined
  113. lorddavidiii has left
  114. Ge0rG flow: you could do a roster pull I suppose
  115. lorddavidiii has joined
  116. lorddavidiii has left
  117. flow Ge0rG, I don't think so
  118. lorddavidiii has joined
  119. flow as I believe I will only found the pending out subscription requests in the roster
  120. flow as I believe I will only find the pending out subscription requests in the roster
  121. Marc has left
  122. Marc has joined
  123. lorddavidiii has left
  124. lorddavidiii has joined
  125. Dele Olajide has joined
  126. Ge0rG I'm always struggling with corner cases of presence subscription management in multi-client situations, and each time I wonder whether it's a bug in my code, a bug in the other clients, a bug in the server or a bug in the spec
  127. lorddavidiii has left
  128. emus has joined
  129. lorddavidiii has joined
  130. lorddavidiii has left
  131. lorddavidiii has joined
  132. pdurbin has joined
  133. lorddavidiii has left
  134. lorddavidiii has joined
  135. lorddavidiii has left
  136. lorddavidiii has joined
  137. lorddavidiii has left
  138. lorddavidiii has joined
  139. lorddavidiii has left
  140. pdurbin has left
  141. Jeybe has left
  142. Jeybe has joined
  143. lorddavidiii has joined
  144. mukt2 has joined
  145. lorddavidiii has left
  146. lorddavidiii has joined
  147. lorddavidiii has left
  148. lorddavidiii has joined
  149. mukt2 has left
  150. lorddavidiii has left
  151. lorddavidiii has joined
  152. lorddavidiii has left
  153. sonny has left
  154. sonny has joined
  155. lorddavidiii has joined
  156. pdurbin has joined
  157. Daniel has left
  158. Daniel has joined
  159. pdurbin has left
  160. remko has joined
  161. remko has left
  162. remko has joined
  163. remko has left
  164. mimi89999 has left
  165. MattJ Ge0rG, FWIW there are almost certainly bugs in Prosody regarding subscription stuff (edge cases that don't 100% match the spec, or potentially stuff not covered by the spec)
  166. mimi89999 has joined
  167. MattJ But coming up with a test suite that covers everything is pretty hard, it's one of the things I wrote scansion for
  168. Ge0rG MattJ: my pet issues revolve around accepting / rejecting a request on device A and not seeing it on the simultaneously connected device B
  169. Ge0rG MattJ: not sure if you can scansion two parallel connections
  170. MattJ You can
  171. MattJ Most tests involve multiple connected clients
  172. Ge0rG MattJ: well then!
  173. Ge0rG Let me append that right to the end of your infinitely long TODO list.
  174. MattJ It's already on there, of course
  175. MattJ Being infinite
  176. jonas’ nobody said that the entries are unique, also I’m pretty sure you can have an infinitely long TODO list with only unique items without all possible entries occuring
  177. jonas’ for example, if your list consisted only of entries matching the regular expression a+
  178. debacle has left
  179. pdurbin has joined
  180. lskdjf has left
  181. lskdjf has joined
  182. Jeybe has left
  183. Jeybe has joined
  184. emus has left
  185. pdurbin has left
  186. emus has joined
  187. Daniel has left
  188. Daniel has joined
  189. Jeybe has left
  190. Jeybe has joined
  191. mukt2 has joined
  192. Shell has joined
  193. mukt2 has left
  194. flow To be fair, I don't think that this is an edge case and that it is actually not that bad that there is no method to query the server for pending in subscriptions, as it forces you to do the right thing™: setup a callback/listener/hook for pending in subscriptions, and after that, send the initial presence, handling the list of pending subscriptions client-side
  195. eevvoor has joined
  196. sonny has left
  197. lorddavidiii has left
  198. lorddavidiii has joined
  199. lorddavidiii has left
  200. goffi Hi, I'm implementing "max_items" node configuration in my pubsub component, but I don't see any standardisation in XEP-0060 (it's just present in examples)
  201. Daniel goffi: it's registered
  202. Daniel I think
  203. lorddavidiii has joined
  204. jonas’ for certain definitions of registered
  205. Daniel 16.4.4 pubsub#node_config
  206. Daniel > for certain definitions of registered Yes
  207. goffi Daniel: I see it's there: https://xmpp.org/registrar/formtypes.html, but still, it's unclear
  208. lorddavidiii has left
  209. goffi I have a few questions actually, mainly 2: 1) why using "max" which forces to use "text-single" for the field, instead of 0 or -1 for no max? Is there a legitimate reason to want a node with 0 for max items?
  210. lorddavidiii has joined
  211. goffi 2) what do to when a config is changed and max_items become smaller than the actual number of items? Delete all extra ones? If so, there is a risk to delete accidentaly items (I think this happened to Movim with microblogging, because some buggy clients where changing max_items to 1)
  212. Daniel Pubsub is only a cache anyway
  213. Daniel So implementations just have to deal with vanishing items
  214. MattJ goffi, the 'max' thing has been discussed here a few times
  215. goffi what? No
  216. goffi it's definitely not "just a cache"
  217. Daniel You should read the xep again
  218. MattJ We (Prosody) are not happy with it, because we have form validation and there is no existing data type that matches "usually a positive integer, sometimes a string"
  219. goffi Daniel: I don't see where the XEP says that
  220. goffi MattJ: the type is quite bad indeed
  221. goffi Daniel: may be you should read the xep again :-/
  222. pep. Daniel: no it's not just a cache. Maybe that's true of omemo, not pubsub
  223. lorddavidiii has left
  224. pep. (of the usage omemo does of pubsub, bot pubsub itself*)
  225. MattJ I certainly agree that pubsub is not just a cache
  226. pep. (of the usage omemo does of pubsub, not pubsub itself*)
  227. goffi I'll have to follow the thing and use text-single, but that's a really unfortunate choice.
  228. sonny has joined
  229. Daniel Can someone point me to normative language on how persistent items and Max items is supposed to work?
  230. lorddavidiii has joined
  231. goffi there is no normative for "max_items", that my point, it's only present in examples (and examples are not normative as far as I know)
  232. lorddavidiii has left
  233. MattJ Yeah, it's lacking
  234. goffi Actually, most of pubsub config is not normalized properly.
  235. Daniel The language I can find leads me to believe it is a fifo cache
  236. MattJ There is also inconsistency between ejabberd and Prosody I believe
  237. lorddavidiii has joined
  238. Daniel > Note: If the service or node is configured so that there is a maximum number of items cached at the node and the maximum is reached when an item is published, the service MUST delete one of the existing items. It is RECOMMENDED for the service to follow the "first in, first out" rule and delete the oldest item.
  239. Daniel So you don't get an error on publish
  240. Daniel It Transparently deletes the oldest
  241. sonny has left
  242. debacle has joined
  243. lorddavidiii has left
  244. lorddavidiii has joined
  245. goffi Daniel: that when max_items is set indeed, that the behaviour I would expect (I'm not happy with the "MAY" result in sending a delete notification though)
  246. goffi but my issue is when the config is changed, not on publication
  247. sonny has joined
  248. lorddavidiii has left
  249. goffi I think I'll not change the max_items and return an error if there are more items than the requested max_items, user will have to delete/purge manually before changing the settings. That's better than deleting items by accident.
  250. sonny has left
  251. lorddavidiii has joined
  252. Daniel Right. But what's the default value for max_items
  253. Daniel You say it's only a cache when max items is set
  254. goffi my server doesn't have max_items for now, so I'll set a default to "max".
  255. Daniel So how does it behave if it's not set
  256. goffi s/server/component/
  257. Daniel I can't find normative language in the xep that tells me that max_items is by default unset or 'max'
  258. lorddavidiii has left
  259. Daniel Therefor I conclude it's a cache by default
  260. sonny has joined
  261. Daniel Even if your implementation isn't
  262. goffi There is no normative language for max_items at all
  263. goffi that's one of the main issue with pubsub, it's not normalised enough and implementation differs on this kind of important points.
  264. Daniel Note that I don't want it to be a cache
  265. lorddavidiii has joined
  266. Daniel But I think there is a reading of the xep that leads you to believe it is
  267. APach has left
  268. goffi Daniel: I think we agree on the behaviour of "max_items", but I disagree when you said previously "implementations just have to deal with vanishing items"
  269. Daniel Also I think that prosody for example does in fact have a limit
  270. Daniel Which if it them adheres to the rest of the xep makes it a cache
  271. goffi Daniel: I have implemented many features on top of pubsub (blog, tickets, merge requests, etc), and it's clearly not an option that items are randomly disappearing.
  272. Daniel Maybe a large cache of 1000 of whatever the limit is in prosody
  273. Daniel goffi: I agree. But don't blame the messanger
  274. goffi Daniel: the config has to be checked (either with publish-options or by getting the config) by the client anyway, max_items need to be set by the client IMHO, we can't rely on supposed default behaviour.
  275. lorddavidiii has left
  276. goffi Daniel: I'm not blaming you ;)
  277. Daniel Yes the max items has to be set. Especially for pubsub on the account
  278. Daniel Where the default is 1
  279. goffi anyway thanks all for the feedbacks, I have my answers :)
  280. pep. Time to PR pubsub? :p
  281. goffi pep.: yep, I can do that but I don't know when
  282. raghavgururajan has left
  283. goffi I have a bunch of work on XEPs accumating in my TODO list, I guess I'll have to block a couple of days for that.
  284. pep. goffi, I guess even just mentioning that in the wiki or something would be great already. We have a page for pubsub I guess?
  285. adiaholic_ has left
  286. adiaholic_ has joined
  287. lorddavidiii has joined
  288. pep. (without looking for normative language right away)
  289. pep. https://wiki.xmpp.org/web/XEP-Remarks/XEP-0060:_PubSub
  290. Daniel The thing is that even when a client sets it to max, it's still a cache
  291. Daniel Because Max is not defined as unlimited but as what ever the server internally has as a limit
  292. pep. It's not a "cache" then, we just need to make it obvious on publish that there's not space or sth :/
  293. Daniel So you have to change the normative section I quoted earlier
  294. MattJ Yeah, I think there should be a way to specify the behaviour
  295. pep. yeah
  296. pep. I don't think I like the "When a new item gets published, delete whatever" part
  297. MattJ I don't want to change it - the current behaviour is often desired (though I agree "delete whatever" needs to be less vague)
  298. Daniel > It's not a "cache" then, we just need to make it obvious on publish that there's not space or sth :/ I agree that this is where we want to end up. But agreeing on that doesn't mean that it's already the case
  299. MattJ A related issue is when you publish an item with the same id as an existing item
  300. raghavgururajan has joined
  301. pep. I don't think deleting an item on publish is good for anything that goffi mentioned. blog, bug tracker, etc.
  302. pep. "Yo I published a comment and your article disappeared"
  303. pep. (might not happened because these two would probably be on different nodes, but fun nonetheless)
  304. Daniel Yes or bookmarks
  305. pep. yes
  306. pep. "I don't understand, whenever I'm joining a new groupchat, I'm leaving another" :p
  307. Daniel There is a discrepancy between what pubsub says and who we want to use it
  308. Zash Singleton node, FIFO of size n, fixed-size (conflict on publish if limit is reached)
  309. Zash I guess much of this comes from Pubsub being too generic to be usefuly without additional logic
  310. lorddavidiii has left
  311. goffi MattJ: what is the issue with publishing on the same id as existing item? I belived the XEP explicitely says somewhere that it's then overwritting.
  312. Zash I thought that this was the same as removing that item and publishing a new one.
  313. xelxebar has left
  314. xelxebar has joined
  315. MattJ goffi, I'm not aware of such text
  316. MattJ Ah, it does use the word "overwrite"
  317. MattJ It's in 7.1.3 Error Cases: https://xmpp.org/extensions/xep-0060.html#publisher-publish-error
  318. Shell has left
  319. lorddavidiii has joined
  320. lorddavidiii has left
  321. APach has joined
  322. calvin has joined
  323. lorddavidiii has joined
  324. lorddavidiii has left
  325. lorddavidiii has joined
  326. lorddavidiii has left
  327. lorddavidiii has joined
  328. adiaholic_ has left
  329. adiaholic_ has joined
  330. pdurbin has joined
  331. lorddavidiii has left
  332. lorddavidiii has joined
  333. lorddavidiii has left
  334. lorddavidiii has joined
  335. lorddavidiii has left
  336. lorddavidiii has joined
  337. lorddavidiii has left
  338. lorddavidiii has joined
  339. lorddavidiii has left
  340. adiaholic_ has left
  341. adiaholic_ has joined
  342. lorddavidiii has joined
  343. pdurbin has left
  344. lorddavidiii has left
  345. lorddavidiii has joined
  346. andrey.g has left
  347. lorddavidiii has left
  348. lorddavidiii has joined
  349. lorddavidiii has left
  350. lorddavidiii has joined
  351. adiaholic_ has left
  352. adiaholic_ has joined
  353. lorddavidiii has left
  354. lorddavidiii has joined
  355. debacle has left
  356. lorddavidiii has left
  357. lorddavidiii has joined
  358. eevvoor has left
  359. goffi MattJ: It's even in success case: https://xmpp.org/extensions/xep-0060.html#publisher-publish-success (the note under the example)
  360. lorddavidiii has left
  361. waqas has joined
  362. Wojtek has joined
  363. adiaholic_ has left
  364. lorddavidiii has joined
  365. adiaholic_ has joined
  366. Daniel has left
  367. Daniel has joined
  368. debacle has joined
  369. adiaholic_ has left
  370. adiaholic_ has joined
  371. debacle has left
  372. adiaholic_ has left
  373. adiaholic_ has joined
  374. krauq has left
  375. krauq has joined
  376. Nekit has joined
  377. marc has left
  378. marc has joined
  379. andrey.g has joined
  380. debacle has joined
  381. Yagiza has left
  382. test has joined
  383. test has left
  384. marc has left
  385. APach has left
  386. APach has joined
  387. pdurbin has joined
  388. eta has left
  389. arc has left
  390. arc has joined
  391. pdurbin has left
  392. eta has joined
  393. lovetox has joined
  394. Dele Olajide has left
  395. Dele Olajide has joined
  396. Wojtek has left
  397. j.r has left
  398. j.r has joined
  399. Wojtek has joined
  400. calvin has left
  401. calvin has joined
  402. arc has left
  403. arc has joined
  404. Daniel has left
  405. Daniel has joined
  406. APach has left
  407. adiaholic_ has left
  408. adiaholic_ has joined
  409. APach has joined
  410. Daniel has left
  411. Daniel has joined
  412. debacle has left
  413. Daniel has left
  414. Daniel has joined
  415. marc has joined
  416. Yagiza has joined
  417. APach has left
  418. APach has joined
  419. LNJ has left
  420. pdurbin has joined
  421. marc has left
  422. marc has joined
  423. LNJ has joined
  424. Daniel has left
  425. Daniel has joined
  426. adiaholic_ has left
  427. adiaholic_ has joined
  428. arc has left
  429. arc has joined
  430. adiaholic_ has left
  431. adiaholic_ has joined
  432. Steve Kille has left
  433. Marc has left
  434. Marc has joined
  435. Marc has left
  436. Marc has joined
  437. mukt2 has joined
  438. pdurbin has left
  439. Steve Kille has joined
  440. Daniel has left
  441. Daniel has joined
  442. mukt2 has left
  443. arc has left
  444. arc has joined
  445. adiaholic_ has left
  446. Yagiza has left
  447. marc has left
  448. calvin has left
  449. Jeybe has left
  450. Jeybe has joined
  451. mukt2 has joined
  452. mukt2 has left
  453. j.r has left
  454. j.r has joined
  455. Maranda has left
  456. Maranda has joined
  457. lorddavidiii has left
  458. pdurbin has joined
  459. lorddavidiii has joined
  460. pdurbin has left
  461. qwer has joined
  462. qwer has left
  463. mukt2 has joined
  464. mukt2 has left
  465. eevvoor has joined
  466. DebXWoody has left
  467. lorddavidiii has left
  468. lovetox has left
  469. eevvoor has left
  470. Tobias has left
  471. LNJ has left
  472. DebXWoody has joined
  473. DebXWoody has left
  474. calvin has joined
  475. DebXWoody has joined
  476. mukt2 has joined
  477. j.r has left
  478. j.r has joined
  479. DebXWoody has left
  480. raghavgururajan has left
  481. david has left
  482. david has joined
  483. mukt2 has left
  484. marc has joined
  485. calvin has left
  486. Wojtek has left
  487. Wojtek has joined
  488. Wojtek has left
  489. Jeybe has left
  490. calvin has joined
  491. Guus has left
  492. Guus has joined
  493. emus has left
  494. emus has joined
  495. marc has left
  496. rion has left
  497. raghavgururajan has joined
  498. Max has left
  499. Max has joined
  500. mukt2 has joined
  501. mukt2 has left
  502. raghavgururajan has left
  503. raghavgururajan has joined
  504. Wojtek has joined
  505. raghavgururajan has left
  506. raghavgururajan has joined
  507. Kev has joined
  508. Kev has left
  509. Wojtek has left
  510. goffi has left
  511. paul has left
  512. calvin has left
  513. raghavgururajan has left
  514. Max has left
  515. Daniel has left
  516. Max has joined
  517. mukt2 has joined
  518. emus has left
  519. Daniel has joined
  520. mukt2 has left
  521. adiaholic_ has joined
  522. debacle has joined
  523. calvin has joined