XSF Discussion - 2020-08-21


  1. debacle has left

  2. mukt2 has joined

  3. stpeter has joined

  4. stpeter has left

  5. alameyo has left

  6. arc has left

  7. arc has joined

  8. arc has left

  9. arc has joined

  10. mukt2 has left

  11. alexis has left

  12. alexis has joined

  13. mukt2 has joined

  14. jcbrand has left

  15. mukt2 has left

  16. bear has left

  17. Lance has left

  18. larma has left

  19. bear has joined

  20. mukt2 has joined

  21. larma has joined

  22. moparisthebest has left

  23. moparisthebest has joined

  24. mukt2 has left

  25. mukt2 has joined

  26. arc has left

  27. arc has joined

  28. krauq has left

  29. krauq has joined

  30. Lance has joined

  31. thorsten has left

  32. Lance has left

  33. alameyo has joined

  34. Lance has joined

  35. Lance has left

  36. neshtaxmpp has left

  37. neshtaxmpp has joined

  38. stpeter has joined

  39. stpeter has left

  40. thorsten has joined

  41. neshtaxmpp has left

  42. krauq has left

  43. neshtaxmpp has joined

  44. adiaholic_ has left

  45. adiaholic_ has joined

  46. krauq has joined

  47. adiaholic_ has left

  48. adiaholic_ has joined

  49. krauq has left

  50. krauq has joined

  51. arc has left

  52. arc has joined

  53. Yagiza has joined

  54. mukt2 has left

  55. adiaholic_ has left

  56. adiaholic_ has joined

  57. arc has left

  58. arc has joined

  59. alexis has left

  60. arc has left

  61. arc has joined

  62. mukt2 has joined

  63. larma has left

  64. bear has left

  65. larma has joined

  66. adiaholic_ has left

  67. adiaholic_ has joined

  68. krauq has left

  69. krauq has joined

  70. murabito has left

  71. mukt2 has left

  72. mukt2 has joined

  73. bear has joined

  74. stpeter has joined

  75. stpeter has left

  76. neshtaxmpp has left

  77. neshtaxmpp has joined

  78. murabito has joined

  79. lorddavidiii has joined

  80. DebXWoody has joined

  81. papatutuwawa has left

  82. papatutuwawa has joined

  83. adiaholic_ has left

  84. adiaholic_ has joined

  85. neshtaxmpp has left

  86. neshtaxmpp has joined

  87. APach has left

  88. APach has joined

  89. bear has left

  90. Tobias has joined

  91. adiaholic_ has left

  92. adiaholic_ has joined

  93. adiaholic_ has left

  94. adiaholic_ has joined

  95. Mikaela has joined

  96. werdan has joined

  97. paul has joined

  98. krauq has left

  99. krauq has joined

  100. neshtaxmpp has left

  101. werdan has left

  102. jonas’

    larma, lovetox, I am of the opinion that '394 is a dead-end and we should instead re-vive a different subset of XHTML, with clearer and stricter rules plus maybe a reference cleanup implementation in JavaScript.

  103. adiaholic_ has left

  104. adiaholic_ has joined

  105. APach has left

  106. mukt2 has left

  107. APach has joined

  108. Seve

    +1

  109. karoshi has joined

  110. krauq has left

  111. neshtaxmpp has joined

  112. MattJ

    I used to agree, but these days I see all the problems that come with allowing multiple representations of the body

  113. APach has left

  114. APach has joined

  115. neshtaxmpp has left

  116. stpeter has joined

  117. stpeter has left

  118. krauq has joined

  119. mukt2 has joined

  120. adiaholic_ has left

  121. adiaholic_ has joined

  122. winfried has left

  123. winfried has joined

  124. winfried has left

  125. winfried has joined

  126. emus has joined

  127. winfried has left

  128. winfried has joined

  129. winfried has left

  130. winfried has joined

  131. lorddavidiii has left

  132. larma

    jonas’: why do you think so? I think 394 has great potential because it's extensible and has a properly defined fallback behavior. It's a good design and easy to implement. What's the issues you see?

  133. lovetox has joined

  134. jonas’

    larma, I doubt the "easy to implement" part

  135. jonas’

    it has nasty corner cases (though counting itself is not one of them, since it’s clearly defined to count code points), e.g. what happens if a markup span ends right between two codepoints belonging to one emoji?

  136. jonas’

    I also don’t particularly like the fallback characters, they are bound to cause annoyances.

  137. lovetox

    jonas’, thats not a nasty corner case

  138. lovetox

    you try to find *something* that maybe does not work

  139. lovetox

    which never happens in real life

  140. jonas’

    lovetox, it may not be for an emoji, but I don’t dare to say it can’t cause problems in some scripts. Unicode is a strange thing.

  141. lovetox

    and even if, people would not see as "OMG i dont even can end a span between a emoji

  142. jonas’

    lovetox, yeah, that’s how you design robust things, not by saying "ah, that’s never going to happen!!"

  143. adiaholic_ has left

  144. adiaholic_ has joined

  145. jonas’

    lovetox, of course, nobody will complain that in XHTML-IM, they can’t do onload="alert()". But if an attacker does, all hell breaks loose.

  146. lovetox

    btw i also would love a subset of xhtml

  147. lovetox

    but i guess everyone can already implement that

  148. lovetox

    there is no need for a new XEP?

  149. jonas’

    how can everyone implement that already?

  150. lovetox

    just implement only, a subset ...

  151. lovetox

    like everyone does already

  152. jonas’

    but which subset?

  153. jonas’

    ok, I don’t want to discuss this with you right now

  154. lovetox

    the one you care about

  155. lovetox

    thats why im asking, i can just trim my xhtml impl

  156. lovetox

    or do a totally new 394

  157. Dele Olajide has joined

  158. Maranda has left

  159. adiaholic_ has left

  160. adiaholic_ has joined

  161. lovetox has left

  162. larma

    jonas’: iirc, the same issue of multi-codepoint emoji being split across multiple spans is not well defined in any popular markup system including HTML.

  163. larma

    So honestly that seems to be a non-issue. And I can hardly imagine a proper design that would have specific handling and not cause immense developer work as you'd have to tap into the font rendering library which you usually try not to do

  164. Maranda has joined

  165. debacle has joined

  166. mukt2 has left

  167. adiaholic_ has left

  168. adiaholic_ has joined

  169. flow has joined

  170. mukt2 has joined

  171. sonny has left

  172. sonny has joined

  173. lskdjf has joined

  174. sonny has left

  175. sonny has joined

  176. lorddavidiii has joined

  177. Maranda has left

  178. xecks has joined

  179. jcbrand has joined

  180. Maranda has joined

  181. goffi has left

  182. goffi has joined

  183. Shell has left

  184. Shell has joined

  185. flow has left

  186. floretta has left

  187. mukt2 has left

  188. mukt2 has joined

  189. stpeter has joined

  190. stpeter has left

  191. neshtaxmpp has joined

  192. amuza@riseup.net has left

  193. neshtaxmpp has left

  194. jonas’

    larma, it is irrelevant as long as there’s only a single possible representation of the text. However, with 394, there are two: one with markup applied and one without.

  195. jonas’

    if the goal of '394 is to avoid different meaning of text with and without markup applied, these corner cases need to be investigated

  196. dwd

    MattJ, I think the root problem is multiple displays of the body - that is, a message that can mean one thing to one person (or intermediary filtering system) and something else to another. I think that problem is way worse with XHTML-IM and similar, minimal with 393, and 394 represents a reasonable comprmise (assuming it gains the "this was markup tag"; without it should be minimal as well).

  197. papatutuwawa has left

  198. amuza@riseup.net has joined

  199. MattJ

    dwd: that's basically my opinion too

  200. jonas’

    larma, can I convince you to take over '394? ;)

  201. arc has left

  202. arc has joined

  203. larma

    I still have my work on "sims 2" and stickers pending ;)

  204. larma

    Oh, and reactions

  205. larma

    But beside that, I'd be OK to take it over

  206. jonas’

    larma, sims 2 the game?

  207. larma

    No

  208. jonas’

    oh damn

  209. larma

    Sims as in 385

  210. jonas’

    right

  211. larma

    http://larma.de/xeps/sfs.html#intro

  212. jonas’

    I like most of that, though I do see some use for mixed content.

  213. adiaholic_ has left

  214. adiaholic_ has joined

  215. jonas’

    larma, immediate feedback: - allow more than one <file-sharing/> element per message; - add an ID to each file-sharing element so that it can be referenced by future specifications.

  216. jonas’

    then it would be trivial to build a combination of that + 394 which allows inline images :)

  217. emus

    > http://larma.de/xeps/sfs.html#intro 👍

  218. eta has left

  219. eta has joined

  220. matkor has left

  221. floretta has joined

  222. matkor has joined

  223. LNJ

    larma: Great work, I really like the changes you made and especially the attaching of new sources. Have you thought about using message fastening for this? And another point that I was also missing in SIMS is that there is no example for including the thumbnail data (BoB would also allow communication of the data via IQs).

  224. LNJ

    +1 for allowing multiple files

  225. Daniel

    Looks good on first glance.

  226. Daniel

    Cleans up the issues I have with sims

  227. Daniel

    Will take a closer look later in the day

  228. Daniel

    Oh 2.3 is interesting. especially but not only in a group context. would be interesting to see if and how succesful that will actually get implemented

  229. winfried has left

  230. winfried has joined

  231. neshtaxmpp has joined

  232. Daniel

    but good downwards comptability to the x-oob+body method

  233. Daniel

    and will solve the weird standstill we currently have with SIMS

  234. debacle has left

  235. Steve Kille has left

  236. arc has left

  237. arc has joined

  238. Steve Kille has joined

  239. krauq has left

  240. krauq has joined

  241. larma

    jonas’: mixed content only makes sense for media files, you can't mix a random binary with normal text. So mixed content is intentionally out of scope there.

  242. dwd

    "Here's the PDF you wanted" - seems pretty useful to me.

  243. neshtaxmpp has left

  244. dwd

    The other problem that we run into is "Here is the current COVID-19 protocol" - we want later "hits" on that file identifier to get the latest version, ideally.

  245. !XSF_Martin has left

  246. larma

    dwd: you can still send message and file and files can have descriptions

  247. !XSF_Martin has joined

  248. dwd

    Yes, you can (and that's what we do), but it means a search for the message doesn't naturally locate the file.

  249. larma

    If you use file description it could.

  250. dwd

    Yes, true. But that means the file description would end up being used as a message, if you're not careful. Depends very heavily on the UI; a file sharing extension on iOS, for example, is likely to end up using a description, whereas sharing a file inline to a chat is more likely to be showing a message+attachment kind of metaphor.

  251. larma

    Also searching for files is inherently a huge problem. For PDFs you'd want to actually search the content of the file as well. For pictures this would also be great but you'd need to OCR + image detection which is not easy.

  252. dwd

    Well, that's another problem entirely.

  253. dwd

    But anyway, I think overall, our greater problem is (essentially) versioning rather than the message+file case.

  254. larma

    I totally agree this XEP is not to solve all possible scenarios. It intentionally does not replace sims, but provides an alternative that is more like an evolution of what we are doing now (oob)

  255. arc has left

  256. arc has joined

  257. larma

    Versioning to me seems like a total sidecase. You are typically also not versioning messages (even with lmc, you don't edit messages from weeks ago)

  258. larma

    If you need file versioning, oob seems like a sane approach to me

  259. werdan has joined

  260. dwd

    I know you're not versioning messages. But it would be nice if this could just share, essentially, a link in the same format.

  261. wurstsalat has left

  262. dwd

    Which ought to be a simple matter of having much of the file metadata element optional, and possibly a mechanism [given some stable identifier] of finding the current detailed metadata.

  263. wurstsalat has joined

  264. amuza@riseup.net has left

  265. larma

    My suggestion for versioning files if you want to stick with xmpp only would be to put the file metadata on a pubsub node and then just send a reference to that pubsub node in the message. You can update it (including getting a history) at any time and have a pointer to the actual file content (as http link) in it. Thereby you get proper versioning with possibility to fetch historic file versions.

  266. larma

    But that's totally overkill for the one shot file sharing I believe most users want.

  267. dwd

    Oh, sure, we *could*. But then the client has to be able to understand that.

  268. neshtaxmpp has joined

  269. larma

    You are talking about a niche feature. It's not going to be implemented by all clients, no matter how bard you push, so better to keep the basic feature alone for those only interested in that.

  270. larma

    You are talking about a niche feature. It's not going to be implemented by all clients, no matter how hard you push, so better to keep the basic feature alone for those only interested in that.

  271. papatutuwawa has joined

  272. werdan has left

  273. amuza@riseup.net has joined

  274. dwd

    Yeah, sure, but I'm suggesting that allowing some metadata to be optional means versioning is then supported (alongside named URL sharing, actually) but in a uniform format that will "just work" for most receiving clients.

  275. dwd

    So I don't *need* to push on receivers to support anything.

  276. neshtaxmpp has left

  277. Maranda has left

  278. eevvoor has joined

  279. larma

    Well, you'd need to get rid of the file hash at least which means the file is not authenticated through the message anymore (assuming the message is) and you also can't make use of the 2.3 feature

  280. Maranda has joined

  281. mukt2 has left

  282. DebXWoody has left

  283. adiaholic_ has left

  284. adiaholic_ has joined

  285. Steve Kille has left

  286. mukt2 has joined

  287. Steve Kille has joined

  288. alameyo has left

  289. alameyo has joined

  290. jonas’

    larma, I always find it annoying when I have to write text messages separately from the media or files I send, since the file upload typically happens asynchronously.

  291. jonas’

    so I can’t know when my text message arrives related to the blob

  292. jonas’

    which is meh, also for the flow of reading on the receiving end

  293. !XSF_Martin

    Yeah, the way other messengers do it is nice.

  294. !XSF_Martin

    Where the image and your comment are one message.

  295. eevvoor

    ‎!XSF_Martin how do they do it exactly?

  296. eevvoor

    Are the technical details known?

  297. !XSF_Martin

    On the protocol level no idea. Threema and WhatsApp are closed source. Maybe signal does this too? Then one might have a look how they do it.

  298. MattJ

    It's not exactly rocket science to put text and a URL in a single message :)

  299. winfried has left

  300. winfried has joined

  301. Zash

    Inline vs attached vs singletons?

  302. !XSF_Martin

    Probably they have some uploaded file url in some field and the text/body in another.

  303. mukt2 has left

  304. dwd

    MattJ, Yes, but what about a series of hashes in multiple algorithms?

  305. mukt2 has joined

  306. dwd

    Also, yes, that problem of slow links and file/image uploads in a problem we have to solve as well.

  307. alexis has joined

  308. stpeter has joined

  309. stpeter has left

  310. DebXWoody has joined

  311. neshtaxmpp has joined

  312. karoshi has left

  313. debacle has joined

  314. mukt2 has left

  315. MattJ

    In MIX the messages are in the participants' archives... does the MIX server *also* keep an archive? Would clients ever query it?

  316. jonas’

    yes, always

  317. jonas’

    because we don’t have a reliable s2s sync protocol, so the user’s archive is bound to be incomplete.

  318. jonas’

    also for history before you joined

  319. MattJ

    So why store them in the user's archive then?

  320. jonas’

    no idea :)

  321. j.r has left

  322. jonas’

    (that was a bit of a snark. Actually, having them in the user’s archive is very convenient for the user and we should maybe see if we can fix the s2s sync)

  323. dwd

    MattJ, Yes, for example if a MIX channel were used as a pager replacement, someone newly allocated to the pager will query the archive to find previous messages in a conversation.

  324. j.r has joined

  325. mukt2 has joined

  326. MattJ

    Sounds simple™

  327. MattJ

    from a client perspective

  328. dwd

    Dealing with S2S sync is certainly a good problem to tackle, BTW.

  329. DebXWoody has left

  330. Zash

    S2S MAM?

  331. jonas’

    for certain definitions of "good"

  332. Zash

    "sync"... ugh

  333. dwd

    Well, reliability.

  334. dwd

    I think we don't want to be tackling more than dropped connections. Sustained disconnected-mode operation for S2S isn't something that's worth tackling - things like FMUC handle those kinds of cases.

  335. karoshi has joined

  336. winfried has left

  337. winfried has joined

  338. winfried has left

  339. winfried has joined

  340. Zash

    So do we need more than s2s stream management?

  341. dwd

    Zash, Probably not, actually.

  342. jonas’

    Zash, yes, because you’ll miss messages while the server is restarting

  343. winfried has left

  344. winfried has joined

  345. jonas’

    unless you can persist s2s state && the remote will hold their state long enough so that your kernel upgrade + 10 minute reboot time is covered

  346. dwd

    jonas’, So do we need an outgoing buffer and retry semantics rather than bound-with-error?

  347. krauq has left

  348. dwd

    jonas’, So do we need an outgoing buffer and retry semantics rather than bounce-with-error?

  349. jonas’

    dwd, I don’t think that’d be a good idea

  350. jonas’

    maybe s2s SM + pull-based MAM sync from MIX-enabled user-servers after a server restart would be sufficient?

  351. Zash

    MUX-side delivery tracking ?

  352. Ge0rG

    what about a thing that's somewhere in between 0198 and MAM; keep a queue of "important" stanzas, use unique IDs instead of counter values, resync after session setup.

  353. jonas’

    dwd, problem with the outbound queues is their size will be limited at some point, pushing the problem only back. A highly active MIX could exhaust that limit during your kernel upgrade.

  354. jonas’

    though SM and outbound queues are still problematic anyways...

  355. karoshi has left

  356. karoshi has joined

  357. jonas’

    so in fact, a server would have to do pull-based MAM sync whenever it is not able to SM-resume with the other side, no matter the reason.

  358. jonas’

    look, that sounds like what clients do!

  359. Zash

    MIX is server side MUC?

  360. dwd

    jonas’, For all its users?

  361. jonas’

    and then the server would have to both sync the messages into MAM *and* replay them live to already-connected clients (which may have synced with the *local* MAM already and think they’re up-to-date) *and* queue and delay any *live* messages from the MIX so that everything arrives in order

  362. dwd

    jonas’, And you think this is beter scaling than a 0198 queue?

  363. krauq has joined

  364. jonas’

    dwd, I think this serves a different purpose than a '198 queue

  365. dwd

    jonas’, Is that purpose to make everyone's life harder? If so, mission accomplished. :-)

  366. jonas’

    dwd, the purpose is to achieve reliable message delivery

  367. jonas’

    I’m not sure how you’re going to achieve that with '198 alone. It hasn’t sufficed for c2s, it won’t suffice for s2s either.

  368. Zash

    Ugh, sync :(

  369. alexis has left

  370. winfried has left

  371. winfried has joined

  372. jonas’

    dwd, there are two key guarantees which need to be held which make this very hard: - In-order message delivery from the MIX to the client - No insertions into the middle of the user’s MAM archive

  373. Ge0rG

    Can't we just have forever-persistent 0198?

  374. jonas’

    and this is why Ge0rG (sorry for putting words in your mouth again) and I have been saying that the user’s local archive is a terrible idea and only going to cause pain.

  375. winfried has left

  376. winfried has joined

  377. Zash

    Can't we just embrace fast delivery or failure notification?

  378. MattJ

    Notify the MIX that delivery failed

  379. Ge0rG

    Zash: there was a one-message thread on message errors some time ago...

  380. Ge0rG

    MattJ: and then the MIX can kick the user out! Win-win!

  381. MattJ

    Sounds like a plan

  382. Ge0rG

    And when the user rejoins, they just do a full sync!

  383. Zash

    Message attachments in the form of delivery statuses?

  384. MattJ

    I knew MIX could solve all the problems of MUC in the simplest possible way

  385. Ge0rG

    Or you just add a tombstone to all local user archives whenever s2s fails

  386. dwd

    Ge0rG, Put in a tombstone for every missed message. Seems legit.

  387. Ge0rG

    dwd: but you don't know which / how many messages you missed!

  388. dwd

    Ge0rG, You would if you had tombstones.

  389. jonas’

    dwd, how is the server to know how many messages it missed?

  390. dwd

    jonas’, Because of the tombstones. I fail to see how you can fault my logic here.

  391. mukt2 has left

  392. mukt2 has joined

  393. Ge0rG

    dwd: aaah, right! The tombstones! It's obvious to me now!

  394. andrey.g has joined

  395. jonas’

    sorry, my sarcasmometer is out-of-service due to the heatwave

  396. dwd

    jonas’, Storm Ellen here, my smilies have been blown away.

  397. sonny has left

  398. sonny has joined

  399. Ge0rG

    surely just a random weather phenomenon not related in any way to ocean heating or the CO2 amounts in the atmosphere

  400. jonas’

    Ge0rG, surely.

  401. jonas’

    Ge0rG, ThiS iS a SAfE sPaCe gO AWaY wiTH yOUr ClIMAtE ChaNGE IdeOLogY!

  402. jonas’

    s/ChaNGE/CaTAsTrOPHy/, too

  403. Ge0rG

    </trigger-warning>

  404. jcbrand has left

  405. lorddavidiii has left

  406. krauq has left

  407. krauq has joined

  408. Nano4BeingYou has joined

  409. alexis has joined

  410. adiaholic_ has left

  411. adiaholic_ has joined

  412. Nano4BeingYou has left

  413. stpeter has joined

  414. stpeter has left

  415. jcbrand has joined

  416. eevvoor has left

  417. mukt2 has left

  418. bear has joined

  419. j.r has left

  420. mukt2 has joined

  421. winfried has left

  422. winfried has joined

  423. lorddavidiii has joined

  424. mukt2 has left

  425. mukt2 has joined

  426. neshtaxmpp has left

  427. neshtaxmpp has joined

  428. Shell has left

  429. krauq has left

  430. krauq has joined

  431. mukt2 has left

  432. krauq has left

  433. krauq has joined

  434. mukt2 has joined

  435. krauq has left

  436. krauq has joined

  437. winfried has left

  438. winfried has joined

  439. Maranda has left

  440. Maranda has joined

  441. winfried has left

  442. winfried has joined

  443. winfried has left

  444. winfried has joined

  445. stpeter has joined

  446. stpeter has left

  447. sonny has left

  448. sonny has joined

  449. sonny has left

  450. eevvoor has joined

  451. sonny has joined

  452. winfried has left

  453. winfried has joined

  454. Holger

    > and this is why Ge0rG (sorry for putting words in your mouth again) and I have been saying that the user’s local archive is a terrible idea and only going to cause pain. I'm saying that all day long (can't remember saying anything else since I first heard of MIX) and would still very much prefer to keep this feature optional.

  455. Ge0rG

    Holger: but you are not the XEP author.

  456. larma has left

  457. lskdjf has left

  458. sonny has left

  459. sonny has joined

  460. sonny has left

  461. sonny has joined

  462. winfried has left

  463. winfried has joined

  464. winfried has left

  465. winfried has joined

  466. j.r has joined

  467. andrey.g has left

  468. jcbrand has left

  469. lovetox has joined

  470. alexis has left

  471. mukt2 has left

  472. lovetox has left

  473. krauq has left

  474. krauq has joined

  475. Nano4BeingYou has joined

  476. Nano4BeingYou has left

  477. mukt2 has joined

  478. neshtaxmpp has left

  479. MattJ

    Still, if we have community consensus that this design is flawed, we can still change it, right? If the MIX has an archive anyway, clients just need to query that instead

  480. MattJ

    ...right...?

  481. MattJ

    Relatedly: https://framapiaf.org/@debacle/104713005724817353 (thanks debacle)

  482. winfried has left

  483. winfried has joined

  484. alameyo has left

  485. j.r has left

  486. j.r has joined

  487. Kev

    The only reason for MIX to need to be in the user's archive is for search.

  488. Kev

    (From memory)

  489. Kev

    Well, bandwidth too, but mostly search.

  490. MattJ

    If that's the case, I'm happy with that

  491. Holger

    MattJ: At least during the Summit it seemed to me the consensus is to have user archives. But yes I'd think we should just have clients check a feature (IIRC there is one in MIX-PAM) to decide which archive to query. Increases complexity on the client side which I'm usually all for avoiding at all cost, but seems the least evil to me in this case.

  492. Kev

    If someone could come up with a decent solution to search it would be nice to drop it.

  493. winfried has left

  494. winfried has joined

  495. alexis has joined

  496. Kev

    (Ok, I think I'm up to three reasons - search, bandwith, and persistence)

  497. MattJ

    Yeah, I think I'd rather tackle the search problem than turn the current architecture on its head and face a whole set of other problems

  498. Holger

    Kev: I also remember scalability arguments, i.e. the case where the client is joined to thousands of rooms.

  499. Holger

    And persistence, yes.

  500. Holger

    I get all that but I think we'd need to solve a couple of problems before at least I would be able to implement user archives. And it would be nice if that wouldn't block MIX.

  501. Kev

    You really don't want to be in a room that keeps history for a day, come back two days later and not see the replies to your messages.

  502. Kev

    It's one of those 'no ideal solutions' things, I think, that just hurts because of federated architectures.

  503. Holger

    Right now the user server would either duplicate to death or have to implement black dedup magic. Plus the sync issues.

  504. Kev

    User archives seemed like the least bad solution.

  505. jonas’

    Kev, so a user archive which seems complete, but has gaps nobody knows about is better than an archive which tells you "sorry, I don’t have your newest message, there is a gap here"

  506. Holger

    So I think right now it's a horrible combination of the downsides of Matrix with those of XMPP.

  507. jonas’

    that logic seems flawed to me

  508. Holger

    I think.

  509. Kev

    jonas’: Dear Strawman, love...?

  510. winfried has left

  511. winfried has joined

  512. eta

    so, the thing I never got with XEP-0045 is

  513. jonas’

    Kev, I can’t follow, sorry

  514. jonas’

    my english fails me

  515. Kev

    jonas’: You're presenting a position that isn't mine, then arguing that it's wrong, and therefore I am.

  516. eta

    why can't the server just keep a log of what was said after a resource left, persist that, and then replay it as join history?

  517. jonas’

    Kev, sorry, not my entention, maybe I missed something

  518. Kev

    I don't think user archives should have gaps in them, which is why we needed the sync logic between MIX and User archive.

  519. Holger

    eta: It could. MAM is just nicer because the paging.

  520. jonas’

    Kev, ok, I missed that, sorry

  521. jonas’

    ignore me :)

  522. jonas’

    ignore me & carry on :)

  523. Kev

    It was a discussion at the Summit about how we needed to ensure we could detect holes in the user's view of the MIX archive, and plug them.

  524. MattJ

    eta, paging and tracking is harder than you think (usually people "leave" the MUC long after they lost their connection)

  525. Kev

    Maybe it was a side-room discussion, I forget at this point.

  526. jonas’

    I might’ve missed that discussion :/

  527. eta

    MattJ, ah right, reasonable enough

  528. jonas’

    eta, also unbounded storage requirements on the server side. What if the resource never comes back?

  529. eta

    jonas’, well I guess you'd need some cap

  530. eta

    but nvm, I'm convinced MAM is probably ideal

  531. jonas’

    eta, also, MAM-MUC is pretty much that, except that the client has to explicitly ask ;)

  532. MattJ

    Just like with MAM. In fact Prosody (and I'd be surprised if not other servers) uses the MAM archive to fulfil MUC history requests these days

  533. emus has left

  534. winfried has left

  535. winfried has joined

  536. Zash has left

  537. Zash has joined

  538. DebXWoody has joined

  539. Holger

    BTW 0369, 7.2.1 says the user's server MUST archive, 7.2.2 says it MAY?

  540. j.r has left

  541. j.r has joined

  542. Dele Olajide has left

  543. emus has joined

  544. sonny has left

  545. sonny has joined

  546. Guus has left

  547. Guus has joined

  548. larma has joined

  549. jcbrand has joined

  550. dwd

    Holger, Take the average, it's a SHOULD.

  551. Holger

    🙂

  552. dwd

    Although if it says MUST twice and MAY once, it's a REALLY SHOULD.

  553. Holger

    Makes sense.

  554. Holger

    I'm okay with MUST archive as long as I MAY apply an arbitrary expiry period of 0 or more seconds.

  555. jonas’

    :>

  556. jonas’

    Holger, you are aware that you can’t do that as a user server, right?

  557. jonas’

    not without purging all the other messages too

  558. jonas’

    due to how MAM works ;)

  559. Holger

    Well with our specific implementation (stanza ID being a timestamp) things wouldn't break.

  560. mukt2 has left

  561. jonas’

    holes in MAM are forbidden

  562. Holger

    Yes my statement was just that "things wouldn't break".

  563. jonas’

    only with an expiry of exactly 0s implemented by not visibly storing the messages

  564. jonas’

    otherwise you have to violate '313 by not returning the correct response for an ID not in your archive.

  565. jonas’

    > If any UID requested by the client in any of the 'before-id', 'after-id' or 'ids' form fields is not present in the archive, the server MUST return an item-not-found error in response to the query.

  566. Holger

    Yes that's what I'm doing.

  567. jonas’

    Shame on you! Violating a MUST!

  568. jonas’

    (also, yes it is friday)

  569. Holger

    Wasn't in earlier revisions IIRC, and isn't in 0059. We have generic 0059 code to do 0059 with MAM and other things, and I'm not keen on "if MAM then this else that" special casing.

  570. Wojtek has joined

  571. jonas’

    nothing to do with '59 that bit of text

  572. adiaholic_ has left

  573. jonas’

    gotta go now tho

  574. adiaholic_ has joined

  575. Nekit has left

  576. Holger

    Not sure how to parse that. 0059 says what to do if a UID requested is not present in the archive. 0313 says something else on the same topic.

  577. Holger

    Generic implementation is one reasoning, the other is avoiding the additional SQL query on each and every MAM request.

  578. alameyo has joined

  579. MattJ

    The error is to allow clients to detect gaps in the sync

  580. MattJ

    if that's not obvious

  581. Holger

    I understand the reasoning but that doesn't make me like the solution ;-)

  582. lskdjf has joined

  583. Zash has left

  584. mukt2 has joined

  585. arc has left

  586. arc has joined

  587. alexis has left

  588. Lance has joined

  589. sonny has left

  590. sonny has joined

  591. neshtaxmpp has joined

  592. krauq has left

  593. krauq has joined

  594. Zash has joined

  595. Guus

    Does anyone know an administrator for jabber.cz?

  596. stpeter has joined

  597. stpeter has left

  598. Guus

    They might want to review their user using smash55 for its username

  599. dwd

    What would things look like iof MIX messages did not go into the user's archive ever, and instead were fetched on demand - could this be managed by the server or would it have to be managed by the client?

  600. Guus

    dwd: re your question on twitter: try Greg and Dele

  601. winfried has left

  602. winfried has joined

  603. winfried has left

  604. winfried has joined

  605. krauq has left

  606. krauq has joined

  607. alexis has joined

  608. winfried has left

  609. winfried has joined

  610. !XSF_Martin

    Guus: What's the issue with that useername?

  611. Guus

    !XSF_Martin: it is the point of contact that's advertised in spam messages

  612. !XSF_Martin

    Ah I misinterpreted > review their user … for its username So I thought the username is the problem itself. Sorry, not a native speaker.

  613. dwd

    Guus, Oh, good call. Though i think that's maybe the wrong bit of BT entirely.

  614. j.r has left

  615. j.r has joined

  616. Guus

    dwd: could be, but I believe they've both moved around

  617. Guus

    Worth a shot

  618. winfried has left

  619. winfried has joined

  620. Steve Kille has left

  621. Steve Kille has joined

  622. winfried has left

  623. winfried has joined

  624. alameyo has left

  625. alameyo has joined

  626. Guus has left

  627. Guus has joined

  628. winfried has left

  629. winfried has joined

  630. alexis has left

  631. Shell has joined

  632. winfried has left

  633. winfried has joined

  634. winfried has left

  635. winfried has joined

  636. winfried has left

  637. winfried has joined

  638. winfried has left

  639. winfried has joined

  640. eevvoor has left

  641. eevvoor has joined

  642. krauq has left

  643. krauq has joined

  644. lovetox has joined

  645. arc has left

  646. arc has joined

  647. neshtaxmpp has left

  648. Wojtek has left

  649. lovetox has left

  650. Wojtek has joined

  651. neshtaxmpp has joined

  652. winfried has left

  653. winfried has joined

  654. winfried has left

  655. winfried has joined

  656. winfried has left

  657. winfried has joined

  658. krauq has left

  659. krauq has joined

  660. krauq has left

  661. krauq has joined

  662. neshtaxmpp has left

  663. sonny has left

  664. sonny has joined

  665. arc has left

  666. arc has joined

  667. sonny has left

  668. sonny has joined

  669. bear has left

  670. Yagiza has left

  671. arc has left

  672. arc has joined

  673. winfried has left

  674. winfried has joined

  675. andrey.g has joined

  676. sonny has left

  677. sonny has joined

  678. winfried has left

  679. winfried has joined

  680. mukt2 has left

  681. mukt2 has joined

  682. bear has joined

  683. winfried has left

  684. winfried has joined

  685. winfried has left

  686. winfried has joined

  687. adiaholic_ has left

  688. adiaholic_ has joined

  689. Lance has left

  690. debacle has left

  691. adiaholic_ has left

  692. adiaholic_ has joined

  693. winfried has left

  694. winfried has joined

  695. krauq has left

  696. krauq has joined

  697. andrey.g has left

  698. winfried has left

  699. winfried has joined

  700. winfried has left

  701. winfried has joined

  702. lovetox has joined

  703. Nekit has joined

  704. Lance has joined

  705. winfried has left

  706. winfried has joined

  707. bear has left

  708. winfried has left

  709. winfried has joined

  710. Lance has left

  711. winfried has left

  712. winfried has joined

  713. lovetox has left

  714. DebXWoody has left

  715. eevvoor has left

  716. winfried has left

  717. winfried has joined

  718. Lance has joined

  719. sonny has left

  720. sonny has joined

  721. bear has joined

  722. adiaholic_ has left

  723. Lance has left

  724. winfried has left

  725. winfried has joined

  726. sonny has left

  727. sonny has joined

  728. jcbrand has left

  729. neshtaxmpp has joined

  730. Lance has joined

  731. winfried has left

  732. winfried has joined

  733. goffi has left

  734. Zash has left

  735. Zash has joined

  736. neshtaxmpp has left

  737. alexis has joined

  738. jcbrand has joined

  739. alexis has left

  740. alexis has joined

  741. alameyo has left

  742. alameyo has joined

  743. winfried has left

  744. winfried has joined

  745. winfried has left

  746. winfried has joined

  747. lorddavidiii has left

  748. winfried has left

  749. winfried has joined

  750. debacle has joined

  751. arc has left

  752. arc has joined

  753. alexis has left

  754. thorsten has left

  755. arc has left

  756. arc has joined

  757. arc has left

  758. arc has joined

  759. krauq has left

  760. krauq has joined

  761. wurstsalat has left

  762. Tobias has left

  763. alexis has joined

  764. stpeter has joined

  765. stpeter has left

  766. Shell has left

  767. Shell has joined

  768. alexis has left

  769. neshtaxmpp has joined

  770. alexis has joined

  771. arc has left

  772. arc has joined

  773. arc has left

  774. arc has joined

  775. Mikaela has left

  776. Vaulor has left

  777. mukt2 has left

  778. thorsten has joined

  779. arc has left

  780. arc has joined

  781. neshtaxmpp has left

  782. lskdjf has left

  783. krauq has left

  784. alexis has left

  785. jcbrand has left

  786. alexis has joined

  787. debacle has left

  788. sonny has left

  789. mukt2 has joined

  790. krauq has joined

  791. alexis has left

  792. arc has left

  793. arc has joined

  794. sonny has joined

  795. sonny has left

  796. sonny has joined

  797. neshtaxmpp has joined

  798. alexis has joined

  799. bear has left

  800. neshtaxmpp has left

  801. sonny has left

  802. sonny has joined

  803. alameyo has left

  804. alameyo has joined

  805. neshtaxmpp has joined

  806. krauq has left

  807. krauq has joined

  808. emus has left

  809. Maranda has left

  810. sonny has left

  811. sonny has joined