XSF Discussion - 2020-08-26

  1. Andrzej has joined

  2. emus has left

  3. neshtaxmpp has joined

  4. mukt2 has left

  5. winfried has left

  6. winfried has joined

  7. waqas has joined

  8. amuza@riseup.net has left

  9. Lance has joined

  10. LNJ has left

  11. LNJ has joined

  12. LNJ has left

  13. alameyo has left

  14. Seve has joined

  15. Andrzej has left

  16. Half-Shot has left

  17. uhoreg has left

  18. Rixon 👁🗨 has left

  19. uhoreg has joined

  20. Half-Shot has joined

  21. Rixon 👁🗨 has joined

  22. stpeter has joined

  23. stpeter has left

  24. paul has left

  25. Andrzej has joined

  26. winfried has left

  27. dwd has left

  28. winfried has joined

  29. Lance has left

  30. bear has left

  31. mdosch has left

  32. mdosch has joined

  33. bear has joined

  34. stpeter has joined

  35. stpeter has left

  36. Lance has joined

  37. Andrzej has left

  38. mukt2 has joined

  39. neshtaxmpp has left

  40. alameyo has joined

  41. neshtaxmpp has joined

  42. bear has left

  43. neshtaxmpp has left

  44. neshtaxmpp has joined

  45. Seve has left

  46. mukt2 has left

  47. neshtaxmpp has left

  48. bear has joined

  49. mukt2 has joined

  50. Andrzej has joined

  51. Yagiza has joined

  52. stpeter has joined

  53. stpeter has left

  54. mukt2 has left

  55. Andrzej has left

  56. DebXWoody has joined

  57. govanify has left

  58. govanify has joined

  59. Seve has joined

  60. dwd has joined

  61. mukt2 has joined

  62. murabito has left

  63. Tobias has joined

  64. adiaholic_ has left

  65. adiaholic_ has joined

  66. murabito has joined

  67. mukt2 has left

  68. mukt2 has joined

  69. krauq has left

  70. krauq has joined

  71. alameyo has left

  72. eevvoor has joined

  73. krauq has left

  74. krauq has joined

  75. waqas has left

  76. waqas has joined

  77. lorddavidiii has joined

  78. lovetox has joined

  79. alameyo has joined

  80. eevvoor has left

  81. eevvoor has joined

  82. APach has joined

  83. mimi89999 has left

  84. mimi89999 has joined

  85. lovetox has left

  86. Andrzej has joined

  87. APach has left

  88. lovetox has joined

  89. mukt2 has left

  90. mukt2 has joined

  91. papatutuwawa has joined

  92. Andrzej has left

  93. APach has joined

  94. lovetox has left

  95. sonny has left

  96. Daniel has left

  97. Daniel has joined

  98. sonny has joined

  99. sonny has left

  100. Mikaela has joined

  101. paul has joined

  102. lovetox has joined

  103. sonny has joined

  104. lovetox has left

  105. sonny has left

  106. krauq has left

  107. krauq has joined

  108. sonny has joined

  109. lorddavidiii has left

  110. alameyo has left

  111. alameyo has joined

  112. Daniel has left

  113. Daniel has joined

  114. karoshi has joined

  115. bear has left

  116. lovetox has joined

  117. LNJ has joined

  118. sonny has left

  119. sonny has joined

  120. sonny has left

  121. sonny has joined

  122. sonny has left

  123. sonny has joined

  124. moparisthebest has left

  125. lorddavidiii has joined

  126. Seve has left

  127. Vaulor has left

  128. floretta has left

  129. Seve has joined

  130. floretta has joined

  131. flow has joined

  132. jcbrand has joined

  133. sonny has left

  134. alameyo has left

  135. alameyo has joined

  136. sonny has joined

  137. waqas has left

  138. sonny has left

  139. sonny has joined

  140. sonny has left

  141. sonny has joined

  142. sonny has left

  143. sonny has joined

  144. Andrzej has joined

  145. rion has joined

  146. sonny has left

  147. sonny has joined

  148. rion

    https://github.com/xsf/xeps/pull/905 can council review this wrt stpeter comment?

  149. Andrzej has left

  150. jonas’

    rion, sorry, I missed this

  151. jonas’

    after stpeters approval, this is just a matter of Editors, since this spec is still Experimental/Deferred

  152. jonas’

    rion, can you ping me (@horazont) in the PR so that I get an explicit email from it?

  153. rion

    jonas’: done

  154. jonas’

    thank you

  155. jonas’

    rion, can you also update the revision block with a more recent date to reduce confusion?

  156. jonas’

    (please do so by amending the commit, do not create a new commit changing the date, otherwise I’ll have to rewrite that)

  157. emus has joined

  158. neshtaxmpp has joined

  159. marc has joined

  160. esil has joined

  161. esil has left

  162. sonny has left

  163. sonny has joined

  164. rion

    jonas’: force-pushed

  165. sonny has left

  166. marc has left

  167. sonny has joined

  168. jonas’


  169. debacle has joined

  170. Andrzej has joined

  171. karoshi has left

  172. karoshi has joined

  173. Andrzej has left

  174. Andrzej has joined

  175. Vaulor has joined

  176. marc0s has left

  177. marc0s has joined

  178. mukt2 has left

  179. sonny has left

  180. papatutuwawa has left

  181. APach has left

  182. mukt2 has joined

  183. Dele Olajide has joined

  184. debacle has left

  185. sonny has joined

  186. Andrzej has left

  187. Andrzej has joined

  188. Andrzej has left

  189. krauq has left

  190. krauq has joined

  191. sonny has left

  192. mukt2 has left

  193. mukt2 has joined

  194. sonny has joined

  195. Andrzej has joined

  196. lovetox has left

  197. debacle has joined

  198. mukt2 has left

  199. lovetox has joined

  200. sonny has left

  201. krauq has left

  202. krauq has joined

  203. marc has joined

  204. Holger

    So the reason to have the server do all this ping and MAM dance rather than just having the client ping the MUC is filtering push notifications based on nick mentions?

  205. Steve Kille has left

  206. eta

    Holger: that's one reason

  207. Steve Kille has joined

  208. Holger

    Which obviously only works for unencrypted MUC. And then you need additional protocol for making that configurable?

  209. eta

    Holger: it's a bad thing if clients have to implement a bunch of retry logic

  210. eta

    the XEP I'm writing doesn't actually address push

  211. eta

    it's mainly about keeping clients in the MUC in the face of disruption

  212. APach has joined

  213. eta

    also, mobile clients can't retry if the phone is in deep sleep

  214. Holger

    About keeping them? I thought it was about detecting kicks that got unnoticed due to TCP fuckup?

  215. Ge0rG

    eta: what about having a client register for XEP-0357 on a MUC if it wants to stay inside?

  216. eta

    Holger: it also handles MUC service restarts

  217. Holger

    By auto-rejoining?

  218. Zash

    The MUC model is client-based, so the client doing stuff fits.

  219. Ge0rG

    and when that specific full JID falls out of the MUC, it will be push-pinged?

  220. eta

    Ge0rG: that requires server support

  221. eta

    and doesn't work if there's no s2s at the time of the disruption

  222. eta

    s/server/MUC service/

  223. eta

    Holger: yeah

  224. Ge0rG

    eta: if there is no s2s, nothing will work

  225. eta

    and either asking the client to handle MAM, or doing it for the client in some cases

  226. eta

    Ge0rG: well the client's server polling until s2s comes back will :p

  227. eta

    Holger: basically the client can just join a MUC and never get kicked out, if this spec is implemented

  228. eta

    (well, unless the server gives up after an extended period)

  229. Holger

    As long as the 0198 session is alive, you mean. (Which can't be kept alive if the mobile client cannot be push-woken out of its deep sleep.)

  230. eta

    Holger: well that's why the server also always keeps a resource joined that it controls

  231. Holger


  232. eta

    so then a follow up XEP can use that connection to do push things :p

  233. eta

    why is that eww?

  234. Holger

    Well I should read the spec.

  235. eta

    Holger: I should write the spec 😉

  236. eta

    I'll fill out the design considerations section with some rationale

  237. sonny has joined

  238. winfried has left

  239. winfried has joined

  240. winfried has left

  241. winfried has joined

  242. sonny has left

  243. Ge0rG

    eta: a user's server could act as a XEP-0045 bouncer without any protocol changes; it just needs to define how joined channels are maintained, e.g. by using the bookmark autojoin flag

  244. eta

    Ge0rG: there aren't really any protocol changes :)

  245. Ge0rG

    eta: so the user's server would join all the user's MUCs under a specailly crafted resource, and keep track of which clients join/leave the MUC

  246. Ge0rG

    no more multiple copies of MUC-PMs, all the benefits. Somebody just needs to write it

  247. eta

    Ge0rG: hmm, but multiplexing multiple resources into one sounds more complicated

  248. Ge0rG

    eta: not so much really

  249. Ge0rG

    a MUC has to do that for multi-session nicks already

  250. eta

    more to the point, it somewhat breaks things like transports that do per-resource history

  251. eta

    and now introduces fun questions about whether the server has to keep a MAM archive

  252. Zash

    Ge0rG: Pretty sure the server could use the bare JID to join.

  253. Ge0rG

    per-resource history is horrible anyway

  254. Ge0rG

    Zash: maybe, maybe not

  255. eta


  256. Steve Kille has left

  257. Ge0rG

    eta: so many reasons, I can't even start.

  258. Zash

    That's what that experimental "minimix" thing does and I'm pretty sure it didn't break everything

  259. Ge0rG

    There was a bunch of issues on the biboumi tracker related to that

  260. eta

    Ge0rG: I mean, that's one way you could implement this XEP, btw

  261. Steve Kille has joined

  262. eta

    like I don't think the client has to care about whether it's one resource or multiple on the server side

  263. eta

    we can add that in as a "Servers MAY choose to only join one resource" or something

  264. eta

    I'm just worried doing it that way would break assumptions in existing software

  265. Ge0rG

    I'm not following

  266. eta

    the XEP doesn't mandate you actually join each resource

  267. eta

    I mean, from the client's perspective it should appear that way

  268. sonny has joined

  269. eta

    but you're free to multiplex everything into the barejid and just join that if you like

  270. Zash

    Gets easier to distinguish server-based things if the bare JID is used, but yeah there might be some "there's always a resource" assumption in some MUC implementation.

  271. eta

    Ge0rG: (that being said, I was originally going to stipulate each resource be joined, so thanks for the suggestion)

  272. sonny has left

  273. matkor has left

  274. matkor has joined

  275. sonny has joined

  276. karoshi has left

  277. karoshi has joined

  278. sonny has left

  279. Alex

    does the XSF website deploy automatically over CD after PRs or are there additional steps required?

  280. Zash

    May require a swift kick in the Docker by iteam, unless it's been automated without me noticing (possible)

  281. sonny has joined

  282. thorsten has joined

  283. Andrzej has left

  284. Rixon 👁🗨 has left

  285. Half-Shot has left

  286. uhoreg has left

  287. uhoreg has joined

  288. Half-Shot has joined

  289. Rixon 👁🗨 has joined

  290. Andrzej has joined

  291. Andrzej has left

  292. Andrzej has joined

  293. Andrzej has left

  294. Andrzej has joined

  295. Andrzej has left

  296. Andrzej has joined

  297. Holger

    Ge0rG, eta, sorry but to me all this sounds like throwing another non-trivial pile of terrible hacks on top of MUC just to try to work around MUCs presence-basedness by pretending the client is present while its not. I think this would just open up a new can of worms to keep us busy. To me it makes way more sense to try to get rid of the presence-basedness rather than working around it. E.g. by doing 0357 on the MUC JID; or if you want to leave push to the user's server, by going for Tigase' solution of having the MUC send groupchat messages to the bare JID of offline members, so the user server can push-notify (which seems the most straightforward variant of MUC-Lite and MUC/Sub and whatnot to me).

  298. eta

    Holger: the main issue I have with that sort of solution is it requires MUC services to upgrade

  299. Holger

    eta, and you think having user servers upgrade to a version that implements an absolutely non-trivial pile of hacks is easier?

  300. eta

    Holger: define "non-trivial pile of hacks"

  301. eta

    I don't think my proposal is that terrible

  302. Holger

    Are user servers somehow easier to upgrade than MUC servers?

  303. eta

    Holger: well, your ideas also would require clients to upgrade

  304. Holger

    My other suggestion would be to spend our limited time on MIX rather than on poll-pinging MUCs, playing presence games, having servers perform MAM queries and whatnot.

  305. eta

    backwards compat is important

  306. eta

    MIX is grand, but it'll be a long time before everyone is using it

  307. eta

    and using it requires effort on behalf of all servers and clients

  308. Holger

    AFAICS the Tigase solution requires an absolutely trivial upgrade to "subscribe" with the MUC. One could probably even go without that.

  309. Holger

    Backwards compat is important but we don't break it at all by introducing optional improvements.

  310. eta

    Holger: from the user's perspective though, now they have some MUCs where push works and some MUCs where it doesn't

  311. Holger

    Everything that works today will work tomorrow with my suggestions.

  312. eta

    Holger: sure; my point is, with my suggestions, everything that works today will work better tomorrow, transparently

  313. eta

    Holger: I don't disagree with you about MUC being less than ideal :)

  314. eta

    but the pace of XMPP development is slow enough as is

  315. Holger

    Right, that's not our disagreement. We disagree on how to tackle that problem.

  316. Kev

    Often because we worry too much about compatibility with broken systems ;)

  317. Kev goes back to lurking

  318. eta

    Holger: we've had MIX / mucsub / etc for a while now though

  319. eta

    and if they'd gained traction, we wouldn't be having this conversation

  320. eta

    perhaps this is because the last chat system I tried to use was IRC, but I think there's significant value in having older clients work without requiring them to change anything

  321. Holger

    MUC/Sub & friends are non-standard extensions of vendors for their customers.

  322. Holger

    I totally agree on backwards compat being essential.

  323. eta

    Holger, well hang on, let's look at this from another angle, actually

  324. eta

    I actually don't think we're in disagreement at all

  325. eta

    because you can have both a pile of hacks for old hacky stuff and a cleaner way to do things for non legacy MUC services

  326. Holger

    I just disagree on the idea of implementing a pile of hacks to bring new functionality to clients transparently.

  327. eta


  328. Holger

    So I disagree on that we're even talking about a backwards compat issue.

  329. Andrzej has left

  330. eta

    well what about that idea do you dislike?

  331. eta

    is it the pile of hacks part, or the transparent part?

  332. Holger

    The hack part. I'm obviously all for improving things transparently if it can be done in a clean way.

  333. winfried has left

  334. winfried has joined

  335. eta


  336. sonny has left

  337. eta

    the issue is, hacks are kinda required to deal with legacy services

  338. eta

    I mean what I've written already makes some provision for doing mucsub-esque things (along the lines of "keep a list of MUC participants, and notify their servers if they drop out for whatever reason")

  339. eta

    but then you don't get the benefit if the MUC doesn't upgrade

  340. sonny has joined

  341. eta

    (I also don't think auto-rejoining is thaaat hacky :p)

  342. eta

    I guess you could split the XEP and make the hacky part optional? (at the cost of negating a lot of the benefits)

  343. Holger

    I’ve implemented tons of horrible hacks for backwards compat myself. But I’m not keen on implementing hacks to get new improvements just to avoid the requirement for the MUC service to be updated.

  344. sonny has left

  345. Holger

    What Ge0rG and you outlined did sound way more complex than just poll-pinging and auto-rejoining.

  346. Holger


  347. eta

    Holger, I mean I'm really not a fan of the whole join-using-only-one-resource thing

  348. serge90 has left

  349. serge90 has joined

  350. eta

    it's just one way to implement it, right

  351. papatutuwawa has joined

  352. sonny has joined

  353. Andrzej has joined

  354. sonny has left

  355. sonny has joined

  356. sonny has left

  357. Andrzej has left

  358. sonny has joined

  359. mdosch has left

  360. mdosch has joined

  361. Andrzej has joined

  362. Ge0rG

    Holger: there are so many trade-offs here!

  363. sonny has left

  364. eta

    how do you reference another section of an XEP

  365. eta

    (cc jonas’ as resident XEP XML expert)

  366. jonas’

    eta, of the same XEP?

  367. eta

    jonas’, yeah

  368. Ge0rG

    eta: <link url='#lists'>

  369. jonas’

    you need to put an anchor='some-unique-and-urlsafe-string' on the <sectionX/> and then you can <link url='#some-unique-and-urlsafe-string'>...</link>

  370. eta


  371. marc has left

  372. marc has joined

  373. stpeter has joined

  374. stpeter has left

  375. lorddavidiii has left

  376. eta

    can one say "This section is non-normative" in XEPs, or is that generally avoided?

  377. jonas’

    eta, what would you put there?

  378. jonas’

    (the schema is, for example, generally non-normative)

  379. eta

    jonas’, I'm describing how the way the XEP is written provides backwards compatibility

  380. Andrzej has left

  381. jonas’

    that’d be good for a Design Considerations section I pioneered in e.g. XEP-0392

  382. eta

    this part isn't really normative; I've already described that, for example, you MUST implement the compat mechanisms in XEP-0402

  383. jonas’

    go ahead please

  384. eta

    maybe I should use one of those inset box things

  385. jonas’

    eta, if it’s a longer explanation, please put it in a separate section

  386. jonas’

    eta, https://xmpp.org/extensions/xep-0392.html#design like here

  387. eta

    jonas’, it isn't really, it's more of a "just to be clear, this legacy mechanism is also expected to work, but I've already said that"

  388. sonny has joined

  389. jonas’

    I think that falls in that section, too

  390. Ge0rG

    jonas’: it would be great to have a bunch of styling examples in xep-template.xml, like boxes and stuff

  391. jonas’

    Ge0rG, go ahead

  392. Ge0rG

    but I'm the one who always struggles to find the right elements!

  393. sonny has left

  394. lorddavidiii has joined

  395. Ge0rG

    there are thirteen sections in the template and none does quite fit

  396. amuza@riseup.net has joined

  397. Andrzej has joined

  398. lorddavidiii has left

  399. Ge0rG

    > xep-template.xml:82: element p: validity error : Element code is not declared in p list of possible children When your example accidentally becomes a unit test.

  400. Ge0rG

    you can have <code> in <li> but not in <p>?!

  401. jonas’


  402. Ge0rG

    Also <code> is not what I expected.

  403. Ge0rG

    but what's <dl>?

  404. jonas’

    a definition list

  405. sonny has joined

  406. Ge0rG


  407. sonny has left

  408. vanitasvitae

    i stumbled across p being not allowed as child of li recently as well

  409. vanitasvitae

    i stumbled across p not being allowed as child of li recently as well

  410. Ge0rG

    jonas’: <cite> isn't being rendered in bold any more

  411. Ge0rG

    nowait, it's my local copy only.

  412. sonny has joined

  413. Ge0rG

    TIL that some of the XEPs contain images as embedded data:image/png;base64

  414. lorddavidiii has joined

  415. sonny has left

  416. sonny has joined

  417. sonny has left

  418. sonny has joined

  419. sonny has left

  420. Andrzej has left

  421. Andrzej has joined

  422. Andrzej has left

  423. Andrzej has joined

  424. karoshi has left

  425. karoshi has joined

  426. Yagiza has left

  427. mukt2 has joined

  428. mdosch has left

  429. mdosch has joined

  430. sonny has joined

  431. adiaholic_ has left

  432. adiaholic_ has joined

  433. sonny has left

  434. mukt2 has left

  435. sonny has joined

  436. moparisthebest has joined

  437. krauq has left

  438. krauq has joined

  439. Andrzej has left

  440. Andrzej has joined

  441. Mikaela has left

  442. Mikaela has joined

  443. sonny has left

  444. sonny has joined

  445. eta made a funny typo: "If clients attempt to send to send presence to a MUC experiencing an outrage condition, ..."

  446. sonny has left

  447. Ge0rG


  448. MattJ

    It should be possible to filter by such conditions on search.jabber.network

  449. sonny has joined

  450. sonny has left

  451. rion has left

  452. Andrzej has left

  453. karoshi has left

  454. winfried has left

  455. winfried has joined

  456. lovetox has left

  457. karoshi has joined

  458. karoshi has left

  459. Andrzej has joined

  460. lovetox has joined

  461. sonny has joined

  462. bear has joined

  463. karoshi has joined

  464. neshtaxmpp has left

  465. sonny has left

  466. sonny has joined

  467. stpeter has joined

  468. stpeter has left

  469. sonny has left

  470. mdosch has left

  471. mdosch has joined

  472. Andrzej has left

  473. karoshi has left

  474. karoshi has joined

  475. mdosch

    eta: Also you doubled 'to send'

  476. eta

    mdosch, oh, oops

  477. eta

    nice catch

  478. mdosch

    I got stuck there first and wondered why that typo is funny. 😄

  479. lovetox has left

  480. bear has left

  481. Andrzej has joined

  482. mdosch has left

  483. !XSF_Martin has left

  484. !XSF_Martin has joined

  485. Mikaela has left

  486. mdosch has joined

  487. neshtaxmpp has joined

  488. sonny has joined

  489. mdosch has left

  490. jonas’

    the duplication was on a linebreak for me so I did not notice it :D

  491. alameyo has left

  492. alameyo has joined

  493. mdosch has joined

  494. Daniel has left

  495. sonny has left

  496. Daniel has joined

  497. sonny has joined

  498. APach has left

  499. APach has joined

  500. sonny has left

  501. Andrzej has left

  502. APach has left

  503. APach has joined

  504. Andrzej has joined

  505. mdosch has left

  506. lorddavidiii has left

  507. karoshi has left

  508. bear has joined

  509. mdosch has joined

  510. Wojtek has joined

  511. sonny has joined

  512. sonny has left

  513. sonny has joined

  514. krauq has left

  515. krauq has joined

  516. sonny has left

  517. Andrzej has left

  518. krauq has left

  519. krauq has joined

  520. Andrzej has joined

  521. Nekit has left

  522. sonny has joined

  523. mdosch has left

  524. mdosch has joined

  525. sonny has left

  526. Rixon 👁🗨 has left

  527. Half-Shot has left

  528. uhoreg has left

  529. stpeter has joined

  530. uhoreg has joined

  531. Half-Shot has joined

  532. Rixon 👁🗨 has joined

  533. stpeter has left

  534. sonny has joined

  535. Wojtek has left

  536. Wojtek has joined

  537. karoshi has joined

  538. APach has left

  539. papatutuwawa has left

  540. lovetox has joined

  541. Shell has left

  542. bear has left

  543. bear has joined

  544. Shell has joined

  545. Wojtek

    eta, I was just pondering your stance (let's patch MUC instead of doing MIX) a bit and... wouldn't you say that favouring patching actually adds to the relative slow evolution of XMPP? If there is no need to move to the next thing then there is less motivation. What's more - with said Conv.Compat tester there is quite significant push for server operators to upgrade - with introduction of ext component with turn/stun the deployment reached 50% of tested servers in roughly 3 months (and then reached plateau) - whad makes you think that with MIX it wouldn't be the same?

  546. Wojtek

    one thing to consider is also migration path - there was a MUC room and then there is a MIX room - it would be nice to have some way to convert those (with members and history maybe?) and inform the user that addresses changed

  547. Steve Kille has left

  548. thorsten has left

  549. APach has joined

  550. eta

    Wojtek, my stance isn't "let's patch MUC instead of doing MIX", it's "let's patch MUC *and* do MIX"

  551. eta

    a reliable way of joining and staying in a MUC room is required, no matter whether clients use MUC or MIX, because there will always be old MUC rooms / transports people want to use

  552. eta

    it'd be entirely possible to use the backend parts of my proposal and stick a MIX frontend on them, and make a MIX-to-MUC bridge

  553. lovetox has left

  554. Ge0rG

    there are also valuable lessons for MIX to be learned from making MUC reliable.

  555. Steve Kille has joined

  556. Wojtek

    doing tho things strains our resources

  557. Wojtek

    @Ge0rG true that

  558. eta

    Wojtek, I mean writing this specification mostly strains my resources, and I wasn't going to do anything else anyway :P

  559. Wojtek

    the biggest issue here are "MAM holes"

  560. rion has joined

  561. eta

    and yeah, I agree spreading our effort across 2 things isn't great, but on the other hand joining old MUC rooms is kinda needed

  562. winfried has left

  563. winfried has joined

  564. eta

    especially if MIX has semantics where the client only has to join once and stays in, you'll need something like my specification to actually implement that in a MIX-to-MUC bridge

  565. Rixon 👁🗨 has left

  566. Half-Shot has left

  567. uhoreg has left

  568. uhoreg has joined

  569. Half-Shot has joined

  570. Rixon 👁🗨 has joined

  571. eta

    Wojtek, also, doing durable MUC doesn't really strain client developers at all

  572. neshtaxmpp has left

  573. eta

    they have to implement like one thing (and they don't really even need to do that, if they don't want to)

  574. eta

    and AFAICT the main blockers seem to be on the client side, in terms of evolving XMPP

  575. Andrzej

    eta, I suppose not for long as I'm aware of 2-3 groups working on MIX right now (client side)

  576. Wojtek

    I kinda agree, but in case of MIX in MIX-PAM user's server, upon receiving stanza which references previous stanza-id that doesn't exist locally could query the MIX server for missing messages (it's not specified now but that was the idea at last summit). And this could actually be extended on whole MAM it seems

  577. Wojtek

    on the other hand doing that in MUC semantics requires more logic on user's server to correctly maintain user's session

  578. eta

    Andrzej, oh? which? (that's pretty cool)

  579. Andrzej

    I know that there was (is?) a branch of Conversations which had some support for MIX (if I recall correctly), we at Tigase are working on iOS,Android and macOS clients with MIX and if I'm correct Kaidan is working on MIX as well

  580. eta

    oh right, yeah, I forgot about those other 2

  581. neshtaxmpp has joined

  582. Lance has left

  583. krauq has left

  584. mimi89999 has left

  585. krauq has joined

  586. Mikaela has joined

  587. bear has left

  588. mdosch has left

  589. mdosch has joined

  590. papatutuwawa has joined

  591. winfried

    Has anybody an idea how well ecdsa signed certificates are supported for s2s communication? Would saying RSA /or/ ECDSA result in any interoperability issues?

  592. moparisthebest

    if the web is anything to go by, I don't think anyone is doing ecdsa-only nowadays, some run both though

  593. moparisthebest

    winfried, as far as "would ECDSA result in interop issues" the answer is absolutely yes, we *just* had a server break s2s with xmpp.org with a DH key > 1024 which was widely fixed in 2007 when xmpp.org upgraded in 2020

  594. lovetox has joined

  595. neshtaxmpp has left

  596. moparisthebest

    of course I'd argue if you haven't upgraded your server in the last 10 years who cares if your s2s works but others have different opinions :)

  597. winfried

    moparisthebest: well, it should become part of a security norm, so 10y legacy should not be a major argument...

  598. adiaholic_ has left

  599. adiaholic_ has joined

  600. moparisthebest

    should it? I thought there were numerous problems with ECDSA and in general people were waiting for CA approval of ED25519 certs?

  601. moparisthebest

    should it? I thought there were numerous problems with ECDSA and in general people were waiting for CAB approval of ED25519 certs?

  602. mdosch has left

  603. mdosch has joined

  604. mdosch has left

  605. Lance has joined

  606. mdosch has joined

  607. mdosch has left

  608. vanitasvitae has left

  609. esil has joined

  610. esil has left

  611. vanitasvitae has joined

  612. sonny has left

  613. sonny has joined

  614. sonny has left

  615. vanitasvitae has left

  616. vanitasvitae has joined

  617. sonny has joined

  618. sonny has left

  619. sonny has joined

  620. sonny has left

  621. krauq has left

  622. krauq has joined

  623. eevvoor has left

  624. moparisthebest

    winfried, best summary I can find I guess https://community.letsencrypt.org/t/support-ed25519-and-ed448/69868

  625. sonny has joined

  626. krauq has left

  627. krauq has joined

  628. bear has joined

  629. Dele Olajide has left

  630. dwd has left

  631. sonny has left

  632. mdosch has joined

  633. Andrzej has left

  634. winfried

    moparisthebest: thanks

  635. krauq has left

  636. krauq has joined

  637. neshtaxmpp has joined

  638. sonny has joined

  639. dwd has joined

  640. mimi89999 has joined

  641. thorsten has joined

  642. thorsten has left

  643. lorddavidiii has joined

  644. Wojtek has left

  645. eevvoor has joined

  646. Wojtek has joined

  647. mdosch has left

  648. mdosch has joined

  649. Andrzej has joined

  650. eevvoor has left

  651. eevvoor has joined

  652. marc has left

  653. marc has joined

  654. eevvoor has left

  655. eevvoor has joined

  656. marc has left

  657. eevvoor has left

  658. marc has joined

  659. vanitasvitae has left

  660. Andrzej has left

  661. Lance has left

  662. sonny has left

  663. sonny has joined

  664. vanitasvitae has joined

  665. Andrzej has joined

  666. vanitasvitae has left

  667. sonny has left

  668. sonny has joined

  669. mukt2 has joined

  670. vanitasvitae has joined

  671. eevvoor has joined

  672. eevvoor has left

  673. sonny has left

  674. eevvoor has joined

  675. eevvoor has left

  676. adiaholic_ has left

  677. adiaholic_ has joined

  678. sonny has joined

  679. mdosch has left

  680. mdosch has joined

  681. mukt2 has left

  682. marc has left

  683. sonny has left

  684. sonny has joined

  685. sonny has left

  686. sonny has joined

  687. stpeter has joined

  688. stpeter has left

  689. eevvoor has joined

  690. papatutuwawa has left

  691. rion has left

  692. calvin has joined

  693. karoshi has left

  694. karoshi has joined

  695. rion has joined

  696. sonny has left

  697. sonny has joined

  698. papatutuwawa has joined

  699. sonny has left

  700. sonny has joined

  701. sonny has left

  702. sonny has joined

  703. Andrzej has left

  704. bear has left

  705. eevvoor has left

  706. sonny has left

  707. karoshi has left

  708. Daniel has left

  709. Daniel has joined

  710. sonny has joined

  711. Andrzej has joined

  712. debacle has left

  713. sonny has left

  714. karoshi has joined

  715. Lance has joined

  716. sonny has joined

  717. Andrzej has left

  718. sonny has left

  719. bear has joined

  720. karoshi has left

  721. DebXWoody has left

  722. karoshi has joined

  723. Mikaela has left

  724. lorddavidiii has left

  725. werdan has joined

  726. sonny has joined

  727. Andrzej has joined

  728. karoshi has left

  729. sonny has left

  730. sonny has joined

  731. Andrzej has left

  732. Andrzej has joined

  733. Andrzej has left

  734. Andrzej has joined

  735. mukt2 has joined

  736. Tobias has left

  737. bear has left

  738. Andrzej has left

  739. Andrzej has joined

  740. flow has left

  741. sonny has left

  742. bear has joined

  743. Andrzej has left

  744. Andrzej has joined

  745. mukt2 has left

  746. sonny has joined

  747. karoshi has joined

  748. rion has left

  749. rion has joined

  750. werdan has left

  751. jcbrand has left

  752. lovetox has left

  753. Andrzej has left

  754. andrey.g has joined

  755. marc has joined

  756. marc has left

  757. marc has joined

  758. krauq has left

  759. krauq has joined

  760. Nekit has joined

  761. sonny has left

  762. sonny has joined

  763. dwd has left

  764. mdosch has left

  765. mdosch has joined

  766. Andrzej has joined

  767. sonny has left

  768. rion has left

  769. rion has joined

  770. sonny has joined

  771. karoshi has left

  772. alameyo has left

  773. alameyo has joined

  774. sonny has left

  775. marc has left

  776. marc has joined

  777. sonny has joined

  778. Vaulor has left

  779. dwd has joined

  780. sonny has left

  781. xsf has left

  782. Daniel has left

  783. Daniel has joined

  784. sonny has joined

  785. andrey.g has left

  786. bear has left

  787. calvin has left

  788. sonny has left

  789. sonny has joined

  790. calvin has joined

  791. calvin has left

  792. mukt2 has joined

  793. Zash has left

  794. Andrzej has left

  795. bear has joined

  796. rion has left

  797. Zash has joined

  798. mukt2 has left

  799. Andrzej has joined

  800. stpeter has joined

  801. stpeter has left

  802. xsf has joined

  803. mdosch has left

  804. Injecto has joined

  805. mdosch has joined

  806. Injecto has left

  807. calvin has joined

  808. alameyo has left

  809. alameyo has joined

  810. lskdjf has left

  811. bear has left

  812. calvin has left

  813. marc has left

  814. mdosch has left

  815. mdosch has joined

  816. mdosch has left

  817. mdosch has joined

  818. mdosch has left

  819. mdosch has joined

  820. mdosch has left

  821. mdosch has joined

  822. neshtaxmpp has left

  823. mdosch has left

  824. mdosch has joined

  825. mdosch has left

  826. mdosch has joined

  827. mdosch has left

  828. mdosch has joined

  829. sonny has left

  830. sonny has joined

  831. emus has left

  832. Andrzej has left

  833. neshtaxmpp has joined