XSF Discussion - 2021-03-24

  1. arc has left
  2. arc has joined
  3. jcbrand has left
  4. ajeremias has joined
  5. stp has joined
  6. neshtaxmpp has left
  7. BASSGOD has left
  8. BASSGOD has joined
  9. dwd has left
  10. arc has left
  11. LNJ has left
  12. stp has left
  13. Calvin has joined
  14. stp has joined
  15. Andrzej has joined
  16. Calvin has left
  17. menel has left
  18. stp has left
  19. ajeremias has left
  20. Andrzej has left
  21. lskdjf has left
  22. Alex has left
  23. debacle has left
  24. wurstsalat has left
  25. Andrzej has joined
  26. lux39 has joined
  27. lux39 has left
  28. neshtaxmpp has joined
  29. Andrzej has left
  30. Kev has left
  31. Kev has joined
  32. BASSGOD has left
  33. BASSGOD has joined
  34. karoshi has left
  35. lux39 has joined
  36. wladmis has left
  37. wladmis has joined
  38. Andrzej has joined
  39. BASSGOD has left
  40. BASSGOD has joined
  41. Andrzej has left
  42. govanify has left
  43. govanify has joined
  44. govanify has left
  45. govanify has joined
  46. Yagiza has joined
  47. Kev has left
  48. Kev has joined
  49. Kev has left
  50. Kev has joined
  51. lux39 has left
  52. lux39 has joined
  53. yushyin has left
  54. aidalgol has left
  55. croax has joined
  56. BASSGOD has left
  57. govanify has left
  58. govanify has joined
  59. BASSGOD has joined
  60. yushyin has joined
  61. lux39 has left
  62. govanify has left
  63. govanify has joined
  64. adiaholic has joined
  65. Andrzej has joined
  66. lux39 has joined
  67. DebXWoody has joined
  68. dwd has joined
  69. Andrzej has left
  70. Tobias has joined
  71. andy has joined
  72. adiaholic has left
  73. Andrzej has joined
  74. adiaholic has joined
  75. adiaholic has left
  76. adiaholic has joined
  77. aidalgol has joined
  78. fuana has left
  79. emus has left
  80. pasdesushi has joined
  81. emus has joined
  82. ti_gj06 has joined
  83. pasdesushi has left
  84. pasdesushi has joined
  85. menel has joined
  86. Andrzej has left
  87. pasdesushi has left
  88. neshtaxmpp has left
  89. wurstsalat has joined
  90. alameyo has left
  91. jcbrand has joined
  92. marek has joined
  93. Kev has left
  94. Kev has joined
  95. Kev has left
  96. Kev has joined
  97. Kev has left
  98. Kev has joined
  99. ti_gj06 has left
  100. Vaulor has joined
  101. Seve has joined
  102. adiaholic has left
  103. flow has joined
  104. Syndace has left
  105. Syndace has joined
  106. Alex has joined
  107. DebXWoody has left
  108. mathijs has left
  109. mathijs has joined
  110. DebXWoody has joined
  111. DebXWoody has left
  112. lovetox has left
  113. Syndace has left
  114. Syndace has joined
  115. lovetox has joined
  116. paul has left
  117. paul has joined
  118. paul has left
  119. paul has joined
  120. Andrzej has joined
  121. govanify has left
  122. govanify has joined
  123. eric has left
  124. ti_gj06 has joined
  125. eric has joined
  126. govanify has left
  127. govanify has joined
  128. eevvoor has joined
  129. jcbrand has left
  130. jcbrand has joined
  131. millesimus has left
  132. millesimus has joined
  133. marc has joined
  134. APach has left
  135. APach has joined
  136. Syndace has left
  137. Syndace has joined
  138. bean has joined
  139. goffi has joined
  140. stp has joined
  141. alameyo has joined
  142. karoshi has joined
  143. goffi has left
  144. alameyo has left
  145. stp has left
  146. stp has joined
  147. goffi has joined
  148. floretta has left
  149. purplebeetroot has joined
  150. neshtaxmpp has joined
  151. APach has left
  152. APach has joined
  153. ajeremias has joined
  154. goffi has left
  155. peetah has left
  156. peetah has joined
  157. floretta has joined
  158. debacle has joined
  159. APach has left
  160. Syndace has left
  161. Syndace has joined
  162. purplebeetroot has left
  163. LNJ has joined
  164. lskdjf has joined
  165. DebXWoody has joined
  166. govanify has left
  167. govanify has joined
  168. govanify has left
  169. govanify has joined
  170. mdosch has left
  171. mdosch has joined
  172. chronosx88 has left
  173. chronosx88 has joined
  174. ajeremias has left
  175. purplebeetroot has joined
  176. aidalgol has left
  177. Syndace has left
  178. Syndace has joined
  179. purplebeetroot has left
  180. DebXWoody has left
  181. ajeremias has joined
  182. stp has left
  183. stp has joined
  184. purplebeetroot has joined
  185. chronosx88 has left
  186. chronosx88 has joined
  187. ti_gj06 has left
  188. purplebeetroot has left
  189. goffi has joined
  190. Maranda has left
  191. deuill has left
  192. deuill has joined
  193. chronosx88 has left
  194. chronosx88 has joined
  195. purplebeetroot has joined
  196. Kev has left
  197. deuill has left
  198. Maranda has joined
  199. deuill has joined
  200. purplebeetroot has left
  201. deuill has left
  202. deuill has joined
  203. chronosx88 has left
  204. chronosx88 has joined
  205. Kev has joined
  206. deuill has left
  207. deuill has joined
  208. Andrzej has left
  209. Andrzej has joined
  210. Tobias has left
  211. Tobias has joined
  212. Andrzej has left
  213. Andrzej has joined
  214. ti_gj06 has joined
  215. Andrzej has left
  216. Andrzej has joined
  217. govanify has left
  218. govanify has joined
  219. DebXWoody has joined
  220. govanify has left
  221. govanify has joined
  222. Andrzej has left
  223. Andrzej has joined
  224. fuana has joined
  225. Andrzej has left
  226. Andrzej has joined
  227. Andrzej has left
  228. Andrzej has joined
  229. Andrzej has left
  230. Andrzej has joined
  231. fuana has left
  232. deuill has left
  233. floretta has left
  234. chronosx88 has left
  235. chronosx88 has joined
  236. deuill has joined
  237. fuana has joined
  238. fuana has left
  239. fuana has joined
  240. chronosx88 has left
  241. chronosx88 has joined
  242. chronosx88 has left
  243. chronosx88 has joined
  244. lux39 has left
  245. inky has left
  246. alacer has left
  247. alacer has joined
  248. inky has joined
  249. fuana has left
  250. alameyo has joined
  251. chronosx88 has left
  252. chronosx88 has joined
  253. fuana has joined
  254. alameyo has left
  255. Andrzej has left
  256. Andrzej has joined
  257. chronosx88 has left
  258. chronosx88 has joined
  259. peetah has left
  260. peetah has joined
  261. Kev has left
  262. Kev has joined
  263. fuana has left
  264. Andrzej has left
  265. Andrzej has joined
  266. Syndace has left
  267. Syndace has joined
  268. ajeremias has left
  269. fuana has joined
  270. deuill has left
  271. deuill has joined
  272. ajeremias has joined
  273. Guus has joined
  274. fuana has left
  275. fuana has joined
  276. ajeremias has left
  277. Syndace has left
  278. Syndace has joined
  279. Freddy has left
  280. fuana has left
  281. fuana has joined
  282. ajeremias has joined
  283. deuill has left
  284. Freddy has joined
  285. deuill has joined
  286. Andrzej has left
  287. Andrzej has joined
  288. Andrzej has left
  289. floretta has joined
  290. Andrzej has joined
  291. Sam Is there a reason XEP-0013 isn't yet deprecated? It's not entirely the same thing as MAM, but it doesn't seem worth keeping around
  292. Holger Sam: Some clients actually use it to disable offline delivery in favor of MAM.
  293. Sam And XEP-0160 for that matter
  294. Holger I.e. to avoid some dedup.
  295. MattJ Which is a total hack
  296. Ge0rG The interop between offline messages and MAM and a seamless transition between MAM and live message delivery is still unsolved.
  297. fuana has left
  298. Sam Not deprecating this doesn't help solve it.
  299. Holger kk wasn't aware we have proper solutions rather than hacks now 🙂
  300. Ge0rG Wait, it's a somewhat deployed solution to one part of the problem space.
  301. Sam Especially if clients are using this as a hacky work around, it seems like we should start discourating it
  302. Holger In favor of what?
  303. Sam In favor of just using MAM and if it doesn't meet your needs you should write a new thing or update MAM instead of relying on hacks.
  304. Zash You still get a burst of offline messages then
  305. Sam Maybe this should be considered during MAM advancement discussion then. Leaving these out of the discussion doesn't seem great
  306. Sam But as always: discouraging people from using old hacks doesn't immediately make all clients remove them entirely.
  307. Holger Sam: The use case I mentioned was for MAM clients.
  308. Sam It just means we move it to deprecated and recommend that people come up with a new way to do things.
  309. Sam Holger: yes, it just seems like a hack we shouldn't encourage
  310. Ge0rG feels inclined to recite old standards@ threads.
  311. Holger If we tell client devs not to use 0013 they'll ask what to do instead.
  312. Holger Just receive the spam and dedup?
  313. Sam Good, that's a good thing for them to be asking and for us to think about
  314. Holger Works but doesn't seem less hacky to me. L
  315. MattJ Holger, well it's doing that for Prosody servers anyway. right?
  316. Holger Works but doesn't seem less hacky to me.
  317. Kev (The answer is to not send offline messages when using bind2, IMO)
  318. Holger MattJ: Yes. Works but not less hacky.
  319. MattJ And I'd like the server to solve this by not sending offline messages to modern clients
  320. MattJ Whether that's bind2 or not I don't know, bind2 is perpetually beyond our reach
  321. Kev (Or bind3, or whatever we end up using)
  322. Ge0rG Kev: bindIM2.0
  323. Zash What about messages that end up in the offline store, but not in MAM?
  324. MattJ bind2 would be the easiest fix to a whole range of problems
  325. Zash (and why‽)
  326. Sam Yah, I could see this belonging in MAM or in Bind2
  327. MattJ and by bind2 I actually mean "any replacement for the current resource binding step"
  328. Holger I know you guys all have nice solutions in your mind. What I don't get is how it helps to deprecate existing solutions *before* we have new ones.
  329. Kev Holger: I’m not saying they do.
  330. Sam I absolutely think they do. Nobody bothers to make fixes as long as there's some old hacky solution available
  331. Kev I’m just saying how I think we should solve the use case.
  332. MattJ Holger, XEP-0013 isn't implemented by more than half of deployed servers anyway, and that's unlikely to change. So either it works without XEP-0013 already, or we're no worse off...
  333. Sam If we deprecate, it doesn't break any existing thing, it just encourages new solutions to be put forward
  334. Sam Also what MattJ said
  335. Holger MattJ: Then let's deprecate everything that's not in ejabberd right now as well 🙂
  336. Holger MIX!
  337. Sam And it makes it less likely that new clients accidentally implement an old thing because MAM has scary red text at the front and this has nice green draft text
  338. Sam We can debate where to draw that line (ie. MUC is widely implemented, maybe we can't just get rid of that and say "do MIX"), but this just seems confusing and it's not like a ton of things implement it as Matt pointed out
  339. MattJ Holger, that's not what I'm saying, of course. Just that you're positioning XEP-0013 as necessary, when it clearly is not.
  340. MattJ Though sign me up for MIX deprecation :D
  341. MattJ (joking)
  342. MattJ (I think)
  343. Sam Anyways, I think this discussion is already helpful and should be part of the council's discussion when the MAM LC is over, that's all I'm saying. Council, please consider that this is related to the MAM LC and might be a thing worth considering :)
  344. Holger > Holger, that's not what I'm saying, of course. Just that you're positioning XEP-0013 as necessary, when it clearly is not. It's not necessary, just an optimization. Like e.g. 0198.
  345. Kev I don’t think it actually affects MAM advancement.
  346. Holger And I think optimizations are legit.
  347. Kev (Which doesn’t mean Council can’t think about it, I just don’t think it’s pertinent)
  348. Sam As always, I think it's confusing to have two things that both appear to be recommended and have significant overlap in functionality, and therefore it does affect MAM advancement in my mind.
  349. Ge0rG Well, it might be an optimization, but using 0013 might also create a hole between MAM sync and live traffic, depending on things the client developer forgot to thoroughly think about
  350. Sam Also if parts of this are needed in MAM, we should not advance MAM, so I think it's relevant in that way.
  351. Sam (although I tend to agree this makes more sense in bind2)
  352. MattJ I agree with Kev that MAM is unaffected
  353. Sam Fair, if council doesn't think they're related that's fine. Either way, please consider this a request to discuss deprecating 0013 and 0160
  354. MattJ Offline messages are technically not really standardized anywhere (XEP-0160 is the closest, an attempt to document them after the fact)
  355. krauq has left
  356. krauq has joined
  357. Sam (0160 seems like it's useful, just *very* outdated since it doesn't even mention MAM)
  358. Holger > Nobody bothers to make fixes as long as there's some old hacky solution available Like nobody bothers to make fixes rude the old hacky solution is deprecated. Where's that XEP that does stranger blocking now that 0016 is deprecated again?
  359. Holger > Nobody bothers to make fixes as long as there's some old hacky solution available Like nobody bothers to make fixes when the old hacky solution is deprecated. Where's that XEP that does stranger blocking now that 0016 is deprecated again?
  360. Zash If it works, don't fix it!
  361. Zash (they said about the broken mess)
  362. peetah has left
  363. peetah has joined
  364. Sam That's a perfect example. We have a better solution, it solves the 90% use case, if Process one is still using privacy lists, that's fine but we no longer have a confusing situation.
  365. Freddy has left
  366. deuill has left
  367. Holger We have the situation that XMPP just doesn't support a use case some are interested in.
  368. Holger Because we had to deprecate the existing solution in favor of a non existing one.
  369. Sam Who's interested in it? As far as I can tell it's like 2 people and they're both just using the old thing, which is fine.
  370. Holger I've been asked more than once how you'd implement that.
  371. Holger Haha.
  372. Sam So write an XEP for it.
  373. Holger We had one.
  374. deuill has joined
  375. Sam Yes, one that had confusing overlap with another spec and which made it trivial to shoot yourself in the foot and tried to everything under the sun instead of just "block strangers" if that's the functionality from it you need.
  376. Holger I've been told we don't need it because someone will write a simpler one. I never said I'll do that.
  377. Sam Good, don't, keep using the old thing until someone else writes one then.
  378. Holger Now I'm being told the functionality is no longer needed, yay.
  379. Sam It's not needed IMO, if it were more people would be interested in writing a replacement.
  380. Holger So I'll tell client devs to ignore the depreciation.
  381. Kev I think lots of people use the feature, it’s just not standardised any more and is either by server configuration or adhoc command.
  382. Nekit has joined
  383. Holger What's the point of the depreciation then?
  384. Kev I might be wrong, but it’s the impression I get.
  385. Sam That's fine, if that's what you have to do that's what you have to do. Deprecation doesn't mean you're instantly barred from implementing forever, it means we don't recommend this solution.
  386. Holger I'm asking why we stop recommending a solution before coming up with an alternative.
  387. Sam Because those two things don't have anything to do with one another, and as long as we're recommending a soultion there will never be an alternative.
  388. Holger I don't get that logic at all.
  389. Sam I'm not saying an alternative will appear immediately if we stop recommending it. I am saying that there's no chance of getting one if we continue recommending it.
  390. Holger If someone thinks a solution is suboptimal he should provide a better alternative. Rather than ditching it and telling others to do that if they needed the functionality.
  391. Kev I think that’s been demonstrably untrue through XMPP’s history, FWIW. 191 came about before 16 went away, it just missed a bit (accidentally, I suspect). 313 136, etc. etc.
  392. flow What Holger says
  393. Kev (My comment refers to never having alternatives while the original is around)
  394. Sam Also that (in the case of privacy lists) continuing to recommend them was harmful. They overlapped with blocking command, so we had the situation where some things used one and some used another and the XMPP network wasn't compatible if you switched clients.
  395. Sam And also privacy lists would cause you to shoot yourself in the foot, like the cisco phone that when I added it to my account blocked everything that didn't look like a phone number, which IMO shouldn't even be possible in a standardized way.
  396. Sam sorry, messages are significantly delayed for me, I'm typing responses then it's taking a minute to send
  397. Sam Sure, fair enough, on rare occasions it happens, but I think mostly it's been good when we've deprecated things that are old and broken regardless of whether there's a solution or not.
  398. Sam Anyways, unless we have some sort of product manager deciding what features the network must have, I don't see why the XSF has to have a recommendation for every possible feature. If we want people to take XMPP seriously again and stifle the (very valid) Matrix critisism of having too much old cruft and it being impossible to implement XMPP, we should get rid of the old cruft.
  399. Sam Sometimes there will be old cruft we really can't get rid of because it's widely used, or is an absolutely necessary feature, etc. but I don't think that's what this is.
  400. Syndace has left
  401. peetah has left
  402. Andrzej has left
  403. Syndace has joined
  404. ajeremias has left
  405. Andrzej has joined
  406. Andrzej has left
  407. Lance has joined
  408. Holger I think there's significant demand for that feature, but I don't think that matters much. If there's *any* demand for some functionality, having an extension for that makes sense.
  409. Kev I think it lives somewhere in the gray area between the two :)
  410. deuill has left
  411. marc has left
  412. fuana has joined
  413. deuill has joined
  414. emus has left
  415. marc has joined
  416. Freddy has joined
  417. Holger Right now it would be used by (and could be recommended to) quite a few users as a simple way to avoid spam, esp. if their contact list basically never changes.
  418. fuana has left
  419. Sam We can report spam without also doing lots of other harmful things. And in fact, there is a better more targeted XEP for that.
  420. Sam We can have a more targeted XEP for just blocking all users too if that's a feature people want, it just seems like the harm of recommending a giant thing with overlap that breaks across clients just to do that one thing outweighs the benefit of not having a thing in draft that does that one tiny thing you seem to actually want privacy lists for.
  421. Holger I'm aware of that XEP, it doesn't do the same thing in a better way.
  422. Holger Yes we can have it. We drive have it.
  423. Sam The point still stands. An XEP causing actual harm being kept around for one tiny feature seems like a bad tradeoff.
  424. dwd I think we need a blockchain.
  425. Zash I have a normal chain, is that enough? It holds up a lamp.
  426. Sam Maybe privacy lists does meet some threshold for that and this one doesn't, I don't know, we can discuss where to draw that line, but I'd argue that "we have to have all features at all costs" isn't a good place to draw it.
  427. eevvoor has left
  428. eevvoor has joined
  429. Holger This is just about *existing* features. Not all features.
  430. Andrzej has joined
  431. Sam Fine, "we have to keep all existing features at all costs" isn't a good place to draw it.
  432. flow no, but isntead of assuming that we can create one-size-fits-all kind of xeps, we may have to acknowledge that there could be multiple xeps for the same thing but with a different scope
  433. peetah has joined
  434. Sam I think that *can* be fine, but it definitely wasn't in this case. When gajim does one thing and conversations does another and it's not compatible so depending on which you log in with people appear blocked or not, that's a problem.
  435. fuana has joined
  436. Sam Or when a new developer tries to implement an XMPP client and there are two specs that do almost the exact same thing and they have no way to tell which they should implement, or worse, the one that nobody uses that they *definitely* shouldn't implement appears recommended and the other doesn't, that's a problem.
  437. Holger Yes.
  438. Sam And that's a much bigger problem than deprecating an XEP to provide guidance and not breaking any existing clients or servers.
  439. Holger I'm just questioning who to solve such problems.
  440. jonas’ yeah, it’s a shame that we don’t have documents which give new developers guidance about which XEPs to look at
  441. Seve has left
  442. Sam Yes, bringing back the compliance suites was one thing I tried to do to solve those problems, it can't do it on its own though.
  443. Ge0rG Just recommend the Compliance Suites ;)
  444. Ge0rG Sam: what's missing from compliance suites that you'd like to recommend to new developers?
  445. Sam Nothing, and I always do recommend them. But not everyone will find the compliance suties, and the XSF recommending broken products with significant overlap still causes harm.
  446. Sam Well, I mean, I dunno if things are missing or not, I just see them as only part of the solution.
  447. Ge0rG So the solution to this problem is: make the Compliance Suites more prominent
  448. fuana has left
  449. ajeremias has joined
  450. dwd We've discussed putting the current compliance suite prominently on the website, potentially even in a different format so it's nice and simple to read.
  451. Holger FWIW I'm all with Sam that overlapping solutions is one of the most severe issues with our specs …
  452. mathijs has left
  453. arc has joined
  454. dwd XEP-0136 forever?
  455. arc 😏
  456. BASSGOD has left
  457. fuana has joined
  458. mathijs has joined
  459. neshtaxmpp has left
  460. Freddy has left
  461. Seve has joined
  462. Tobias has left
  463. Tobias has joined
  464. BASSGOD has joined
  465. BASSGOD has left
  466. fuana has left
  467. fuana has joined
  468. neshtaxmpp has joined
  469. arc Well apparently the meeting isn't happening today either
  470. APach has joined
  471. moparisthebest jots down who to fire at next board election
  472. moparisthebest I KID I KID :)
  473. pasdesushi has joined
  474. dwd I'm here, actually.
  475. Zash MattJ, ralphm?
  476. dwd Obviously moparisthebest can fire me anyway.
  477. Kev has left
  478. Kev has joined
  479. BASSGOD has joined
  480. arc An email went out to the board list but no action has been taken on it yet
  481. pasdesushi has left
  482. Wojtek has joined
  483. alex-a-soto has left
  484. MattJ This slot continues to be one of the worst possible in my entire week, my inability to attend should not be a surprise by now :)
  485. arc has left
  486. arc has joined
  487. MattJ I filled out the poll last week, I don't know if everyone has yet
  488. fuana has left
  489. fuana has joined
  490. APach has left
  491. marc has left
  492. marc has joined
  493. marc has left
  494. marc has joined
  495. marc has left
  496. marc has joined
  497. mathijs has left
  498. mathijs has joined
  499. BASSGOD has left
  500. BASSGOD has joined
  501. jonas’ looks like 3 people filled it out so far
  502. MattJ arc, looks like you haven't filled out the poll yet?
  503. arc I am the easy one 🤣
  504. Alex has left
  505. Alex has joined
  506. MattJ Sarcasm? :)
  507. ralphm Cool, with 4 out of 5 it seems the best availability is on April 1.
  508. Freddy has joined
  509. ralphm Oh, wait, 4 out of 4.
  510. arc I'm the easy one because I'm just generally available after 9:00 a.m. Pacific
  511. arc And they can be available even earlier than that if that works better for most people
  512. arc I'm just not very generally functional before my first tea
  513. BASSGOD has left
  514. ralphm So, if we'd retry this tomorrow at 17:00 UTC and then 16:00 UTC after the DST change coming weekend, would that work?
  515. ralphm arc: also whooosh
  516. MattJ wfm
  517. arc Wfm
  518. APach has joined
  519. fuana has left
  520. fuana has joined
  521. APach has left
  522. marc has left
  523. APach has joined
  524. ralphm Ok, modified the calendar accordingly
  525. APach has left
  526. APach has joined
  527. chronosx88 has left
  528. chronosx88 has joined
  529. arc has left
  530. arc has joined
  531. Guus has left
  532. BASSGOD has joined
  533. ti_gj06 has left
  534. fuana has left
  535. fuana has joined
  536. marc has joined
  537. ti_gj06 has joined
  538. werdan has joined
  539. Wojtek has left
  540. BASSGOD has left
  541. nad200 has joined
  542. arcxi has left
  543. arcxi has joined
  544. fuana has left
  545. fuana has joined
  546. BASSGOD has joined
  547. arcxi has left
  548. arcxi has joined
  549. arcxi has left
  550. arcxi has joined
  551. arcxi has left
  552. arcxi has joined
  553. arcxi has left
  554. arcxi has joined
  555. arcxi has left
  556. arcxi has joined
  557. arcxi has left
  558. arcxi has joined
  559. arcxi has left
  560. fuana has left
  561. arcxi has joined
  562. arcxi has left
  563. arcxi has joined
  564. arcxi has left
  565. arcxi has joined
  566. werdan has left
  567. marc has left
  568. marc has joined
  569. nad200 has left
  570. BASSGOD has left
  571. ajeremias has left
  572. Freddy has left
  573. emus has joined
  574. Freddy has joined
  575. Andrzej has left
  576. Daniel has left
  577. BASSGOD has joined
  578. emus has left
  579. Daniel has joined
  580. alex-a-soto has joined
  581. andrey.g has joined
  582. Yagiza has left
  583. marc has left
  584. BASSGOD has left
  585. bean has left
  586. bean has joined
  587. nad200 has joined
  588. ajeremias has joined
  589. pjn has left
  590. BASSGOD has joined
  591. sonny has left
  592. sonny has joined
  593. pjn has joined
  594. nad200 has left
  595. marc has joined
  596. sonny has left
  597. sonny has joined
  598. pjn has left
  599. menel has left
  600. arc has left
  601. arc has joined
  602. arc has left
  603. arc has joined
  604. mathijs has left
  605. pjn has joined
  606. Freddy has left
  607. marc has left
  608. Freddy has joined
  609. pjn has left
  610. pjn has joined
  611. marc has joined
  612. mathijs has joined
  613. admin103 has joined
  614. deuill has left
  615. admin103 has left
  616. deuill has joined
  617. eevvoor has left
  618. eevvoor has joined
  619. moparisthebest 1. how *should* an XMPP server handle non-XML junk sent from a client after bind 2. how do existing XMPP servers *actually* handle that in the wild?
  620. Zash Like, text content between stanzas?
  621. moparisthebest for #2 prosody seems to silently ignore it, it'll deliver stanzas sent after said junk just fine
  622. moparisthebest yep
  623. Zash Yeah, goes into the same void as whitespace keepalives.
  624. nad200 has joined
  625. L29Ah any reason for whitespace keepalives, except "my tcp implementation lacks SO_KEEPALIVE"?
  626. flow L29Ah, I don't think so
  627. moparisthebest many a fun firewall exists that doesn't care about your SO_KEEPALIVE
  628. Kev Well, there’s also detecting dead sessions.
  629. flow L29Ah, the question is if you don't want to use xmpp ping or SM's <r/> for keepalive
  630. aidalgol has joined
  631. flow "if session idle for X minutes, then send xmpp ping to server" is what i usually do
  632. Zash Someone should make a diagram of what parts of the stack is appropriate for TCP keepalives, whitespace keepalives, xep-0199, xep-0198 <r/> ...
  633. L29Ah moparisthebest: do they just drop empty-data tcp packets for the fun of it?
  634. moparisthebest yes, except they sell it as a feature "traffic optimization"
  635. moparisthebest they'll also silently drop your TCP connection and not bother sending you a RST on each side, so you both think you are still connected to each other, hence Kev 's "detecting dead sessions"
  636. nad200 has left
  637. Zash Do TCP stacks even let you send empty packets?
  638. BASSGOD has left
  639. moparisthebest well I'm assuming inside TLS here, so it's never empty
  640. flow L29Ah, I probably don't have to say that, but please take session idle time into account for keep alive mechanisms, do not simply do periodic sends
  641. Zash OH! There's also TLS heartbleed packets :D
  642. flow or tcp out of band data
  643. L29Ah flow: that SO_KEEPALIVE cares for, but whitespace stuff needs to do it explicitly :/
  644. flow L29Ah, right, but it's not rocket science i'd say :)
  645. menel has joined
  646. Zash This gets more fun if you have proxies involved.
  647. Zash Like, say, all those sslh setups people use to share port 443 with their web server.
  648. Zash or websocket proxied trough some reverse proxy
  649. L29Ah pontarius-xmpp doesn't care about it yet
  650. bean has left
  651. BASSGOD has joined
  652. emus has joined
  653. goffi has left
  654. ajeremias has left
  655. ajeremias has joined
  656. pjn has left
  657. pjn has joined
  658. emus has left
  659. moparisthebest Neustradamus: https://tools.ietf.org/html/rfc8996 you should get all the servers and clients to implement this, also public servers :)
  660. emus has joined
  661. emus has left
  662. emus has joined
  663. emus has left
  664. emus has joined
  665. emus has left
  666. ajeremias has left
  667. emus has joined
  668. ajeremias has joined
  669. emus has left
  670. peetah has left
  671. peetah has joined
  672. marek has left
  673. Tobias has left
  674. Neustradamus moparisthebest: Nice! Sam will must to know it ah ah
  675. marc has left
  676. marc has joined
  677. marc has left
  678. moparisthebest they pull no punches language-wise: > TLS 1.0 MUST NOT be used. Negotiation of TLS 1.0 from any version of TLS MUST NOT be permitted. > TLS 1.1 MUST NOT be used. Negotiation of TLS 1.1 from any version of TLS MUST NOT be permitted.
  679. wurstsalat has left
  680. andy has left
  681. pjn has left
  682. Neustradamus MattJ: https://www.ssllabs.com/ssltest/analyze.html?d=jabber.org
  683. pjn has joined
  684. alameyo has joined
  685. bean has joined
  686. benharri has left
  687. paul has left
  688. benharri has joined
  689. Kev has left
  690. Kev has joined
  691. ajeremias has left
  692. karoshi has left
  693. peetah has left
  694. peetah has joined
  695. peetah has left
  696. peetah has joined
  697. ajeremias has joined
  698. peetah has left
  699. peetah has joined
  700. peetah has left
  701. peetah has joined
  702. deuill has left
  703. deuill has joined
  704. peetah has left
  705. peetah has joined
  706. Syndace has left
  707. Syndace has joined
  708. ajeremias has left
  709. debacle has left