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