XSF logo XSF Discussion - 2019-08-02


  1. waqas has joined
  2. zach has left
  3. zach has joined
  4. Chobbes has left
  5. Nekit has left
  6. Chobbes has joined
  7. LNJ has left
  8. LNJ has joined
  9. peter has joined
  10. stpeter has joined
  11. debacle has left
  12. Chobbes has left
  13. zach has left
  14. zach has joined
  15. pdurbin has joined
  16. pdurbin has left
  17. peter has left
  18. xnamed Hi, I am new here, I would like to suggest an idea, I'm thinking about collaborative editor in XMPP for some reasons We have some stuff already in XMPP could use for it:   • XHTML-IM ( https://xmpp.org/extensions/xep-0071.html )   • XMPP E2E Security ( https://wiki.xmpp.org/web/XMPP_E2E_Security )   • Publish-Subscribe ( https://xmpp.org/extensions/xep-0060.html )   • Bookmarks ( https://xmpp.org/extensions/xep-0048.html )   • Multi-User Chat ( https://xmpp.org/extensions/xep-0045.html )   • and maybe other XEPs I didn't learned yet!
 What do we need:   • Shows cursors and selections of remote users   • Show the others having joined the session and something like Chat State Notifications ( https://xmpp.org/extensions/xep-0085.html ) and Chat Markers ( https://xmpp.org/extensions/xep-0333.html ) XEPs   • Syntax highlighting   • That's all I have for now

Maybe the idea is old or something I don't know, I'm just telling my thoughts!
  19. stpeter has left
  20. wurstsalat has left
  21. Zash There's https://xmpp.org/extensions/xep-0284.html
  22. lumi has left
  23. xnamed well, looks good, I will try with it
  24. stpeter has joined
  25. peter has joined
  26. neshtaxmpp has left
  27. neshtaxmpp has joined
  28. zach has left
  29. zach has joined
  30. lskdjf has left
  31. waqas has left
  32. adityaborikar has joined
  33. adityaborikar has left
  34. adityaborikar has joined
  35. waqas has joined
  36. peter has left
  37. adityaborikar has left
  38. stpeter has left
  39. andy has joined
  40. Yagiza has joined
  41. zach has left
  42. zach has joined
  43. adityaborikar has joined
  44. LNJ has left
  45. adityaborikar has left
  46. adityaborikar has joined
  47. LNJ has joined
  48. patrick has left
  49. karoshi has joined
  50. jcbrand has joined
  51. zach has left
  52. zach has joined
  53. pdurbin has joined
  54. adityaborikar has left
  55. adityaborikar has joined
  56. xnamed has left
  57. sezuan has joined
  58. adityaborikar has left
  59. Lance has joined
  60. Yagiza has left
  61. Yagiza has joined
  62. sezuan has left
  63. sezuan has joined
  64. murabito has left
  65. murabito has joined
  66. Lance has left
  67. sezuan has left
  68. adityaborikar has joined
  69. Lance has joined
  70. murabito has left
  71. zach has left
  72. zach has joined
  73. murabito has joined
  74. murabito has left
  75. murabito has joined
  76. jubalh has joined
  77. murabito has left
  78. murabito has joined
  79. LNJ has left
  80. LNJ has joined
  81. murabito has left
  82. murabito has joined
  83. murabito has left
  84. murabito has joined
  85. zach has left
  86. zach has joined
  87. Douglas Terabyte has left
  88. adityaborikar has left
  89. Mikaela has joined
  90. murabito has left
  91. murabito has joined
  92. Lance has left
  93. zach has left
  94. zach has joined
  95. adityaborikar has joined
  96. larma has left
  97. wurstsalat has joined
  98. marc_ has joined
  99. lovetox has joined
  100. lovetox pep., Ge0rG does that proposal for adding a feature under a feature break entity caps?
  101. Zash Yup. And probably the schema to.
  102. waqas has left
  103. larma has joined
  104. valo has left
  105. Ge0rG I still think it's less wrong than putting all combination os sub-features into individual feature var strings.
  106. sezuan has joined
  107. jonas’ except that it breaks all the things
  108. zach has left
  109. zach has joined
  110. valo has joined
  111. Ge0rG create a new feature tag that's recursive
  112. Zash And caps3
  113. Ge0rG caps3.11
  114. Ge0rG caps for workgroups
  115. jonas’ '390 is still experimental
  116. jonas’ so that’s the least of worries
  117. marc_ has left
  118. Lance has joined
  119. pep. Is ecaps2 implemented at all in clients? I know it's in xmpp-parsers, and I know there's a prosody module to convert to escaps2, but that's about it?
  120. lovetox could it not be named, "pubsub:order-by" ?
  121. pep. lovetox, that's the second proposal
  122. pep. But it's ugly
  123. lovetox why though? it breaks nothing
  124. jonas’ pep., aioxmpp has an implementation, obviously
  125. lovetox and nobody looks everyday at xml streams, so i dont really care if its ugly
  126. pep. lovetox, yeah as I said in the mail
  127. pep. I was mostly curious if there were prettier alternatives
  128. pep. Or smarter ones
  129. pep. jonas’, right
  130. jonas’ XEP-0128 forms!!kk
  131. jonas’ actually...
  132. lovetox yeah that was my next bet
  133. pep. actually..
  134. lovetox you have to disco info the pubsub service itself anyway
  135. lovetox so it can announce all features inside its extended form
  136. lovetox like httpupload does
  137. lovetox with max-size etc
  138. pep. or pubsub nodes, or .. muc? :)
  139. lovetox its still bit of a hack
  140. ralphm Well, forms are for config. I think the way we would have done this is per-subprotocol features. It is a bit untortunate. Nested features would not work correctly with CAPS.
  141. pep. Then you can do disco#items on muc with order-by and rsm, imagine the possibilities!!1!
  142. jonas’ nested features would break any schema-validating parser
  143. jonas’ although I’d like to get written down somewhere that unknown elements and attributes MUST be ignored, unless they carry an attribute {urn:xmpp}critical="true" :>
  144. jonas’ in which case you have to run in circles screaming full of terror
  145. marc_ has joined
  146. ralphm One other possibility is querying a node that is the 'main' subprotocol namespace and adding the rsm feature on that
  147. jonas’ ralphm, but the roundtrips
  148. Zash Oh right, disco and nodes.
  149. jonas’ (and it doesn’t work with caps either)
  150. ralphm I didn't say is was pretty
  151. lovetox i would just add a field var=feature to the extended form
  152. lovetox and list all features there
  153. lovetox prettier in my opinion
  154. jonas’ ralphm, also, what if I create a pubsub node named like a feature (very common in PEP)
  155. Zash jonas’, hush
  156. ralphm Yeah
  157. Ge0rG jonas’: obviously, this must be forbidden by the protocol!
  158. Zash Wasn't there some overlaps like this already?
  159. ralphm I think for now just having a new pubsub feature and a new disco feature suffices
  160. ralphm If there only a handful of combinations, we don't have to overengineer
  161. pep. Should we also update pubsub to create pubsub#with-rsm btw? To fix the current thing that's broken
  162. pep. "broken"
  163. ralphm Yes
  164. ralphm That was my suggestion
  165. lovetox yeah pubsub has already endless feautres, just add pubsub#rsm and be done with
  166. ralphm Backwards compatible, too
  167. ralphm Old clients will see the rsm feature and will try
  168. pep. I'm curious though who mandates to add RSM in disco
  169. pep. RSM itself?
  170. ralphm Not really
  171. ralphm Rsm for disco isn't defined
  172. pep. Not that
  173. ralphm Or at least not explicitly
  174. Zash disco#items?
  175. pep. ralphm, you misunderstood
  176. pep. What says currently, "if you do rsm with pubsub, add rsm in disco#info"
  177. pep. Because I'd want to remove that when introducing pubsub#rsm
  178. ralphm Nothing?
  179. ralphm Maybe instead, if you want RSM on disco items, we need to expose a feature, and update XEP-0030
  180. Lance has left
  181. pep. update XEP-0030 !!1! /me runs wavings arms in the air
  182. pep. Am I going to get punished for daring to update a Final XEP?
  183. ralphm Or a new XEP
  184. pep. :(
  185. Zash pep., the elders will come down from the temple and whack ye upon thy fingers
  186. ralphm Zash: like who?
  187. Zash Dunno
  188. marc_ has left
  189. pdurbin has left
  190. pdurbin has joined
  191. Nekit has joined
  192. zach has left
  193. zach has joined
  194. pep. https://xmpp.org/extensions/xep-0059.html#support how can I, without breaking it, say "don't do it anymore" :)
  195. pep. heh, there are mentions already of the issue in this paragraph
  196. pep. Maybe that could have been sorted out at this time
  197. murabito has left
  198. murabito has joined
  199. goffi has joined
  200. adityaborikar has left
  201. adityaborikar has joined
  202. adityaborikar has left
  203. adityaborikar has joined
  204. murabito has left
  205. murabito has joined
  206. zach has left
  207. zach has joined
  208. debacle has joined
  209. xnamed has joined
  210. murabito has left
  211. murabito has joined
  212. pdurbin has left
  213. goffi has left
  214. xnamed has left
  215. xnamed has joined
  216. pdurbin has joined
  217. lskdjf has joined
  218. UsL has joined
  219. marc_ has joined
  220. jubalh has left
  221. sonny has joined
  222. sonny has left
  223. zach has left
  224. zach has joined
  225. sonny has joined
  226. pdurbin has left
  227. pdurbin has joined
  228. debacle has left
  229. karoshi has left
  230. karoshi has joined
  231. rion has left
  232. rion has joined
  233. debacle has joined
  234. xnamed has left
  235. xnamed has joined
  236. jubalh has joined
  237. xnamed few years ago jabber.ru was supporting XEP MUC-Filter which is not exist on xmpp.org and it was working very well with Isida-bot ( http://isida.dsy.name/wiki/en:Index ) and added later to other bots I have unofficial mod_muc with muc-filter support, working on ejabberd-2.1.13 and previous versions the module was not published by Ejabberd, I think it was monopolized by jabber.ru, I know many who wanted to get it but when they asked about it, the answers is like something that did not exist There is short description about the XEP here ( https://github.com/xnamed/isida4/wiki/muc-filter#principle-of-operation ) A list of bot filters that it can do here ( https://github.com/xnamed/isida4/wiki/muc-filter#configuring-the-bot ) If anyone is interested about that, if the description not enough I will send the module if necessary, I can explain it if you don't know erlang and I think it could be implemented the same way on Prosody One of the good things about this feature, users can choose filters in each room, no need to write filters for the server for everything For some time I thought there is no need for it, but there are still some kids, It was very annoying to me when one of my friends room got spammed, more than 1000 messages, then I get them all on my other devices because of XEP MAM :)
  238. zach has left
  239. zach has joined
  240. afrogeek has left
  241. Guus xnamed: I'd be happy to add that to Openfire
  242. xnamed I'm happy to hear it Guus
  243. jonas’ I didn’t understand the documentation
  244. Guus jonas’ it's not overly clear, but the generic principle appears to be: don't broadcast stanzas that are sent to a MUC. Instead, forward it to a JID. Only if that JID gives an 'ok', broadcast the original stanza.
  245. jonas’ ah. hm.
  246. Kev So that's very similar to what we discussed at the Summit, about having an external spam-checker service that would give yay/nay verdicts on stanzas.
  247. Kev If I'm understanding correctly.
  248. Zash Who was it that made a thing for that?
  249. zach has left
  250. Zash Or, what it called?
  251. zach has joined
  252. Zash Providence?
  253. Zash Seems to have dissapeared into a black hole.
  254. pep. The thing valerian did? (the jappix author)
  255. Zash Yes
  256. pep. https://journal.valeriansaliou.name/announcing-providence-a-spam-filter-for-xmpp/ it's disappeared though :(
  257. edhelas has left
  258. xnamed at least it can be choice for who like to use it, and it is not only about spamming, censoring, option for each participant to block private messages with someone and other things
  259. edhelas has joined
  260. Kev Oh, it's per-occupant? I missed that bit. That's fun.
  261. jonas’ I imagine pain down that road with MUC MAM
  262. xnamed yes
  263. Kev jonas’: Yes.
  264. jonas’ a world of pain
  265. andrey.g has left
  266. goffi has joined
  267. pep. https://xmpp.org/extensions/xep-0004.html#final-changes we don't seem to add this kind of changelogs anymore do we?
  268. jonas’ presumably you would find those in the normal version log
  269. Yagiza has left
  270. pep. So I've got a diff for pubsub/rsm SHOULD-ing a new feature in disco#info of the entity. Now I'm looking at RSM and Order-by and I want to remove the "Determining Support" part, because it doesn't make sense on its own, but that would mean removing SHOULDs or MUSTs (or MUST NOT)
  271. jonas’ pep., propose the diff
  272. jonas’ council will figure out a way
  273. pep. k
  274. jonas’ IMO it should be OK to remove that (IIRC) because the information is useless to a peer anyways
  275. pep. Indeed
  276. pep. Any other XEPs one can think of that should also be amended?
  277. pep. Generic stuff? 0004?
  278. jonas’ '4 has nothing to do with RSM, does it?
  279. pep. it doesn't, but it's generic like rsm and doesn't mean much as is, does it?
  280. jonas’ it does
  281. jonas’ people do send forms directly via messages
  282. pep. Though, TIL <message> can contain <x xmlns="jabber:x:data"/>. Not clue what that means
  283. jonas’ and clients which support displaying and handling that would... exactly
  284. jonas’ ... expose that feature
  285. sonny has left
  286. jubalh has left
  287. pep. I was also reminded of jabber:x:search, that can use forms, rsm, etc. So we'd need to add new disco features on every single spec that can use any of these :/
  288. jonas’ yes
  289. jonas’ except if the spec requires it frmo the start
  290. pep. yeah
  291. jonas’ like muclumbus-search
  292. pep. muclumbus-search will be superseeded by disco#items+rsm+order-by at some point :P
  293. Nekit has left
  294. pep. jonas’, or like MAM
  295. pep. Though everybody includes it..
  296. jonas’ pep., I miss +filter-by-name/address/description in that enumeration
  297. Nekit has joined
  298. Link Mauve xnamed, I once wrote https://hg.linkmauve.fr/eldonilo/barbecue/ as an implementation of XEP-0284 for the web, I don’t maintain it anymore and the library it’s build upon is dead too, but you may find some inspiration in there. It’s targetting wysiwyg more than plain text, and doesn’t have syntax highlighting or cursors/selections, but that could be added to 0284.
  299. pep. order-by and rsm are sufficient. You "just" need to add a "name"/"address"/"description" filter?
  300. pep. the @by
  301. jonas’ pep., and then a thing which returns all the info at once instead of having to disco#info each individual result returned by disco#items
  302. jonas’ pep., disco#items does not support filtering so far
  303. pep. Sure, what I just said
  304. pep. We were looking at adding order-by for disco#items with edhelas
  305. jonas’ seems reasonable
  306. pep. Maybe you want a filter-by as well, but order-by + rsm should be enough for now? (put relevant items first, ignore the rest)
  307. jonas’ and once you start with filter-by, you’ll want to write down how that filtering works, which will be its own mess. there’s a reason it’s underspecified in muclumbus at the moment
  308. jonas’ (it boils down to "whatever postgres does")
  309. pep. yeah..
  310. Zash SQL over XMPP?
  311. pep. Specifying order-by on disco#items of a MUC service is already fun :(
  312. pep. There's only 'creation' and 'modification' filters atm
  313. pep. "What does that even mean on MUC"
  314. jonas’ pep., nothing useful
  315. Zash What does it mean in PubSub?
  316. pep. Zash, that's defined in the XEP
  317. edhelas well to me 'creation' should be enough for MUC disco#items
  318. edhelas Zash please add support for https://xmpp.org/extensions/xep-0043.html
  319. Zash How about no
  320. MattJ You're holding back XMPP from world domination
  321. sonny has joined
  322. Guus Yes it's all your fault.
  323. edhelas Prosody is always holding back XMPP, look at ejabberd, they supports 0043 for years
  324. xnamed Link Mauve, I will see
  325. Guus Does SQL-Injection count, btw?
  326. Yagiza has joined
  327. xnamed just added the module on Github, mod_muc ( https://github.com/xnamed/mod_muc )
Guus, Kev,
  328. Zash So in conclusion, I killed XMPP. Finally the world is ready for my real evil plan, ZMPP!
  329. Nekit has left
  330. Nekit has joined
  331. Guus (how do you pronounce that?)
  332. Zash No talk, only chat!
  333. mimi89999 has left
  334. Yagiza has left
  335. Yagiza has joined
  336. karoshi has left
  337. karoshi has joined
  338. jonas’ > Retracted edhelas, are you serious?
  339. goffi has left
  340. goffi has joined
  341. zach has left
  342. zach has joined
  343. adityaborikar has left
  344. adityaborikar has joined
  345. edhelas It's 100% real news, I heard it on FoxNews
  346. adityaborikar has left
  347. adityaborikar has joined
  348. xnamed Zash, what about XNPP?
  349. alameyo has left
  350. alameyo has joined
  351. xnamed Link Mauve, I found a collaborative editor project on github written in C++ so I think it possible to get some information from it, but we will not implement XEP-0284 on the client as long as it's deferred
  352. Link Mauve xnamed, it won’t go back to experimental without feedback from implementors.
  353. xnamed ok
  354. Link Mauve “09:31:46 pep.> Am I going to get punished for daring to update a Final XEP?”, XEP-0030 already got updated in a very incompatible way in the weirdly-named 2.5rc3 version.
  355. Link Mauve A valid parser from rc2 and before could choke on disco#info produced by rc3.
  356. Link Mauve The one in xmpp-parsers had to be updated to remove the explicit ordering restriction.
  357. lumi has joined
  358. pep. So maybe we could update disco and caps at the same time and break the world :)
  359. Link Mauve Please don’t.
  360. Chobbes has joined
  361. Chobbes has left
  362. Chobbes has joined
  363. Link Mauve xnamed, which project is that, btw?
  364. xnamed Link Mauve, https://github.com/gobby/gobby
  365. goffi has left
  366. Link Mauve Ah, I know this one, but it’s using a totally different protocol atm.
  367. xnamed yes I know
  368. xnamed but same idea
  369. jubalh has joined
  370. jubalh has left
  371. Chobbes has left
  372. stpeter has joined
  373. peter has joined
  374. peter has left
  375. jubalh has joined
  376. adityaborikar has left
  377. adityaborikar has joined
  378. edhelas has left
  379. edhelas has joined
  380. edhelas has left
  381. stpeter has left
  382. edhelas has joined
  383. edhelas has left
  384. edhelas has joined
  385. Nekit has left
  386. Lance has joined
  387. sonny has left
  388. pdurbin has left
  389. mimi89999 has joined
  390. adityaborikar has left
  391. xnamed who are the the XEP-0284: Shared XML Editing authors here?   • Joonas Govenius    • Peter Saint-Andre    • Tom Pusateri
 so we could discuss it with them first
  392. adityaborikar has joined
  393. pep. xnamed, peter is on this chan often enough. I suggest you ask your questions on the standards mailing list though
  394. stpeter has joined
  395. xnamed thanks pep.
  396. adityaborikar has left
  397. mimi89999 has left
  398. zach has left
  399. zach has joined
  400. mimi89999 has joined
  401. Chobbes has joined
  402. Chobbes has left
  403. Chobbes has joined
  404. sonny has joined
  405. stpeter has left
  406. adityaborikar has joined
  407. sonny has left
  408. sonny has joined
  409. adityaborikar has left
  410. ziggys has joined
  411. jubalh has left
  412. Lance has left
  413. Mikaela has left
  414. Mikaela has joined
  415. sezuan has left
  416. adityaborikar has joined
  417. adityaborikar has left
  418. adityaborikar has joined
  419. Lance has joined
  420. sonny has left
  421. patrick has joined
  422. COM8 has joined
  423. xnamed has left
  424. xnamed has joined
  425. sonny has joined
  426. COM8 has left
  427. waqas has joined
  428. goffi has joined
  429. ziggys has left
  430. stpeter has joined
  431. peter has joined
  432. ziggys has joined
  433. sonny has left
  434. marc_ has left
  435. jonas’ does anyone know what `tc` is, as an XMPP server-side software/component?
  436. peter has left
  437. peter has joined
  438. adityaborikar has left
  439. zach has left
  440. marc_ has joined
  441. peter I always kind of liked Shared XML Editing but I suppose it was too complex.
  442. Link Mauve I quite liked implementing it.
  443. Link Mauve Damn, that was in 2012.
  444. xnamed we will not focus on it immediately, it was an idea I did not think the XEP was existed
  445. adityaborikar has joined
  446. sonny has joined
  447. xnamed What about OMEMO support in groupchat as gajim-plugin ( https://dev.gajim.org/gajim/gajim-plugins/wikis/omemogajimplugin#groupchat ) and Conversations?
Groupchat with OMEMO encryption works only in rooms that are:   • non-anonymous   • members-only   • works only with contacts that you have in your roster
  448. adityaborikar has left
  449. adityaborikar has joined
  450. ziggys has left
  451. Chobbes has left
  452. Chobbes has joined
  453. goffi has left
  454. Lance has left
  455. Douglas Terabyte has joined
  456. ziggys has joined
  457. marc_ has left
  458. peter has left
  459. rion has left
  460. rion has joined
  461. kokonoe has left
  462. kokonoe has joined
  463. sezuan has joined
  464. goffi has joined
  465. goffi has left
  466. goffi has joined
  467. stpeter has left
  468. sonny Link Mauve, remember https://github.com/fabi1cazenave/sxedit 😀 ?
  469. pep. https://github.com/fabi1cazenave/sxedit/commit/a99facfa291f22d32ae893a4ca505a7a7027270a "Fait tomber en marche.", Some part of France is currently at it :-°
  470. sonny crap, where is my right to be forgotten when I need it
  471. pep. haha
  472. sonny IIRC SXE/sxedit worked really well and editing nodes instead of characters made collaboration much easier as we would "lock" the nodes that were being edited
  473. adityaborikar has left
  474. murabito has left
  475. murabito has joined
  476. goffi has left
  477. adityaborikar has joined
  478. ziggys has left
  479. adityaborikar has left
  480. adityaborikar has joined
  481. sezuan has left
  482. andrey.g has joined
  483. peter has joined
  484. stpeter has joined
  485. mr.fister has joined
  486. sezuan has joined
  487. ziggys has joined
  488. sezuan has left
  489. sezuan has joined
  490. sezuan has left
  491. sezuan has joined
  492. Chobbes has left
  493. Chobbes has joined
  494. igoose has left
  495. igoose has joined
  496. sezuan has left
  497. sezuan has joined
  498. sezuan has left
  499. sezuan has joined
  500. sezuan has left
  501. sezuan has joined
  502. sezuan has left
  503. Chobbes has left
  504. Chobbes has joined
  505. Yagiza has left
  506. jubalh has joined
  507. murabito has left
  508. murabito has joined
  509. Chobbes has left
  510. adityaborikar has left
  511. Link Mauve sonny, yup. ^^
  512. Chobbes has joined
  513. Chobbes has left
  514. Chobbes has joined
  515. Lance has joined
  516. jubalh has left
  517. goffi has joined
  518. pdurbin has joined
  519. sonny has left
  520. ziggys has left
  521. sonny has joined
  522. pdurbin has left
  523. ziggys has joined
  524. waqas has left
  525. ziggys has left
  526. ziggys has joined
  527. ziggys has left
  528. ziggys has joined
  529. ziggys has left
  530. ziggys has joined
  531. ziggys has left
  532. ziggys has joined
  533. COM8 has joined
  534. ziggys has left
  535. COM8 has left
  536. zach has joined
  537. valo has left
  538. valo has joined
  539. ziggys has joined
  540. ziggys has left
  541. ziggys has joined
  542. ziggys has left
  543. ziggys has joined
  544. ziggys has left
  545. ziggys has joined
  546. ziggys has left
  547. ziggys has joined
  548. rion has left
  549. rion has joined
  550. COM8 has joined
  551. COM8 has left
  552. Nekit has joined
  553. debacle has left
  554. peter has left
  555. wojtek has joined
  556. marc_ has joined
  557. sezuan has joined
  558. alameyo has left
  559. Guus has left
  560. zach has left
  561. zach has joined
  562. Guus has joined
  563. alameyo has joined
  564. jubalh has joined
  565. stpeter has left
  566. alameyo has left
  567. alameyo has joined
  568. pep. https://xmpp.org/extensions/xep-0059.html#forwards, I'm not sure I understand the following: Responding entity support for paging through a result set is optional. If it does support paging (not just Limiting the Number of Items), then in each page it returns, the responding entity MUST include <first/> and <last/> elements that specify the unique ID (UID) for the first and last items in the page. If there is only one item in the page, then the first and last UIDs MUST be the same. If there are no items in the page, then the <first/> and <last/> elements MUST NOT be included.
  569. zach has left
  570. zach has joined
  571. pep. "paging" only means a subset of RSM right?
  572. pep. hmm, I guess I'll come back to that once I've read <first/> and <last/>
  573. Ge0rG I wonder what good RSM is for if you take away pagination.
  574. pep. I'm also curious
  575. pep. Maybe you can just get the first N items and be happy with that
  576. pdurbin has joined
  577. Ge0rG Like in matrix
  578. sezuan has left
  579. pdurbin has left
  580. xnamed has left
  581. xnamed has joined
  582. Zash pep.: wat
  583. Zash Oh, I thought I saw a "NOT" in "the first and last UIDs MUST be the same"
  584. pep. Also I am definitely not sure how to picture this: No items will be omitted from pages not yet sent (even if, after earlier pages were sent, some of the items they contained were removed from the set).
  585. pep. 2.2, the paging features
  586. pep. Does that mean when the server gets a request, it should store a reference of all items contained in the set, and page through that and not what's actually happening?
  587. pep. It can't store items directly because of the first condition: "Each page of the result set is up-to-date at the time it is sent (not just at the time the first page was sent)."
  588. wojtek has left
  589. ziggys has left
  590. Ge0rG Maybe we need to define a message DAG that can be linearly paged.
  591. Zash Linked list?
  592. pep. DAG? What would you branch for?
  593. pep. "The responding entity maintains no state" lol, that's a feature of that paging protocol
  594. jubalh has left
  595. pep. Doesn't that directly contradict the second rule
  596. pep. Maybe that's why these guarantees are MAY, so that responding entities can pick what they like in there
  597. xnamed I added explanation ( https://github.com/xnamed/mod_muc/blob/master/README.md ) about muc-filter very close to the implementation in the ejabberd module I hope that my English is enough or at least to make it easier to you, I had no other way to explain it
  598. Zash pep.: It would likely need to be taken in context of whatever it's used with, eg MAM
  599. goffi has left
  600. pep. Ok I understand now my first question on rsm
  601. valo has left
  602. arc has joined
  603. valo has joined
  604. neshtaxmpp has left
  605. neshtaxmpp has joined
  606. neshtaxmpp has left
  607. neshtaxmpp has joined
  608. david has left
  609. david has joined
  610. Wojtek has joined
  611. Lance has left
  612. Mikaela has left
  613. zach has left
  614. zach has joined
  615. karoshi has left
  616. pdurbin has joined
  617. lovetox has left
  618. pdurbin has left
  619. mimi89999 has left
  620. mimi89999 has joined
  621. ralphm has left
  622. ralphm has joined
  623. zach has left
  624. zach has joined
  625. marc_ has left
  626. mimi89999 has left
  627. Nekit has left
  628. mimi89999 has joined
  629. waqas has joined
  630. waqas has left
  631. UsL has left
  632. UsL has joined
  633. waqas has joined
  634. zach has left
  635. zach has joined
  636. patrick has left