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’ <3
  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 Eww.
  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 why?
  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 ah
  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 hm
  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 Maybe.
  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 thanks!
  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’ yes
  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 cool
  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 OUTRAGE!
  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