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