XSF Discussion - 2020-01-22

  1. larma has left

  2. larma has joined

  3. mukt2 has left

  4. Daniel has joined

  5. Dele (Mobile) has left

  6. pep.

    Is there a way to do with pubsub (or else?) many publishers many subscribers, but only subscribers see everything. publishers see their own items

  7. karoshi has left

  8. karoshi has joined

  9. larma has left

  10. larma has joined

  11. larma has left

  12. larma has joined

  13. Shell has joined

  14. mukt2 has joined

  15. aj has left

  16. rion has left

  17. rion has joined

  18. Daniel has left

  19. !XSF_Martin has left

  20. larma has left

  21. larma has joined

  22. !XSF_Martin has joined

  23. typikol has joined

  24. typikol has left

  25. Daniel has joined

  26. david has left

  27. david has joined

  28. aj has joined

  29. Daniel has left

  30. mukt2 has left

  31. pdurbin has joined

  32. mukt2 has joined

  33. Shell has left

  34. aj has left

  35. Shell has joined

  36. pdurbin has left

  37. david has left

  38. david has joined

  39. stpeter has left

  40. dwd

    pep., Defining fulltext search fully would mean servers would have to implement a full-text search engine entirely - it wouldn't handle, for example, stemming in a homogeneous manner, so we'd presumably have to ban that, which feels undesirable. AIUI, MattJ's suggestion is a strict substring field as well as a "magic" field. I think the threat of beer-buying is sufficient to prevent outright silliness (it also prevents anyone being silly and still claiming full conformance, BTW).

  41. emus has left

  42. sonny has joined

  43. debacle has left

  44. Daniel has joined

  45. mukt2 has left

  46. mukt2 has joined

  47. Daniel has left

  48. stpeter has joined

  49. mukt2 has left

  50. mukt2 has joined

  51. karoshi has left

  52. Daniel has joined

  53. mukt2 has left

  54. Daniel has left

  55. Daniel has joined

  56. Douglas Terabyte has left

  57. mukt2 has joined

  58. Daniel has left

  59. mukt2 has left

  60. mukt2 has joined

  61. sonny has left

  62. mukt2 has left

  63. mukt2 has joined

  64. lskdjf has left

  65. !XSF_Martin has left

  66. jubalh has left

  67. fippo has left

  68. mukt2 has left

  69. sonny has joined

  70. !XSF_Martin has joined

  71. mukt2 has joined

  72. Dele (Mobile) has joined

  73. Daniel has joined

  74. pdurbin has joined

  75. stpeter has left

  76. Douglas Terabyte has joined

  77. pdurbin has left

  78. pdurbin has joined

  79. Daniel has left

  80. Daniel has joined

  81. mukt2 has left

  82. mukt2 has joined

  83. Shell has left

  84. mukt2 has left

  85. adiaholic has left

  86. adiaholic has joined

  87. andy has joined

  88. Tobias has joined

  89. mukt2 has joined

  90. Yagiza has joined

  91. neshtaxmpp has left

  92. Daniel has left

  93. mukt2 has left

  94. stpeter has joined

  95. !XSF_Martin has left

  96. lorddavidiii has joined

  97. pdurbin has left

  98. Daniel has joined

  99. stpeter has left

  100. Daniel has left

  101. sonny has left

  102. sonny has joined

  103. waqas has left

  104. mukt2 has joined

  105. paul has joined

  106. Daniel has joined

  107. !XSF_Martin has joined

  108. mukt2 has left

  109. wurstsalat has joined

  110. Daniel has left

  111. karoshi has joined

  112. sonny has left

  113. sonny has joined

  114. Daniel has joined

  115. Daniel has left

  116. j.r has left

  117. j.r has joined

  118. sonny has left

  119. pdurbin has joined

  120. Daniel has joined

  121. !XSF_Martin has left

  122. !XSF_Martin has joined

  123. karoshi has left

  124. jubalh has joined

  125. karoshi has joined

  126. MattJ

    dwd, I don't think we have to rule out stemming

  127. MattJ

    nor mandate it

  128. MattJ

    (for the "plain" search)

  129. MattJ

    But most FTS engines provide an advanced query language, and that's mainly what I want to avoid exposing

  130. lorddavidiii has left

  131. MattJ

    But e.g. it sounded like that's what Guus was doing, it's usually the (slightly) easier option

  132. lorddavidiii has joined

  133. dwd

    Right, indeed. Your suggestion is a dumb substring search, plus magic. I'd aim for magic first, going that any query language is close to nothing. I'm thinking in terms of tsvector in pgsql, for example.

  134. dwd

    Unless I misunderstand your suggestion here.

  135. MattJ

    I'm just saying there should be two fields, plain and implementation-specific

  136. MattJ

    running with the postgres example, the plain one would use plainto_tsquery() for example

  137. sonny has joined

  138. mathijs has left

  139. mathijs has joined

  140. dwd

    But then your plain one would do stemming for example. Surely?

  141. MattJ


  142. MattJ

    I don't see that as a problem

  143. MattJ

    It defines the semantics of the user input, not what the implementation does with that info

  144. MattJ

    "This is a query from the user with no special operators or syntax"

  145. MattJ

    Now find some messages

  146. MattJ

    Which is different to: > <Guus>  simple keywords will work, but more elaborate lucene queries too (although you'd need to know the index fields)

  147. Nekit has joined

  148. MattJ

    I'm saying we should have a way to expose the elaborate queries (if that's what deployments/implementations really want), but we should also have a safe option

  149. MattJ

    Safe in the sense that you can just throw some text in there and have a reasonable expectation it will return something useful

  150. MattJ

    This is from last year, but I just remembered it: https://opensourceconnections.com/blog/2019/05/29/falsehoods-programmers-believe-about-search/

  151. MattJ

    > When you find the boolean operator ‘OR’, you always know it doesn’t mean Oregon

  152. MattJ

    Though I think my favourite from there is: > A customer using the same query twice expects the same results for both searches

  153. jubalh has left

  154. mukt2 has joined

  155. sonny has left

  156. eevvoor has joined

  157. dwd

    Ah, I see.

  158. eevvoor has left

  159. ralphm

    Yeah, search is not trivial.

  160. lovetox has joined

  161. goffi has joined

  162. mukt2 has left

  163. sonny has joined

  164. dwd

    So if I understand correctly, MattJ is arguing that the second sentence of 3.2 of my protoxep should be in effect reversed, and servers MUST interpret any words or characters as search terms, and not treat them as directives or operators.

  165. dwd

    I can certainly go that route.

  166. MattJ

    Depends. You only specified one field, and it depends whether you specified the plain or the non-plain one :)

  167. MattJ

    Guus wants the non-plain one, and this draft was primarily for him at this point, right? :)

  168. Kev

    We already implement MAM search, FWIW, and have for years.

  169. MattJ

    But I wanted to add in a way for the server to convey some help text for the non-plain one

  170. MattJ

    Also we need to deal with localization in the various parts of this

  171. dwd


  172. MattJ

    and that's not easy - it's extremely likely that the server is only going to have FTS for a single locale

  173. MattJ

    But multiple is of course possible with the right setup, I just don't see many people crazy enough to dedicate the resources to that

  174. dwd

    Yeah, fine with extending my extension to introduce extensions. I was mostly in my XEP project for inbox and figured I'd knock it this once so as to have something.

  175. MattJ

    I can contribute the missing parts, I've had this in my head for quite a while, but I'm way too busy this side of FOSDEM

  176. dwd

    I'm not wed to anything here except the beers.

  177. MattJ

    "OR an orange juice"?

  178. dwd

    You don't have to drink the beer. They just have to buy it.

  179. Ge0rG

    this reminds me of how the formulas in Excel/LibreCalc are language-dependent, so if you work with multiple locales, you always get it wrong

  180. dwd

    It makes it impossible to claim they meet the standard by syntax alone.

  181. mathijs has left

  182. mathijs has joined

  183. emus has joined

  184. Guus

    Kev what fields do you use, and what functionality is behind it? My primary motivation was to re-use existing field names if possible, to have overlap.

  185. Kev

    You expect me to remember things? :o

  186. neshtaxmpp has joined

  187. jubalh has joined

  188. jubalh has left

  189. Kev

    { "search", sizeof("search")-1, XEP313_FILTER_TYPE_STRING, "If specified, only return messages that contain each of these words, in any order" }, Seems to be what we're using.

  190. jubalh has joined

  191. MattJ

    I think that's a sensible implementation of the "plain" variant

  192. jubalh has left

  193. Daniel

    that's what Conversations' local search does as well; and what I would expect a server side search to do as well

  194. jubalh has joined

  195. !XSF_Martin has left

  196. jubalh has left

  197. jubalh has joined

  198. cedric has joined

  199. !XSF_Martin has joined

  200. jonas’

    define "word"

  201. jonas’

    if I search for arc, will it return messages which contain "search"?

  202. jonas’

    will it return messages which contain "The word 'arc' may be contained or not"?

  203. jonas’


  204. emus has left

  205. emus has joined

  206. lorddavidiii has left

  207. dwd

    jonas’, Does it matter?

  208. jonas’

    probably not

  209. lorddavidiii has joined

  210. dwd

    jonas’, I mean, does anyone care about replicability of search results between servers? (or between the client's local archive and the server?)

  211. dwd

    Although there's an argument that it might be useful to have a MAM switch that emits only the ids and not the entire messages in case you already have the data. But that feels like an optimisation for another day.

  212. Zash

    If you already have the data, can't you just search there directly?

  213. lorddavidiii has left

  214. jonas’

    Zash, look at how slow conversations is since it got a FTS index ;)

  215. dwd

    Zash, Well, depends on how much of the data you have.

  216. lorddavidiii has joined

  217. Zash

    Also there's the thing where, given an id, it's tricky to retrieve that message

  218. dwd

    Zash, It is?

  219. Zash

    You can request messages before, or after, but not a specific message by id.

  220. dwd

    Zash, Oh. Well, that's stupid then.

  221. dwd

    Zash, So you'd have to ask for one after, then one before the result you get.

  222. Zash


  223. dwd

    Yeah, that's daft.

  224. Zash

    Or one before, then the one after that.

  225. Zash

    Either may or may not work depending on how many messages you have

  226. Zash

    Inb4 inventing SQL over XMPP to solve this

  227. dwd

    Zash, Ask for one before and one after concurrently.

  228. dwd

    Zash, Then it's only 2RTT to get the message you actually wanted.

  229. lorddavidiii has left

  230. mukt2 has joined

  231. lorddavidiii has joined

  232. Guus

    Unrelated question: with RSM, the direction in which you page through the resultset doesn't affect what's defined as the 'first' and 'last' element, right?

  233. Guus

    iow the order of elements on a page does not differ based on the direction that you page through the result set?

  234. Zash


  235. Guus

    👍 thanks

  236. jubalh has left

  237. lorddavidiii has left

  238. Zash

    Which makes it funky to ORDER BY backwards, get the results from SQL backwards, then flip them and send them to the client.

  239. lorddavidiii has joined

  240. jubalh has joined

  241. jubalh has left

  242. sonny has left

  243. sonny has joined

  244. mukt2 has left

  245. lorddavidiii has left

  246. lorddavidiii has joined

  247. lorddavidiii has left

  248. lorddavidiii has joined

  249. paul has left

  250. lorddavidiii has left

  251. lorddavidiii has joined

  252. lorddavidiii has left

  253. lorddavidiii has joined

  254. lorddavidiii has left

  255. lorddavidiii has joined

  256. lorddavidiii has left

  257. lorddavidiii has joined

  258. lorddavidiii has left

  259. lorddavidiii has joined

  260. lorddavidiii has left

  261. lorddavidiii has joined

  262. lorddavidiii has left

  263. lorddavidiii has joined

  264. lorddavidiii has left

  265. lorddavidiii has joined

  266. lorddavidiii has left

  267. lorddavidiii has joined

  268. jubalh has joined

  269. flow

    Zash, Guus, I'd love to see this written down in xep313 (if it's not already).

  270. eevvoor has joined

  271. lovetox has left

  272. Zash

    Doesn't it say in RSM?

  273. flow

    ahh, if so, then i guess that is fine too

  274. lovetox has joined

  275. sonny has left

  276. sonny has joined

  277. lorddavidiii has left

  278. lorddavidiii has joined

  279. paul has joined

  280. murabito has left

  281. jubalh has left

  282. murabito has joined

  283. winfried has left

  284. winfried has joined

  285. wurstsalat has left

  286. wurstsalat has joined

  287. goffi has left

  288. goffi has joined

  289. jubalh has joined

  290. jubalh has left

  291. winfried has left

  292. matkor has joined

  293. winfried has joined

  294. winfried has left

  295. winfried has joined

  296. jubalh has joined

  297. winfried has left

  298. winfried has joined

  299. jubalh has left

  300. jubalh has joined

  301. winfried has left

  302. winfried has joined

  303. jubalh has left

  304. jubalh has joined

  305. jubalh has left

  306. winfried has left

  307. winfried has joined

  308. debacle has joined

  309. winfried has left

  310. debacle has left

  311. winfried has joined

  312. debacle has joined

  313. jubalh has joined

  314. jubalh has left

  315. jubalh has joined

  316. jubalh has left

  317. Wojtek has joined

  318. Zash

    I suppose it doesn't hurt adding some implementation note about it. Feel free to PR 😉

  319. pdurbin has left

  320. sonny has left

  321. dwd


  322. lovetox has left

  323. jubalh has joined

  324. winfried has left

  325. winfried has joined

  326. winfried has left

  327. winfried has joined

  328. !XSF_Martin has left

  329. !XSF_Martin has joined

  330. sonny has joined

  331. marc has left

  332. marc has joined

  333. lovetox has joined

  334. sonny has left

  335. lskdjf has joined

  336. sonny has joined

  337. govanify has joined

  338. eevvoor has left

  339. pep.

    > dwd> You don't have to drink the beer. They just have to buy it. > It makes it impossible to claim they meet the standard by syntax alone. I claim encumbrance. You don't know how easy it is for them to obtain beer :p

  340. jonas’

    I claim encumbrance. I reject supporting the beer production.

  341. pep.

    dwd: interoperability still mandates common wire format doesn't it

  342. pep.

    re MLS/wire

  343. dwd

    pep., Ah, yes. I thought it interesting primarily because Wire were pushing MLS as primary marketing. It's more or less finished, but it's got all the heavyweight cryptanalysis to go - roughly at the same stage where some early experimental deployment of TLSv1.3 was happening while till in Draft, about a year or so befroe the RFC was published.

  344. flow

    pep., MLS-interoperability across federated messaging protocols? I'd expect that to require even more than just a common wire format

  345. mukt2 has joined

  346. Zash

    A common data model at least, so you can map into whatever format

  347. sonny has left

  348. dwd

    flow, You could do text message bridging, though. Depends what the goals are.

  349. jonas’

    depends on where you draw the line around "wire" in "wire format"

  350. jonas’

    or, what Zash says

  351. flow

    I wouldn't be suprised if MLS needs to be tightly-coupled with the underlying groupchat mechanism

  352. dwd

    flow, Prepare to be surprised, then.

  353. flow

    I am prepared, can I be suprised now?

  354. sonny has joined

  355. dwd

    flow, In principle, if two members of the group attempt to commit at once it could get weird, and the DS is supposed to impose a strict ordering, but XMPP does that anyway so I don't think anything special would be needed.

  356. flow

    dwd, DS?

  357. dwd

    flow, Also, "Commit?". Easiest to skim the architecture drafts and get a feel for it.

  358. flow

    will do

  359. dwd

    I can probbaly knock together a lightingish talk at the Summit on MLS if there's interest. Not that I'm any kind of cryptographer of course.

  360. jonas’

    I’d be interested

  361. jonas’

    reminds me to put me on the list of remote attendants

  362. jonas’

    and reminds me to allocate a day off

  363. Max has left

  364. Max has joined

  365. mathijs has left

  366. mathijs has joined

  367. j.r has left

  368. j.r has joined

  369. mukt2 has left

  370. mathijs has left

  371. mathijs has joined

  372. rion has left

  373. rion has joined

  374. sonny has left

  375. mukt2 has joined

  376. sonny has joined

  377. jubalh has left

  378. jubalh has joined

  379. mukt2 has left

  380. pdurbin has joined

  381. Kev

    I think Andrew's right, we should use what's already in the most popular XMPP server (although it's 2014 it was added, not 2016) and use MAM search the way M-Link does :)

  382. pdurbin has left

  383. adiaholic has left

  384. lorddavidiii has left

  385. Zash

    Popularity contest? I object!

  386. lorddavidiii has joined

  387. dwd

    Kev, No idea what you're on about, Openfire's only just adding the feature.

  388. Guus

    I was contemplating how to put that to words, dwd .

  389. jubalh has left

  390. j.r has left

  391. mukt2 has joined

  392. j.r has joined

  393. Zash

    Excuse me, that's the weirdest spelling of Prosody I've seen yet

  394. Zash


  395. winfried has left

  396. winfried has joined

  397. jonas’


  398. Guus

    to be honest, I have no clue how many instances of Openfire are running

  399. Guus

    We have download stats, and update check stats, which give some indication, but that's about it.

  400. dwd

    Lots in locked-down enterprise networks connecting to Active Directory, though.

  401. jonas’

    in the federated world, not many, I think

  402. Guus

    probably true

  403. dwd

    jonas’, Still plenty there; I think most of those doing update checks are likely to be federated.

  404. jonas’

    at least not many seen by s.j.n

  405. jonas’

    so not many hosting MUC services

  406. mukt2 has left

  407. adiaholic has joined

  408. winfried has left

  409. winfried has joined

  410. adiaholic has left

  411. !XSF_Martin has left

  412. !XSF_Martin has joined

  413. adiaholic has joined

  414. j.r has left

  415. j.r has joined

  416. j.r has left

  417. j.r has joined

  418. j.r has left

  419. calvin has joined

  420. stpeter has joined

  421. matkor has left

  422. SubPub has joined

  423. mukt2 has joined

  424. moparisthebest

    Daniel, larma, lovetox, any thoughts on a swap over to finally sending 12-byte IVs ? context: https://github.com/siacs/Conversations/issues/2578

  425. calvin has left

  426. calvin has joined

  427. MattJ

    Relevant: https://github.com/siacs/Conversations/commit/e38a9cd729bfa44d06beb44859516a1eebbb3c92

  428. MattJ

    (and https://github.com/siacs/Conversations/commit/9af056bb16d7294e427dce2d92944c4d12bd8d0f )

  429. Daniel

    it will probbaly happen with the next minor release (not bugfix)

  430. Daniel

    Siskin and profanity are 'fixed' in master

  431. Daniel

    and we will wait for them to release

  432. moparisthebest

    aw awesome, going to go ahead and comment on that issue

  433. Wojtek

    BeagleIM as well (same library as Siskin), should be released soon-ish (depends a bit on Apple)

  434. mukt2 has left

  435. !XSF_Martin has left

  436. j.r has joined

  437. j.r has left

  438. j.r has joined

  439. calvin has left

  440. !XSF_Martin has joined

  441. sonny has left

  442. govanify has left

  443. govanify has joined

  444. winfried has left

  445. winfried has joined

  446. sonny has joined

  447. winfried has left

  448. winfried has joined

  449. jonas’

    cc @ Syndace

  450. mukt2 has joined

  451. stpeter has left

  452. winfried has left

  453. winfried has joined

  454. winfried has left

  455. winfried has joined

  456. winfried has left

  457. winfried has joined

  458. jubalh has joined

  459. Syndace

    thanks jonas’, was involved in that decision

  460. jonas’


  461. mukt2 has left

  462. calvin has joined

  463. lorddavidiii has left

  464. lorddavidiii has joined

  465. jubalh has left

  466. krauq has left

  467. krauq has joined

  468. eevvoor has joined

  469. eevvoor has left

  470. stpeter has joined

  471. !XSF_Martin has left

  472. j.r has left

  473. j.r has joined

  474. !XSF_Martin has joined

  475. j.r has left

  476. j.r has joined

  477. j.r has left

  478. j.r has joined

  479. j.r has left

  480. j.r has joined

  481. lorddavidiii has left

  482. mukt2 has joined

  483. lorddavidiii has joined

  484. lorddavidiii has left

  485. lorddavidiii has joined

  486. j.r has left

  487. j.r has joined

  488. j.r has left

  489. j.r has joined

  490. sonny has left

  491. mathijs has left

  492. mathijs has joined

  493. sonny has joined

  494. alameyo has left

  495. alameyo has joined

  496. mathijs has left

  497. mathijs has joined

  498. pdurbin has joined

  499. mukt2 has left

  500. mukt2 has joined

  501. pdurbin has left

  502. vanitasvitae has left

  503. vanitasvitae has joined

  504. sonny has left

  505. mukt2 has left

  506. sonny has joined

  507. mukt2 has joined

  508. Daniel

    what's the implementation status of bookmarks 2?

  509. pep.

    After what's been done in the sprint?

  510. Daniel

    yeah probably not much

  511. pep.

    the prosody module should be working now

  512. pep.

    converts between all 3 iirc

  513. Link Mauve

    Converts from both forms of XEP-0048 to XEP-0402 format, and then lets the old form of XEP-0048 read from the same store.

  514. mukt2 has left

  515. Link Mauve

    The PEP form of XEP-0048 is only considered for migration, after which it is left unusable.

  516. Link Mauve

    This should work fine since clients can’t rely on this PEP form working when XEP-0411 isn’t advertised.

  517. mukt2 has joined

  518. Daniel

    Yes I actually think that's fine

  519. Daniel

    I know I was super eager on having migration between old pep and new pep working as well. But I don't really understand why anymore

  520. Link Mauve

    It is now working anyway. :)

  521. Link Mauve

    Migration, not concurrent usage.

  522. Daniel

    Yeah. I meant concurrent usage. But yeah it should be fine.

  523. Daniel

    You can unload the old module and then load the new and everything should be ok

  524. Link Mauve


  525. sonny has left

  526. Link Mauve

    The new module will refuse to get loaded if the first one is in the configuration file.

  527. Link Mauve

    (Or loaded.)

  528. Daniel

    Yeah that's cool. Yeah I would like to see a last call on that. Get some more feedback from a wider community and then deploy it.

  529. Daniel

    So for once we could actually do it properly and have a LC before deployment

  530. pep.

    What about the extensions proposal from Link Mauve btw? did that progress a bit? Maybe awaiting for a PR?

  531. Daniel

    The what now?

  532. Daniel

    The changes to the xep went through

  533. pep.

    let me grep in the list

  534. Link Mauve

    pep., which extensions proposal?

  535. pep.

    yours, to bookmarks2

  536. pep.

    For stuff like password etc., or else

  537. Link Mauve

    Ah, the have clients not throw away extensions?

  538. pep.


  539. Link Mauve

    dwd said he was going to add that to the spec.

  540. Link Mauve


  541. pep.


  542. eevvoor has joined

  543. Daniel

    I would actually be cool if we could make Draft before Berlin

  544. Link Mauve


  545. Daniel

    Then we can put the final touches on the implementations in Berlin

  546. marc0s has joined

  547. eevvoor

    at the sprint you mean Daniel?

  548. Daniel

    eevvoor: yes

  549. Ge0rG

    dwd: is Inbox a sophisticated attempt at testing how many levels deep you can nest a <message> without getting your computer taken away? ;)

  550. dwd

    That's a cruel and accurate suggestion.

  551. dwd

    Really, it's a matter of trying to reuse the result from MAM such that things like MAMFC plug into it neatly.

  552. dwd

    But it did feel a bit nesty. Might be a better way of constructing it by injecting an inbox bit inside the result, perhaps.

  553. Ge0rG

    maybe I'm just fed up with trying to read nested messages from one-liner XML dumps from my client and server logs

  554. Ge0rG

    dwd: I don't have a good idea ATM

  555. Kev

    xmllint --format became my friend years ago, and has remained so since.

  556. Kev

    Because yes, reading one-line XMPP stanzas gets worse the deeper they go.

  557. Ge0rG

    Kev: I suppose I need to add a key binding for it to my vim

  558. lovetox has left

  559. Ge0rG

    Kev: it's double nasty in clients that just dump the raw stream instead of individual stanzas, so that your grep dumps a screenful of XML and you need to find the beginning and end of things to be able to xmllint

  560. eevvoor has left

  561. pep.

    I'm not sure I understand why <entry> contains the latest message

  562. pep.

    I mean the whole message

  563. Ge0rG

    pep.: so that you can show the last message in your chat list

  564. pep.

    Are you not going to do MAM anyway right after?

  565. Kev

    No reason to.

  566. pep.

    To get more than 1 message yes

  567. Ge0rG

    pep.: you could implement a thin client that only MAMs when you open a tab

  568. Kev


  569. pep.

    Ge0rG, sure, and then I just need to do MAM when you open the tab

  570. pep.

    Because I will do MAM

  571. pep.

    What I'm interested in inbox is really just the list, because then I know what to fetch via MAM

  572. Kev

    It's fairly common when rendering an inbox (both in chat clients and elsewhere) to want to show a preview of the most recent message, so including the most recent message would achieve that (without doing 100/200/howevermany individual MAM queriest to get the latest message for each inbox entry).

  573. Kev

    So it seems useful to me.

  574. lovetox has joined

  575. lovetox has left

  576. lovetox has joined

  577. pep.

    yeah maybe.. probably something I'll have to ignore then

  578. Ge0rG

    pep.: yes.

  579. Ge0rG

    I still think that poezio should be a fat client, though ;)

  580. pep.

    Ge0rG, in any case that message is useless to me in poezio

  581. pep.

    I'll do MAM to sync up with the last known id

  582. Kev

    The whole fat client/thin client thing I think is only going to be 'resolved' by allowing for both.

  583. Ge0rG

    Kev: I agre

  584. Ge0rG

    Kev: I agree

  585. Kev

    In cases where allowing for both is going to mean lots of data being sent that one or the other doesn't want, potentially shoving a bool on a query to exclude the noise might make sense.

  586. Ge0rG

    I actually have a use-case for both. I want a "fat" poezio on my colo server, with full local logging, and a "thin" MAM-backed one on my laptop when I'm on the go

  587. Zash


  588. Kev

    I don't know if that would add any value to inbox or not, but it's a possibility in general.

  589. Zash

    dwd, had you seen ↑ ?

  590. Kev

    Zash: Is that also similar to the unread stuff in bind2?

  591. pep.

    Ge0rG, both can use MAM

  592. Ge0rG

    pep.: sure, but in different ways

  593. Zash

    Kev, yes, it's inspired by that example in bind2

  594. Ge0rG

    pep.: I want my fat client to do a full MAM sync on startup, and then no more MAM

  595. Kev

    Where inbox is also related to the unread stuff in bind2 (but none of them quite the same)

  596. pep.

    Ge0rG, when joining a new channel

  597. Ge0rG

    startup = new session

  598. Ge0rG

    pep.: history fetch is often good enough, but yeah, okay

  599. Kev

    Zash: I wonder if there's a race there, by not doing it during bind, but it looks useful.

  600. Kev

    Zash: Submit a protoxep?

  601. sonny has joined

  602. Kev

    I do think that server-side tracking of unread per-contact is practically needed, which that doesn't quite do, so it's not a whole solution, I think, but is moving in that direction.

  603. Zash

    Kev: It's mostly done like that to allow easy testing since I don't have bind2 yet.

  604. Kev

    Yeah, that one's a bit of an issue :)

  605. krauq has left

  606. Ge0rG

    as is IM2?

  607. edhelas has left

  608. Zash


  609. edhelas has joined

  610. Zash

    XMPP 2.0

  611. waqas has joined

  612. krauq has joined

  613. winfried has left

  614. winfried has joined

  615. winfried has left

  616. winfried has joined

  617. sonny has left

  618. sonny has joined

  619. dwd

    Zash, I had seen it, but then forgotten about it.

  620. dwd

    pep., And yes, you might not always want the entire message, and instead just know there is one with a particular id. Or you might not need inbox at all if you're going to pull the entire MAM archive across anyway.

  621. dwd

    pep., But lots of existing clients like to list out the conversations, and show a previewish thing of the last message. It's why, for example, Instagram's direct message inbox works in exactly this way.

  622. neshtaxmpp has left

  623. dwd

    pep., We have bigger challenges because we have lots of different styles of client in the XMPP world, and need to cater for them all efficiently without precluding any. I'm not trying to claim this is a finished design suitable for all cases.

  624. Ge0rG

    but it's a very good start

  625. pdurbin has joined

  626. Ge0rG

    dwd: I think it's missing a notion of "open conversations", which is a good thing to keep around in just this place

  627. sonny has left

  628. pep.

    dwd, my goal is not to pull the entire MAM history

  629. pep.

    At least not at first

  630. pep.

    My goal for the inbox thing is really just to get a list of JIDs to fetch MAM for. If I don't have that then I have to fetch then entire history to know who talked to me as there might be JIDs I don't know of (not MUCs nor roster)

  631. pdurbin has left

  632. Ge0rG

    pep.: how is having the last message in the response harmful to that?

  633. pep.

    Ok it may seem I'm still ranting about that, I'm not

  634. Zash

    Timestamp and body of last message per contact gets you most of the data you'd need to show a list of recent conversations and can be done with simple MAM. Read status needs more tracking than what at least Prosody has

  635. pep.

    Zash, that's the thing, you might not be talking only to contacts

  636. Zash

    s/contact/"with" in MAM terms/

  637. pep.

    yeah but you need to know who, which is why I like inbox

  638. Zash

    That MAP thing did that iirc. Wanna be convinced to convert it into mod_inbox? :)

  639. SubPub has left

  640. reedhhw has left

  641. andrey.g has left

  642. sonny has joined

  643. sonny has left

  644. matkor has joined

  645. jubalh has joined

  646. Zash

    Do we need some XPath-ish MAM search thing like the other example of extended search forms?

  647. pep.

    would it be possible to make that message optional maybe?

  648. pep.

    dwd, ^

  649. eevvoor has joined

  650. dwd


  651. !XSF_Martin has left

  652. dwd

    Zash, XPath-based MAM search? Yuck.

  653. Ge0rG

    pep.: what's your goal with that?

  654. pep.

    Ge0rG, why are you fighting it that much? That message is not needed in there all the time :x

  655. Ge0rG

    pep.: I'm not fighting, I'm curious. Every boolean options doubles the number of states you create and have to debug

  656. pep.

    we're at the protocol level still, I think we can live with one or two more options. We're not doing client UX

  657. sonny has joined

  658. Ge0rG

    pep.: please tell me why that Carbon message isn't displayed on my desktop client.

  659. Ge0rG

    (yes, this is a protocol question. More than UX at least)

  660. pep.

    even if that makes things more complex I'm of the opinion that I should be able to choose. if we do one-size-fits-all nobody is going to be happy, or rather, only the golden use case is going to be happy and that's annoying for everybody else

  661. sonny has left

  662. krauq has left

  663. krauq has joined

  664. winfried has left

  665. winfried has joined

  666. Daniel

    So you want to make it optional to request or optional to generate?

  667. Daniel

    Because making it optional to generate would be bad

  668. pep.

    how bad?

  669. pep.

    I was mostly thinking "I don't need it, the server doesn't need to send it". Whether it generates it or not (or stores it as is) it's not my problem

  670. !XSF_Martin has joined

  671. jubalh has left

  672. jubalh has joined

  673. Wojtek has left

  674. MattJ

    What about deployments without MAM? (e.g. for privacy or resource constraint reasons)

  675. waqas has left

  676. mukt2 has left

  677. pep.

    with offline messages?

  678. waqas has joined

  679. pep.

    In any case if the server doesn't keep messages, then it doesn't make sense indeed to force it to return the last one

  680. andrey.g has joined

  681. mukt2 has joined

  682. MattJ

    My point is mainly that you may want to support inbox on a server that doesn't store messages. It seems to me it would be easier for client devs to deal with no message than no inbox

  683. MattJ

    Er, I think I'd be fine with "if the server/user has a MAM archive enabled, you must do this"

  684. emus has left

  685. MattJ

    Just not with making a hard dependency from Inbox to MAM for deployments that don't want that

  686. emus has joined

  687. MattJ

    For something that is ultimately a convenience/optimisation feature

  688. mukt2 has left

  689. mukt2 has joined

  690. winfried has left

  691. Ge0rG

    So such a server would always return an empty list?

  692. winfried has joined

  693. MattJ

    Ge0rG: I think <entry/> would just be empty

  694. sonny has joined

  695. Ge0rG

    MattJ: what JIDs would you list?

  696. MattJ

    (which is already valid per the XEP)

  697. MattJ

    I guess the XEP doesn't really specify what JIDs are in the list

  698. mukt2 has left

  699. MattJ

    With previous PEP-based proposals that was trivial, and the list is a list of open tabs/chats

  700. pep.

    yeah I also liked that

  701. MattJ

    Opening/closing a chat cleanly mapped to adding/removing from the list

  702. MattJ

    Now it's a bit ambiguous

  703. pdurbin has joined

  704. mukt2 has joined

  705. Ge0rG

    May be it can be resolved by adding another flag to the inbox, one that reflects an open chat and is sticky even when there are no unread messages?

  706. debacle has left

  707. pep.

    MattJ, I'd want a per-client list though :x (or profiles or whatever. I guess per-client is already good)

  708. j.r has left

  709. Ge0rG

    pep.: if you have it per client, you don't need to sync it to the server

  710. j.r has joined

  711. pep.

    Ge0rG, maybe it's not just a dumb list in PEP that I want. I also do want to know if MAM/offline stuff that somebody that's not in my roster talked to me and that I need to do MAM with it

  712. pep.

    if I don't have that information right away, I need to fetch the world and I want to avoid that

  713. pdurbin has left

  714. Ge0rG

    pep.: do you want that for all remote JIDs or just the ones that your client hasn't heard from or the ones that are new since the last MAM fetch from any of your clients?

  715. Ge0rG

    I'm trying to determine which sets of information we need for the different use cases and how they overlap

  716. sonny has left

  717. mukt2 has left

  718. Nekit has left

  719. mukt2 has joined

  720. jubalh has left

  721. karoshi has left

  722. MattJ

    Why not a special PEP node plus an iq that performs a query basically equivalent to what Dave's proposal has

  723. MattJ

    For the set of JIDs currently stored

  724. MattJ

    ......plus unreads??

  725. arc has joined

  726. Ge0rG

    Why not have both in the same IQ?

  727. a has left

  728. a has joined

  729. cedric has left

  730. waqas has left

  731. MattJ

    Both what?

  732. neshtaxmpp has joined

  733. Ge0rG

    Both the open tabs and the inbox

  734. mukt2 has left

  735. Yagiza has left

  736. eevvoor has left

  737. Tobias has left

  738. mathijs has left

  739. mathijs has joined

  740. calvin has left

  741. mukt2 has joined

  742. arc has left

  743. arc has joined

  744. arc has left

  745. arc has joined

  746. wurstsalat has left

  747. j.r has left

  748. j.r has joined

  749. lorddavidiii has left

  750. MattJ

    That's basically what I'm proposing, yes

  751. jubalh has joined

  752. waqas has joined

  753. adiaholic has left

  754. adiaholic has joined

  755. arc has left

  756. arc has joined

  757. Ge0rG

    So we were misunderstanding each other all the time? Because that's what I wanted all along as well

  758. Syndace has left

  759. Syndace has joined

  760. MattJ

    Dave's current proposal appears to me to not define any logic around which JIDs should be included in the result

  761. goffi has left

  762. MattJ

    I'm suggesting we merge the old PEP inbox proposal, and use that as the list of JIDs, plus include any others that have pending unread messages

  763. MattJ

    So you have a single query for all "open" chats and unread messages

  764. MattJ

    I think it's similar to what you/someone suggested earlier about a sticky bit on the JIDs, it's just not clear to me how that would get set, how notifications would get broadcast to other clients on update, etc.

  765. MattJ

    I think PEP is a good mechanism for that part

  766. sonny has joined

  767. MattJ

    And that solves my issue too... clients/servers without MAM can still "implement" the open chats part (PEP) without needing to implement the magic query

  768. Daniel has left

  769. Daniel has joined

  770. !XSF_Martin has left

  771. mukt2 has left

  772. gav has joined

  773. !XSF_Martin has joined

  774. mukt2 has joined

  775. emus has left

  776. pdurbin has joined

  777. emus has joined

  778. pdurbin has left

  779. pep.

    Ge0rG, I still want a list of jids (1:1/muc/whatever), but since I'll most likely want a different one per client I can indeed implement it locally, and also I want to know who I have to fetch when I was offline, without having to sync the world

  780. sonny has left

  781. pep.

    Ge0rG, I still want a list of open tabs (1:1/muc/whatever), but since I'll most likely want a different one per client I can indeed implement it locally, and also I want to know who I have to fetch when I was offline, without having to sync the world

  782. debacle has joined

  783. pep.

    Ge0rG, I want a list of open tabs (1:1/muc/whatever), but since I'll most likely want a different one per client I can indeed implement it locally, and also I want to know who I have to fetch when I was offline, without having to sync the world

  784. Daniel has left

  785. krauq has left

  786. calvin has joined

  787. andy has left

  788. andy has joined

  789. Daniel has joined

  790. Daniel has left

  791. pep.

    Also.. the last message is probably not useful for some e2ee mechanisms (PFS).

  792. pep.

    Ah nevermind.

  793. pep.

    That would be an unread message :-°

  794. jubalh has left

  795. emus has left

  796. mukt2 has left

  797. mukt2 has joined

  798. lovetox has left

  799. paul has left

  800. mukt2 has left

  801. mukt2 has joined

  802. winfried has left

  803. winfried has joined

  804. winfried has left

  805. winfried has joined

  806. marc0s has left

  807. marc0s has joined

  808. winfried has left

  809. winfried has joined

  810. winfried has left

  811. winfried has joined

  812. mukt2 has left

  813. !XSF_Martin has left

  814. Daniel has joined