XSF Discussion - 2023-03-21


  1. mentos124 has left

  2. tbm16 has joined

  3. Hugo has left

  4. tbm16 has left

  5. nicoco has left

  6. goldbeardp has joined

  7. Hugo has joined

  8. Vaulor has left

  9. L29Ah has left

  10. nicoco has joined

  11. nicoco has left

  12. xnamed has left

  13. L29Ah has joined

  14. Hugo has left

  15. nicoco has joined

  16. nicoco has left

  17. djorz has left

  18. snow has joined

  19. Wojtek has joined

  20. Wojtek has left

  21. Kev has joined

  22. neshtaxmpp has left

  23. ralphm has left

  24. intosi has left

  25. Maranda[x] has left

  26. brunrobe has left

  27. Maranda has left

  28. KitKat::new() has left

  29. Mjolnir Archon has left

  30. Wojtek has joined

  31. david has joined

  32. david has left

  33. zonsopkomst has left

  34. zonsopkomst has joined

  35. pablo has joined

  36. petrescatraian has left

  37. Calvin has joined

  38. Wojtek has left

  39. tbm16 has joined

  40. nicoco has joined

  41. nicoco has left

  42. nicoco has joined

  43. nicoco has left

  44. Rebeld has joined

  45. nicoco has joined

  46. nicoco has left

  47. sonny has left

  48. nicoco has joined

  49. nicoco has left

  50. Kev has left

  51. SteveF has left

  52. SteveF has joined

  53. Kev has joined

  54. jgart has left

  55. KitKat::new() has joined

  56. nicoco has joined

  57. nicoco has left

  58. nicoco has joined

  59. nicoco has left

  60. pablo has left

  61. pablo has joined

  62. KitKat::new() has left

  63. catchy has joined

  64. nicoco has joined

  65. nicoco has left

  66. jgart has joined

  67. nicoco has joined

  68. nicoco has left

  69. nicoco has joined

  70. nicoco has left

  71. farenr has left

  72. farenr has joined

  73. david has joined

  74. david has left

  75. sonny has joined

  76. goldbeardp has left

  77. Maranda[x] has joined

  78. nicoco has joined

  79. nicoco has left

  80. KitKat::new() has joined

  81. Calvin has left

  82. goldbeardp has joined

  83. TheCoffeMaker has left

  84. nicoco has joined

  85. nicoco has left

  86. pablo has left

  87. pablo has joined

  88. nicoco has joined

  89. nicoco has left

  90. KitKat::new() has left

  91. antranigv has left

  92. pablo has left

  93. nicoco has joined

  94. nicoco has left

  95. neshtaxmpp has joined

  96. Trung has left

  97. Trung has joined

  98. Yagiza has joined

  99. nicoco has joined

  100. nicoco has left

  101. lskdjf has left

  102. farenr has left

  103. tbm16 has left

  104. millesimus has left

  105. Trung has left

  106. Trung has joined

  107. nicoco has joined

  108. nicoco has left

  109. millesimus has joined

  110. snow has left

  111. farenr has joined

  112. Yagiza has left

  113. catchy has left

  114. catchy has joined

  115. Yagiza has joined

  116. Yagiza has left

  117. KitKat::new() has joined

  118. millesimus has left

  119. KitKat::new() has left

  120. nicoco has joined

  121. nicoco has left

  122. millesimus has joined

  123. singpolyma has left

  124. Maranda[x] has left

  125. farenr has left

  126. farenr has joined

  127. KitKat::new() has joined

  128. singpolyma has joined

  129. moparisthebest has left

  130. moparisthebest has joined

  131. khirput has left

  132. khirput has joined

  133. KitKat::new() has left

  134. matthias has joined

  135. nicoco has joined

  136. nicoco has left

  137. KitKat::new() has joined

  138. lbocquet has left

  139. lbocquet has joined

  140. marc0s has left

  141. marc0s has joined

  142. nicoco has joined

  143. nicoco has left

  144. Calvin has joined

  145. KitKat::new() has left

  146. 644043 has left

  147. mirux has joined

  148. farenr has left

  149. nicoco has joined

  150. nicoco has left

  151. atomicwatch has joined

  152. nicoco has joined

  153. nicoco has left

  154. goldbeardp has left

  155. nicoco has joined

  156. nicoco has left

  157. nicoco has joined

  158. nicoco has left

  159. KitKat::new() has joined

  160. nicoco has joined

  161. nicoco has left

  162. Mario Sabatino has joined

  163. atomicwatch has left

  164. Axel R. has joined

  165. nicoco has joined

  166. belove has left

  167. nicoco has left

  168. nicoco has joined

  169. nicoco has left

  170. KitKat::new() has left

  171. belove has joined

  172. Mikaela has joined

  173. nicoco has joined

  174. nicoco has left

  175. 644043 has joined

  176. atomicwatch has joined

  177. MSavoritias (fae,ve) has joined

  178. KitKat::new() has joined

  179. Menel has joined

  180. nicoco has joined

  181. nicoco has left

  182. Vaulor has joined

  183. catchy has left

  184. KitKat::new() has left

  185. oshn has left

  186. KitKat::new() has joined

  187. oshn has joined

  188. oshn has left

  189. Calvin has left

  190. oshn has joined

  191. khirput has left

  192. khirput has joined

  193. atomicwatch has left

  194. daags has left

  195. krit has left

  196. krit has joined

  197. brunrobe has joined

  198. Daniel has left

  199. Seve has joined

  200. Maranda[x] has joined

  201. nicoco has joined

  202. nicoco has left

  203. emus has joined

  204. wurstsalat has joined

  205. xnamed has joined

  206. uhoreg has left

  207. Half-Shot has left

  208. homebeach has left

  209. Matthew has left

  210. Half-Shot has joined

  211. Matthew has joined

  212. homebeach has joined

  213. uhoreg has joined

  214. nicoco has joined

  215. nicoco has left

  216. Daniel has joined

  217. nicoco has joined

  218. nicoco has left

  219. nicoco has joined

  220. nicoco has left

  221. LNJ has left

  222. Vaulor has left

  223. nicoco has joined

  224. nicoco has left

  225. Vaulor has joined

  226. Steve Kille has joined

  227. marc0s has left

  228. marc0s has joined

  229. marc0s has left

  230. marc0s has joined

  231. Rebeld has left

  232. belove has left

  233. 644043 has left

  234. belove has joined

  235. belove has left

  236. belove has joined

  237. LNJ has joined

  238. daags has joined

  239. Andrzej has joined

  240. Arne has left

  241. Andrzej has left

  242. Arne has joined

  243. Maranda has joined

  244. Steve Kille has left

  245. goffi has joined

  246. petrescatraian has joined

  247. Andrzej has joined

  248. Mjolnir Archon has joined

  249. Menel has left

  250. belove has left

  251. belove has joined

  252. Menel has joined

  253. petrescatraian has left

  254. petrescatraian has joined

  255. Andrzej has left

  256. 644043 has joined

  257. djorz has joined

  258. daags has left

  259. nicoco has joined

  260. Steve Kille has joined

  261. nicoco has left

  262. goffi has left

  263. goffi has joined

  264. nicoco has joined

  265. nicoco has left

  266. sonny has left

  267. nicoco has joined

  268. nicoco has left

  269. neshtaxmpp has left

  270. belove has left

  271. neshtaxmpp has joined

  272. nicoco has joined

  273. nicoco has left

  274. praveen has joined

  275. belove has joined

  276. sonny has joined

  277. belove has left

  278. belove has joined

  279. oshn has left

  280. marc0s has left

  281. marc0s has joined

  282. marc0s has left

  283. marc0s has joined

  284. oshn has joined

  285. marc0s has left

  286. marc0s has joined

  287. govanify has left

  288. konstantinos has joined

  289. djorz has left

  290. govanify has joined

  291. marc0s has left

  292. marc0s has joined

  293. Andrzej has joined

  294. Hugo has joined

  295. Titi has joined

  296. atomicwatch has joined

  297. atomicwatch has left

  298. belove has left

  299. atomicwatch has joined

  300. atomicwatch has left

  301. atomicwatch has joined

  302. atomicwatch has left

  303. belove has joined

  304. atomicwatch has joined

  305. Hugo has left

  306. Titi has left

  307. Hugo has joined

  308. marc0s has left

  309. marc0s has joined

  310. Andrzej has left

  311. projjalm has joined

  312. daags has joined

  313. nicoco has joined

  314. adiaholic has left

  315. belove has left

  316. adiaholic has joined

  317. belove has joined

  318. oshn has left

  319. Hugo has left

  320. deimos has left

  321. Andrzej has joined

  322. oshn has joined

  323. gooya has joined

  324. jgart has left

  325. Tim R has joined

  326. neox has joined

  327. neox has left

  328. neox has joined

  329. neox has left

  330. neox has joined

  331. Titi has joined

  332. Andrzej has left

  333. Dele Olajide has joined

  334. ralphm has joined

  335. intosi has joined

  336. oshn has left

  337. Vaulor has left

  338. Vaulor has joined

  339. belove has left

  340. belove has joined

  341. adiaholic has left

  342. adiaholic has joined

  343. 644043 has left

  344. goffi

    Is is possible to share multiple files in a single <message> with XEP-0447 (Stateless file sharing)? Apparently it's not.

  345. mjk has left

  346. mjk has joined

  347. 775857429 has left

  348. millesimus has left

  349. oshn has joined

  350. Kev

    It's possible with SIMS, at least, because Swift does that.

  351. millesimus has joined

  352. stp has joined

  353. belove has left

  354. belove has joined

  355. petrescatraian has left

  356. belove has left

  357. belove has joined

  358. goffi

    I see. I've gone the XEP-0447 way as it is supposed to be a reiteration of XEP-0385. However the issue I see is easily fixable, we need to add on `id` attribute on the `<file-sharing>` element, and rewrite §3.3 "Attaching a source" to use it. Then nothing prevent to use multiple `<file-sharing>` elements in he same `<message>` stanza.

  359. david has joined

  360. david has left

  361. Menel has left

  362. goffi

    We also need to decide once for all which XEP to utilise for file sharing, but that's one of the eternal XMPP problems.

  363. Chad has joined

  364. MattJ

    🙂

  365. Menel has joined

  366. MattJ

    Does anyone feel they have sufficient context to write a summary of the current options (pros, cons, implementation status) to standards@?

  367. MattJ

    (I don't)

  368. goffi

    I'm currently writing something for the multiple files issues, that can be a starting point.

  369. MattJ

    Thanks

  370. Kev

    To this day I don't understand why 447 came about when it basically duplicates SIMS.

  371. nicoco

    I don't either, and in fact they so much look alike that I just support both with little effort. I think the main issue is philosophical: "namespace reuse bad vs namespace reuse good"

  372. Kev

    I know someone once said "Because SIMS has 'media' in the name and I don't want to share media", but I think that's both an insufficient reason and a difference in understanding of the term media.

  373. MattJ

    Action items: Rename SIMS, give it a casual mention in the 2023 compliance suite, done

  374. Kev

    That would work for me.

  375. con3 has joined

  376. Andrzej has joined

  377. Andrzej has left

  378. goffi

    XEP-0385 depends on reference, and while it may be nice to have a reference, it should be optional (it should be possible to have files available just as attachments). Also file-metadata has been split instead of realying on jingle stuff. It has source attachment, which is a neat feature, and XEP-0447 is not tied to message, which make it usable with pubsub. But all that could have been fixed directly on XEP-0385.

  379. kurisu has left

  380. goffi

    However, now that we have both, I personnaly thing that XEP-0447 should be used as basis, XEP-0385 deprecated (with authors probably transfered to XEP-0447), and maybe add references as an optional feature.

  381. goffi

    think*

  382. Wojtek has joined

  383. goldbeardp has joined

  384. kurisu has joined

  385. antranigv has joined

  386. papatutuwawa has joined

  387. praveen has left

  388. stp has left

  389. MSavoritias (fae,ve)

    yeah the newer one has some nice improvements

  390. Steve Kille has left

  391. goffi

    I've sent a message to standard@, and I can propose a PR in coming days, but I'll need backup from XEP authors.

  392. adiaholic has left

  393. adiaholic has joined

  394. Steve Kille has joined

  395. Steve Kille has left

  396. pep.

    Kev, also 372?

  397. pep.

    Re why not SIMS

  398. pep.

    I think that's one of the reasons?

  399. goffi

    yes I've mentioned it in the email. It's really weird because it's in example, but not explained at all in the text.

  400. goffi

    XEP-0372 is not even quoted.

  401. pep.

    https://xmpp.org/extensions/xep-0447.html well actually there's a whole list of "Why not SIMS" in the spec

  402. Kev

    Right, one of which (not allowing body) seems to be show-stopping, "has media in the title" seems like a bad reason, and not using references is to its detriment rather than benefit.

  403. Tobi

    pep. , yup..some weird list. 1. "No focus on media, generic for every file type." <--- probably different understanding of the term "media", 2. Using File metadata element (XEP-0446) [2]. <--- File metadata element didn't exist yet back then. If you look it's from the same author. 3. "Using XML for structured data instead of URIs when possible, adding further extensibility" <-- I think URIs can provide great extensibility as well. I'm sure there are URI schemes for encrypted keys and what not.

  404. pep.

    Ah I'm getting the whole isode crew on my back :P

  405. Tobi

    I'm not against File metadata element, but it's a weird reason for duplicating a XEP. I mean SIMS was experimental and can be changed easily.

  406. goffi

    Kev: in XEP-0447 body is explicitely allowed as fallback (it's just said that it should not have additional info, which seems sensible)

  407. Tobi

    pep. , heh :) but I agree..references is a bit out of place in SIMS. It was not meant to depend on it, more as an example of how the SIMS element can be used with other XEPs in mind.

  408. pep.

    I guess as the spec is actually being used in places, maybe starting to remove these TODOs would be nice

  409. goldbeardp has left

  410. Kev

    > : in XEP-0447 body is explicitely allowed as fallback (it's just said that it should not have additional info, which seems sensible) But that doesn't seem sensible at all, it seems terrible. I can't immediately think of any other platform that requires sending files independent of messages. In all the ones I use, you attach (multiple) file(s) to a message that has all the normal properties.

  411. pep.

    Isn't that "just" a UI thing?

  412. wurstsalat

    larma: ping ^

  413. Wojtek has left

  414. Steve Kille has joined

  415. goffi

    I don't get what prevents the message to have normal properties. The way I understand it, is don't use metadata in the body which are not present in the <file-sharing> element. Also I want and plan to transmit files outside of message, notably with pubsub.

  416. Kev

    > Isn't that "just" a UI thing? I don't see how, unless you then use extra XEPs to tie together these messages into one conceptual message.

  417. marc0s has left

  418. marc0s has joined

  419. Kev

    (With all the MAM etc. problems that brings)

  420. pep.

    I often find it weird that people feel like they need to refer to everything everywhere, but that's me. It's not like there was often 43 different topics going on at the same time

  421. pep.

    Message1: "hey the pictures I told you about", Message2: <pictures>

  422. pep.

    Not saying it shouldn't be done of course, or that I'm gonna try to prevent it from happening (referencing stuff everywhere)

  423. Steve Kille has left

  424. gooya has left

  425. gooya has joined

  426. belove has left

  427. Steve Kille has joined

  428. goffi

    now that I'm thinking about it, XEP-0447 is already used with pubsub in XEP-0471

  429. belove has joined

  430. Yagiza has joined

  431. Steve Kille has left

  432. Martin has left

  433. Martin has joined

  434. Martin has left

  435. Martin has joined

  436. goldbeardp has joined

  437. Steve Kille has joined

  438. Wojtek has joined

  439. con3 has left

  440. marc0s has left

  441. marc0s has joined

  442. Wojtek has left

  443. goldbeardp has left

  444. oshn has left

  445. oshn has joined

  446. floretta has joined

  447. adiaholic has left

  448. adiaholic has joined

  449. Maranda[x] has left

  450. Maranda[x] has joined

  451. marc0s has left

  452. marc0s has joined

  453. goldbeardp has joined

  454. Link Mauve

    pep., you lose the semantics, unless you parse the message.

  455. Link Mauve

    While having a message introducing the pictures, as well as a description for each picture, ties it all together.

  456. xnamed has left

  457. Link Mauve

    This is important for accessibility too.

  458. Link Mauve

    The current Conversations way of sharing media is completely inaccessible.

  459. pep.

    @alt is possible with 447

  460. Link Mauve

    I was talking about abusing XEP-0066 for saying “this URL is actually an embed”.

  461. pep.

    Yeah I wasn't, I was still taking about 447. I agree accessibility is important

  462. xnamed has joined

  463. tbm16 has joined

  464. intosi has left

  465. intosi has joined

  466. Andrzej has joined

  467. TheCoffeMaker has joined

  468. tbm16 has left

  469. Menel has left

  470. Menel has joined

  471. Hugo has joined

  472. Wojtek has joined

  473. belove has left

  474. Calvin has joined

  475. carlos has left

  476. carlos has joined

  477. Calvin has left

  478. belove has joined

  479. larma

    The motivation of 447 is to get things going. One of the reasons why 385 was never really adopted even though everyone agrees it would be nice to have, is it's lack of backwards compatibility. 447 file transfers are fully compatible with legacy oob based http file transfers. This requires that the body remains unused (because the body is needed for backwards compatibility)

  480. marc0s has left

  481. marc0s has joined

  482. Hugo has left

  483. Hugo has joined

  484. larma

    Mixed content (as proposed with SIMS) is somewhat contradicting 0226. I do know that some messengers (hardly all, but Slack does and apparently that became the baseline for many) allow sending messages that have both a text body and files in the same message. That's not a primary objective for 0447.

  485. belove has left

  486. Link Mauve

    larma, the main reason 0385 never got adopted was that it didn’t play well with body-only e2ee IIRC.

  487. goldbeardp has left

  488. TheCoffeMaker has left

  489. larma

    We don't encrypt in public MUCs so it could've been used there at least

  490. Tim R has left

  491. Tim R has joined

  492. belove has joined

  493. Tim R has left

  494. TheCoffeMaker has joined

  495. floretta has left

  496. Andrzej has left

  497. Kev

    You're right, this might not be as widespread as I thought, but it's still a thing I very much want to support. A quick test of what's immediately available to me seems to suggest: Same Message: Apple Messages, Google, Slack, Discord, Guilded Not: Whatsapp, Facebook Messenger

  498. xnamed has left

  499. Kev

    I almost exclusively use the first set, so hadn't realised the last two didn't.

  500. nicoco

    I'm trying to understand something: because of <sources>, we can't have several <file>s in a <file-sharing>. what prevents us from having several <file-sharing>s?

  501. belove has left

  502. xnamed has joined

  503. Daniel

    Ignoring what other messengers are doing. Sending images and text in the same message is a very frequently requested feature

  504. larma

    Kev: Feel invited to figure out how to do backwards compatibility with SIMS, because I didn't (except having two bodies)

  505. adiaholic has left

  506. Daniel

    Note the *s* in images

  507. Chad has left

  508. nicoco

    Daniel: and a single text for all images, or a description per messagE?

  509. nicoco

    Daniel: and a single text for all images, or a description per message?

  510. nicoco

    Daniel: and a single text for all images, or a description per image?

  511. larma

    nicoco: That's indeed on my to do list (assigning an id to each file-sharing if there are multiple)

  512. Daniel

    > Daniel: and a single text for all images, or a description per image? Not sure tbh. But I think one common description would probably be fine?

  513. neox has left

  514. adiaholic has joined

  515. MattJ

    I think common description + optional alt/caption per image is probably what we ought to aim for

  516. nicoco

    I think this is what I've seen in walled gardens, but for accessibility, alt text per image is actually better, isn't it?

  517. Daniel

    (~ alt text with is orthogonal in my mind)

  518. Hugo has left

  519. neox has joined

  520. nicoco

    ok

  521. Kev

    > : Feel invited to figure out how to do backwards compatibility with SIMS, because I didn't (except having two bodies) I thought we'd sorted that in Swift, maybe Tobi can remember what our rule was? I think it was to trim the start of the message if it matches the file URL, and to prepend the URL.

  522. jonas’

    if alt text is covered separately, I'd say that one overarching text alognside the images should do

  523. belove has joined

  524. nicoco

    > assigning an id to each file-sharing if there are multiple larma: but isn't it already possible to have several <file-sharing> elements, each with their own <sources>?

  525. floretta has joined

  526. MattJ

    > I thought we'd sorted that in Swift [...] I think if it comes down to matching like this (which probably it will), we should specify the recommended fallback format in the XEP too

  527. larma

    nicoco: yes, but then attaching sources won't work

  528. TheCoffeMaker has left

  529. 775857429 has joined

  530. TheCoffeMaker has joined

  531. nicoco

    oh right, in 3.3 <sources> is not a child of <file-sharing>. I get it, thanks.

  532. Calvin has joined

  533. larma

    An alternative would be to have some <message-group id=x /> which can be added to multiple messages to have the recipient client group them. So if you send five files with text, you send 6 messages and group them. Legacy clients would still display 5 files and a message without any weirdness.

  534. Calvin has left

  535. larma

    Because fallbacks won't work for multiple files either

  536. larma

    Because fallbacks won't work properly for multiple files either

  537. Kev

    Why not?

  538. larma

    When I talk about fallback I mean fallback to how we do files today.

  539. larma

    Not fallback to "here is a bunch of URLs"

  540. goldbeardp has joined

  541. marc0s has left

  542. marc0s has joined

  543. larma

    Alternatively the fallback for multiple files can be that legacy users get a zip file, but that's pretty bad UX for legacy users if we send images.

  544. catchy has joined

  545. larma

    Having legacy users display 3 images and a body ungrouped is the best fallback we can possibly have, so we should try to reach that somehow.

  546. pep.

    Yeah no an (compressed) archive seems terrible

  547. Calvin has joined

  548. larma

    pep.: would be fine for 3 non image files IMO

  549. goffi

    Wait, I'm reading back the logs, I think that there is a misunderstanding, maybe on my side. When I read "No mixed content, body is used for fallback only and not to transmit additional information.", I read no additional information ABOUT THE FILE (i.e. don't put encryption key or something like that in the body), but I don't read it as it's impossible to put a message in the body at the same time as the file. Example 2 is doing exactly that. I've missed something or what?

  550. pep.

    larma, I guess if one doesn't have to display thumbnails.. but say I only want to download one of them.. it's weird

  551. goffi

    otherwise, I agress that we need to have text in the body at the same time as images, and I've understood XEP-0477 like that.

  552. belove has left

  553. larma

    goffi: example 2 has the file's desc in the body, no text beyond that.

  554. larma

    goffi: example 2 has the file's desc in the body, no additional information beyond that.

  555. larma

    pep.: with uncompressed archives you could just download the header (or footer) and the do a ranged http request. Anyway, not saying it's my favourite solution either.

  556. pep.

    Ok

  557. goffi

    Damn, I've already read it like information about the file, that why I wasn't understanding kev point, in which case I agree that it's a show stopper (and I haven't implemented it like that).

  558. pep.

    And so tangeantially, what about 372?

  559. goffi

    I've always read it*

  560. belove has joined

  561. pep.

    And so relatedly, what about 372?

  562. pep.

    I know some clients use it to do mentions, is there anybody not going to use that for mentions?

  563. pep.

    Also do we need to define a URI for occupant-id maybe?

  564. larma

    Last resort (if people don't like the grouping) could be messages sent exclusively as a fallback (you send one message with text body and file-sharings and then follow-up messages that have the files in legacy mode plus a tag to ignore them if you supported the file-sharing element of the first message)

  565. larma

    Last resort (if people don't like the grouping) could be messages sent exclusively as a fallback (you send one message with text body and <file-sharing>s and then follow-up messages that have the files in legacy mode plus a tag to ignore them if you supported the <file-sharing> element of the first message)

  566. L29Ah has left

  567. larma

    pep.: my proposal would be to add mention to 0394

  568. pep.

    And are they any other uses for 372? Is someone someday going to use my mention-in-a-chatroom as something completly different?

  569. singpolyma

    Good morning. My reasons to prefer SIMS: * Mixed text+files is a must for us * Reuses existing namespaces instead of the NiH file element * Can do both attachments and inline media, both of which we need

  570. Kev

    If that's what has to happen (If I understand correctly, you're sending multiple <message><body>URL</body><ignore-if-you-do-sims/></message>), then that seems better (although horrid) than not being able to use the message body.

  571. L29Ah has joined

  572. pep.

    larma, you mean that thing that's never gonna replace xhtml-im? :x

  573. jonas’

    my proposal would be to kill 394 with fire

  574. jonas’

    and resurrect '77

  575. jonas’

    and resurrect '70

  576. Kev

    And then people who don't care too much could just not do it.

  577. jonas’

    and resurrect '71

  578. Kev

    (Other than the ignoring bit)

  579. singpolyma

    For "fallback" parts of body we fallback xep

  580. Zash

    XHTML-IM 2: This time it's secure, surely?

  581. pep.

    singpolyma, by inline you mean base64?

  582. singpolyma

    pep.: No, I mean text and images intermixed. Probably with xhtml-im but can also use the references for that

  583. jonas’

    XHTML-IM 2: This time, we don't pretend that web issues can be solved in protocol.

  584. pep.

    So.. what about mentions..

  585. larma

    Kev: so I read you don't like the grouping thing?

  586. goffi

    I don't get why the XEP-0447 should have a restricted body. If we want to support multiple files, we can't support legacy anyway.

  587. Kev

    > : so I read you don't like the grouping thing? Maybe I don't understand it, I'm a bit distracted at the moment.

  588. larma

    goffi: multiple files is missing exactly because it wasn't clear what's the best way to do it backwards compatible ;)

  589. larma

    > An alternative would be to have some <message-group id=x /> which can be added to multiple messages to have the recipient client group them. So if you send five files with text, you send 6 messages and group them. Legacy clients would still display 5 files and a message without any weirdness. Kev

  590. Calvin has left

  591. jonas’

    and then your MAM page cuts in the middle and half of it is missing in your dipslay

  592. jonas’

    and then your MAM page cuts in the middle and half of it is missing in your display

  593. pep.

    I think that's a problem for many things, not especially with this spec

  594. larma

    jonas’: and then you fetch the next page and it repairs

  595. 775857429 has left

  596. larma

    Or you use that new version of MAM that we discussed at summit

  597. Kev

    larma I guess don't understand why splitting one logical message across six message stanzas which clients and MAM archives then need to merge is a positive thing.

  598. larma

    Kev: because that's what we effectively do today

  599. Kev

    But I also don't really understand why fallback of 'prepend URLS to body' doesn't work.

  600. Kev

    > : because that's what we effectively do today I think that might depend on which 'we' you mean :)

  601. jonas’

    and as I read on mastodon today: "tradition is just peer pressure exerted by dead people"

  602. larma

    Kev: because legacy clients would then be shown a list of random URLs?

  603. jonas’

    just like today?

  604. jonas’

    it's ok, as long as the URLs are there

  605. Kev

    Together with the rest of the message body, yes. I'm not sure how that's different to legacy clients receiving six messages, one of which is a body and the others are 'random URLs'.

  606. larma

    Consider that *all* your clients would be legacy clients under this definition

  607. Zash

    Subtle encouragement for implementing non-legacy things is fine

  608. jonas’

    larma, yes, for a while

  609. jonas’

    and then they're fixed and we're good

  610. MattJ

    and for the case of n==1, it works as good as today, right?

  611. larma

    jonas’: except that some platforms will never see the update

  612. pep.

    Eventual inconsistencies

  613. jonas’

    larma, :sadface:

  614. jonas’

    can't have nice things everywhere

  615. jonas’

    I am a debian user, fwiw ;)

  616. Zash

    Evolution gonna evolution I guess?

  617. jonas’

    I also don't see the issue with a list of URLs followed by a text. in e.g. conversations it'll look exactly the same as it does now (if you don't send OOB)

  618. MattJ

    Yeah, old clients gradually getting a worse experience is not a reason to hold back the protocol

  619. MattJ

    (or to make it overly complex)

  620. pep.

    That's the thing. Backwards compat ok but at which cost

  621. singpolyma

    Inbound multiple images I store already, will be displaying them later this year I expect

  622. singpolyma

    (oob and sims)

  623. goffi

    if SIMS handle multiple files, why is that acceptable there, and not for XEP-0447?

  624. Zash

    Backwards compat in the form of some graceful decay seems okay to me.

  625. Kev

    > That's the thing. Backwards compat ok but at which cost I note that what I'm suggesting *does* have baseline backwards compat, at pretty low cost.

  626. larma

    I don't think sending multiple messages is overly complex or high cost

  627. singpolyma

    It's super annoying on several levels for the receiver though

  628. pep.

    goffi, I guess it could, but larma seems to not want to do this?

  629. pep.

    And.. what about mentions?!

  630. Zash

    Decaying into multiple messages does have precedent in IRC gateways... Tho I see no huge problem with decaying into <body>{url}+</body>

  631. singpolyma

    What about mentions? That seems unrelated?

  632. larma

    If everyone is on a mission now to break compatibility, I wonder why SIMS wasn't popular except for some closed corporate environments

  633. singpolyma

    Media wasn't popular back then either

  634. lskdjf has joined

  635. larma

    singpolyma: seriously?

  636. singpolyma

    Even when Conversations launched it was just jingle FT push right? Before http upload existed

  637. marc0s has left

  638. marc0s has joined

  639. pep.

    Zash, this can be handled by the IRC gateway, breaking into separate messages

  640. singpolyma

    Pull media is still a brave New world

  641. larma

    If >5 years is new for you

  642. larma

    If >5 years in production is new for you

  643. jonas’

    singpolyma, the advantages of SIMS are not enough to warrant the change

  644. jonas’

    if we get media messages (with more than one file) with alt text each, plus accompanying text, that's a different beast

  645. jonas’

    also, I meant to ping larma

  646. Fishbowler has left

  647. Fishbowler has joined

  648. marc0s has left

  649. marc0s has joined

  650. larma

    jonas’: 90% of cases, people are still going to send a single file without text

  651. jonas’

    great

  652. Kev

    > if we get media messages (with more than one file) with alt text each, plus accompanying text, that's a different beast But...that's what SIMS gives you?

  653. goffi

    + metadata which are necessary for accessibility.

  654. pep.

    larma, have you looked at Mastodon? :x

  655. jonas’

    larma, add an oob tag, and it'll magically work in all exitsing clients then

  656. Andrzej has joined

  657. larma

    jonas’: so it shouldn't break for them.

  658. jonas’

    without the ugly splitting part needed

  659. jonas’

    without the ugly splitting part needed for the case when more than one image is attached

  660. pep.

    description + @alt is pretty standard in my TL

  661. larma

    Many clients require the URL to be in oob and body

  662. jonas’

    what pep. says, too, but mastodon isn't the same use case as XMPP is.

  663. goffi

    larma: that's not true, and other messenging, I see people sharing whole albums.

  664. singpolyma

    > if we get media messages (with more than one file) with alt text each, plus accompanying text, that's a different beast Yes, this is why I use sims

  665. larma

    But if new clients display the body (aka the URL) their UX will be bad

  666. singpolyma

    Plus hashes are a big deal for me and non http options

  667. 775857429 has joined

  668. larma

    So summary: we have 0447 for backwards compatible sending of a single file and SIMS for mixed content, multiple files and so on?

  669. larma

    So summary: we have 0447 for backwards compatible sending of a single file and SIMS for mixed content, multiple files and so on without proper backwards compatibility?

  670. Kev

    Except for SIMS backwards compatibility being fine? If you do something that's supported by the old clients, it's fine, and if you do something new that they didn't support, you expect them to need a fallback.

  671. larma

    We do have different ideas of what reasonable backwards compatibility looks like.

  672. goldbeardp has left

  673. goldbeardp has joined

  674. larma

    I also don't mind if we get rid of 0447 entirely. I just remember vaguely about all the issues people told me they had with SIMS and then I was told that there is no intent to change those things in SIMS and if I wanted to change then I should create a new XEP and now apparently SIMS was all great.

  675. larma

    I also don't mind if we get rid of 0447 entirely. I just remember vaguely about all the issues people told me they had with SIMS and then I was told that there is no intent to change those things in SIMS and if I wanted to change then I should create a new XEP and now apparently SIMS was all great and nobody remembers why they didn't use it.

  676. Zash

    A/B test all the XEPs?

  677. singpolyma has left

  678. singpolyma has joined

  679. larma

    Next Dino release will support 0447, so yes, A/B testing is going to happen anyways

  680. nicoco

    > larma: that's not true, and other messenging, I see people sharing whole albums. absolutely. the non-techies I bring to XMPP IM really miss "sharing a whole (smallish) album in a message", à la whatsapp. I agree that there are better tools to share albums, but this usage of IM has "won" among non-techies. possibly this is only a UI problem though.

  681. adiaholic has left

  682. Chad has joined

  683. L29Ah has left

  684. L29Ah has joined

  685. adiaholic has joined

  686. larma

    FWIW, I totally understand all those use cases people have in mind and are looking to support, but it's also sad to see that everyone is just thinking inside their bubble and not caring about compatibility outside of it.

  687. singpolyma

    Compatibility can only come when we do the work. That's why the transition happens slowly instead of all at once

  688. larma

    FWIW, I totally understand all those use cases people have in mind and are looking to support, but it's also sad to see that everyone is just thinking inside their bubble and not caring about good compatibility outside of it.

  689. Zash

    Do we have a set scope for what we want?

  690. singpolyma

    For our side we're starting by slowly introducing text+image now that we have two clients that support it

  691. larma

    singpolyma: which clients?

  692. singpolyma

    larma: Cheogram Android and Movim

  693. larma

    And what about all the other clients?

  694. singpolyma

    those clients see fallback in the cases we use text+image

  695. singpolyma

    which is why we are doing it slowly and not in every case it makes sense ye

  696. singpolyma

    which is why we are doing it slowly and not in every case it makes sense yet

  697. larma

    The fallback being text + URL?

  698. singpolyma

    yes

  699. larma

    So you're planning to severely degrade UX of >90% of active XMPP users

  700. singpolyma

    No

  701. pep.

    Different use-cases and interop yay

  702. singpolyma

    Right now we only do it in cases where it would be degraded for those other users anyway

  703. pep.

    Someday people will realize interop is a fantasy

  704. singpolyma

    namely, group text, where we have several fallback in play usually

  705. Zash

    pep., or, a process?

  706. pep.

    eventual interoperability?

  707. L29Ah has left

  708. Zash

    yes!

  709. singpolyma

    But it's a trade off between better experience for most of our users vs degraded experience for the few using other clients

  710. singpolyma

    and we do walk that line carefully

  711. L29Ah has joined

  712. Tim R has joined

  713. larma

    "most of our users" which reconfirms the bubble thing I was talking about

  714. singpolyma

    Well, obviously our service will prioritize the experince of people who use it :)

  715. Kev

    Are far as I can see, we should be able to do SIMS (or an update to something else) such that it supports multifile, and supports bodies, and that if you continue to do what the reference current clients do (not allowing multifile and not allowing bodies), those will behave as they already do. So if that's the only case that matters for your users, they won't see any different, but those users who do want those features in 'new' clients get them.

  716. pep.

    singpolyma, said matrix.org on IRC :P

  717. floretta has left

  718. floretta has joined

  719. singpolyma

    pep.: that's sort of the opposite case

  720. singpolyma

    Or, maybe it's similar. Since we have to degrade the experince of MMS users due to these limitations in XMPP clients right now

  721. singpolyma

    But it's pretty small at this point I think, people don't often ask us why multi file is weird

  722. singpolyma

    But yeah, IMO these changes happen slowly and because of ecosystem evolution. Big bang it is too much incompatibility, but doing nothing is stagnation. It's a balance to walk

  723. 775857429 has left

  724. goffi

    I think we were talking about grouping earlier. Would not it be possible to use XEP-0477 with a flag like "the 5 next <message> I send are next files + body message"? We would keep backward compatibility + having multiple files and text message at the same time, at the expanse of a little bit of bandwith.

  725. pep.

    Would it not be easier to say "I'm in the same bundle as <the-previous-message-id>"?

  726. singpolyma

    That means that to know if you have the whole message you have to wait on a timer?

  727. singpolyma

    "maybe I have the whole message now, oh oops here's another piece"

  728. goffi

    pep.: I want to know that I will have to show a specific widget for several files at once, so I need to know from the start.

  729. pep.

    For what goffi says yes, for what I say, no?

  730. marc0s has left

  731. marc0s has joined

  732. pep.

    It's fine, you just update your display?

  733. pep.

    That happens all the time with chat bubbles that include or don't include incoming messages because they appear in the same minute, on Conversations for example

  734. singpolyma

    pep.: what if my "display" is that I'm sending an MMS message with text+images ?

  735. singpolyma

    or an email

  736. pep.

    Ah well

  737. singpolyma

    or any other gateway protocol that supports text+images :)

  738. goffi

    Can be, but it may be weird for the user to have files being added (oh there were 10 files, I only saw 4). Also updating is more difficult in some cases.

  739. pep.

    I find it awkward though what goffi says. You may be waiting on messages that will never come

  740. goffi

    larma: what do you think about it (grouping to have multiple files + message at the same time)?

  741. antranigv has left

  742. goffi

    pep.: that's implementation to handle, I would put a timeout, and display what I have if nothing happen after X seconds.

  743. marc0s has left

  744. marc0s has joined

  745. marc0s has left

  746. marc0s has joined

  747. singpolyma

    vs just using multiple oob and having them all at once

  748. marc0s has left

  749. marc0s has joined

  750. marc0s has left

  751. marc0s has joined

  752. marc0s has left

  753. marc0s has joined

  754. larma

    I'm thinking right now about the following: - Have a single message with the metadata for all files and a body that's displayed, but without the file sources. - Attach the file sources with follow up messages (one for each file) where the fallback of the follow up messages is a valid http file share in the legacy protocol This would be fully backwards compatible, allow for body, have all metatdata in the first message (allowing for generation of a nice widget) and even solve the issue of the delay caused by uploading the file we'd see if the HTTP source was directly in the metadata message.

  755. larma

    And clients that don't care about backwards compatibility can just put the file sources in the initial message.

  756. goffi

    putting source aftewards is a great idea, indeed with the upload delay

  757. goffi

    that looks quite good to me.

  758. jgart has joined

  759. Kev

    I don't see why you'd want to be delaying the information and forcing more work on modern clients for the sake of legacy clients. Surely the main priority should be the modern clients.

  760. MattJ

    OTOH this approach does have benefits beyond backwards compatibility

  761. Kev

    As long as you *can* include the sources in the first message, and don't rely on the rest of them, I can probably live with this. It's a nuisance for MAM servers having to collate all this stuff, but I guess it's not the first bit of nuisance for MAM servers.

  762. larma

    Source attaching is already a feature in 447 (and a very sensible one IMO) so the nuisance for MAM is already here ;)

  763. Kev

    But, from when we implemented this stuff, we deliberately want to delay sending the body message until the files are uploaded, because sending a message "Here are the files" ... *silence because the upload failed* seemed less helpful than the sender being able to choose not to send the message (or update the files first, e.g. to smaller ones).

  764. larma

    Kev: most other messengers announce the file before sending

  765. goffi

    If you encode a video or other large stuff, it would be great to send a message and receiving client can show "upload in progress" until it's done.

  766. Zash

    Wasn't there a XEP like that now?

  767. Zash

    Extension to chat states?

  768. Andrzej has left

  769. Kev

    > : most other messengers announce the file before sending I thought you were arguing earlier that most other messengers didn't send messages and files at the same time? :)

  770. larma

    It's relevant because you want the files to be displayed in the chat at the time they're sent, not the time when they arrive

  771. larma

    Kev: they even do for single files without text

  772. goffi

    larma: do you have some room to work on something like that in coming weeks? I really like this idea and it would help me to solve my issue with the AP gateway. I can help you if you want.

  773. mentos124 has joined

  774. Kev

    I can't remember ever seeing on another service "Someone sent a file, but the upload failed, but you've got this message saying you've got a file and if you try to download it you'll get an error". Maybe I'm exceptionally lucky, but I don't think I've seen it.

  775. singpolyma

    goffi: maybe we should build it and make sure it works before writing yet another XEP draft ;)

  776. mdosch

    > It's relevant because you want the files to be displayed in the chat at the time they're sent, not the time when they arrive How do they do this? Show a dummy/placeholder before the image/file arrives?

  777. goffi

    singpolyma: isn't it about updating XEP-0447?

  778. Zash

    Build it, take notes, turn notes to XEP? :)

  779. singpolyma

    Zash: indeed

  780. larma

    Kev: I've seen an file being removed from the chat because the uplaod failed

  781. goffi

    and yeah, that's what experimental is for.

  782. Zash

    An interesting thing would be to allow downloading a file at the same time as it's being uploaded, sorta streamed trough the http upload service...

  783. larma

    The changes to 0447 are actually rather small: - change such that the body is displayed - change the fallback example to use file attaching rather than the body of the metadata message.

  784. MattJ

    Zash, you mean like we used to have? Yeah... :)

  785. goffi

    and implement webtorrent, welcome to XMPPpeertube

  786. flashcube has joined

  787. Zash

    MattJ, `uploader http socket | tee storage | downloader http socket` :)

  788. Zash

    or like, async promise something something waiting for completion

  789. larma

    The changes to 0447 are actually rather small: - change such that the body is displayed (except if the updated fallback XEP is used to indicate the body is a fallback for 447) - change the fallback example to use file attaching rather than the body of the metadata message.

  790. MattJ

    If we did the multi-upload-slot thing (for upload resumption of large files), we could expose that to the recipient somehow

  791. MattJ

    But this is a tangent discussion I think :)

  792. neox has left

  793. neox has joined

  794. papatutuwawa has left

  795. larma

    Kev (or any other editor): mind merging https://github.com/xsf/xeps/pull/1188 soonish so I can properly use it in the updated 0447 and other places? Thanks

  796. nicola has left

  797. Kev

    I don't think Peter's active, so I think I'm the only one. I'm in the middle of time sensitive stuff for a couple of days, I'm really hoping to have an Editor blitz at the end of the week.

  798. Menel has left

  799. SteveF has left

  800. nicola has joined

  801. stp has joined

  802. singpolyma

    larma: thanks much for that fallback revision BTW, it has made several new features possible for us already

  803. Guus

    If, on an outbound S2S connection, an initiating server obtains a certificate from the receiving server that the initiating server cannot validate under local configuration settings, is there any way it is permissible to continue to use TLS for encryption (but not authentication) of that connection?

  804. Kev

    Sure, dialback if it's allowed.

  805. Guus

    (assuming that authentication happens through Dialb... that)

  806. Kev

    If you allow dialback, unauthenticated TLS is still better than no TLS.

  807. Guus

    I'm having trouble reading https://www.rfc-editor.org/rfc/rfc6120#section-5.4.3.1 in a way that this is permissible.

  808. Kev

    Well, 6120 removed Dialback, so under just 6120 TLS auth is the only permitted auth.

  809. Menel has joined

  810. Kev

    """ * Interoperability Note: At the time of writing, most deployed servers still use the Server Dialback protocol [XEP-0220] to provide weak identity verification instead of using SASL with PKIX certificates to provide strong authentication, especially in cases where SASL negotiation would not result in strong authentication anyway (e.g., because TLS negotiation was not mandated by the peer server, or because the PKIX certificate presented by the peer server during TLS negotiation is self-signed and has not been previously accepted); for details, see [XEP-0220]. The solutions specified in this document offer a significantly stronger level of security (see also Section 13.6). """ but it does mention that dialback for exactly this case.

  811. Zash

    Is that section for s2s?

  812. Kev

    """ * Interoperability Note: At the time of writing, most deployed servers still use the Server Dialback protocol [XEP-0220] to provide weak identity verification instead of using SASL with PKIX certificates to provide strong authentication, especially in cases where SASL negotiation would not result in strong authentication anyway (e.g., because TLS negotiation was not mandated by the peer server, or because the PKIX certificate presented by the peer server during TLS negotiation is self-signed and has not been previously accepted); for details, see [XEP-0220]. The solutions specified in this document offer a significantly stronger level of security (see also Section 13.6). """ but it does mention that dialback allows for exactly this case.

  813. Zash

    Guus: Is that section for s2s?

  814. Kev

    starttls in general, I believe.

  815. flashcube has left

  816. Zash

    > If the initiating entity presents a certificate Guus: I don't read this as requiring mutual TLS certificate authentication

  817. Guus

    I'm not talking about mutual authentication (or at least, I didn't intend to be)

  818. Guus

    The sections are about StartTLS in general (which I assume also apply to direct TLS, but that's another matter)

  819. Zash

    Direct TLS is just StartTLS squeezed into the TCP port number ;)

  820. Guus

    excellent compression rate.

  821. Zash

    I thought security and compression were a scary combo!

  822. Guus

    Kev: that interoperability note does mention dialback, but is that ment t be a permissive statement? I could also read this as: "we used to do this differently, but with this spec, you must now use TLS"

  823. Zash

    Guus, https://www.rfc-editor.org/rfc/rfc7590.html may also be relevant to your interests

  824. Guus

    > In particular for XMPP server-to-server interactions, it can be reasonable for XMPP server implementations to accept encrypted but unauthenticated connections when Server Dialback keys [XEP-0220] are used

  825. Guus

    Thanks guys.

  826. belove has left

  827. goffi

    larma: could you add an example for multiple files sharing in your update XEP please?

  828. belove has joined

  829. Rebeld has joined

  830. larma

    goffi: yes, I will

  831. floretta has left

  832. floretta has joined

  833. goffi

    larma: thx.

  834. Zash

    > [<starttls/>] stream feature might be stripped out by an attacker [...] > Therefore, the initiating entity MUST NOT be deterred from attempting > TLS negotiation even if the receiving entity does not advertise > support for TLS.

  835. belove has left

  836. deimos has joined

  837. belove has joined

  838. papatutuwawa has joined

  839. mentos124 has left

  840. Guus

    Zash: I was more thinking around the configuration of TLS, not the availability of it. As an example: do we allow self-signed certs? expired certs? etc.

  841. Zash

    Local policy? I.e. configurable

  842. floretta has left

  843. floretta has joined

  844. TheCoffeMaker has left

  845. TheCoffeMaker has joined

  846. MattJ

    Either you use TLS for authentication, or you don't. If you do, you can't just allow self-signed, expired, etc.

  847. MattJ

    If you use something else for authentication (e.g. dialback), those things don't matter at all

  848. Kev has left

  849. Steve Kille has left

  850. Kev has joined

  851. MattJ

    Prosody just has options to require TLS for authentication, and to require TLS for encryption

  852. MattJ

    On top of that we have plugins to e.g. authenticate self-signed certs using fingerprints

  853. Zash

    or DANE!

  854. Steve has joined

  855. MattJ

    or DANE :)

  856. Zash

    except DANE authenticates the server, not the client / "initiator" unless you do some Dialback dance

  857. Zash

    or ... 🥁️ ... DANCE

  858. Guus

    MattJ, I am very much not suggesting to _authenticate_ based on an expired cert. I was asking if it would be permissible to continue using TLS for encryption, if the peer presents an invalid certificate - assuming that some other form of authentication mechanism is used.

  859. MattJ

    Yes, that's kind of the point

  860. Guus

    The alternative being having an unencrypted connection that was authenticated using Dialback.

  861. Zash

    Relevant https://xmpp.org/extensions/xep-0344.html ?

  862. MattJ

    Practically everyone (on the public internet) requires encrypted connections these days

  863. MattJ

    https://github.com/stpeter/manifesto/blob/master/manifesto.txt

  864. Kev

    Sounds like Prosody does similar things to M-Link. Although we have an additional option for whether we allow a remote to authenticate us with dialback.

  865. Zash

    Kev, so outgoing and incoming dialback is separate? and/or, policy per remote host?

  866. MattJ

    Yeah, I think we just have dialback enabled or disabled entirely

  867. Guus

    I'm not quite sure what the distinction is that MattJ might be trying to communicate. I've got a feeling that we're all agreeing with each-other?

  868. Zash

    Guus, yes.

  869. Kev

    I forget our options offhand, but IIRC we can allow/require/disable TLS, allow/require/disable strong auth, and additionally enable/disable dialback.

  870. floretta has left

  871. Kev

    So it's possible for us to require the other end to present a cert we trust, but for it to use dialback to authenticate us rather than trusting our cert.

  872. sonny has left

  873. govanify has left

  874. SteveF has joined

  875. snow has joined

  876. sonny has joined

  877. govanify has joined

  878. floretta has joined

  879. antranigv has joined

  880. neox has left

  881. Chad has left

  882. pablo has joined

  883. neox has joined

  884. Calvin has joined

  885. daags has left

  886. petrescatraian has joined

  887. con3 has joined

  888. mentos124 has joined

  889. marc0s has left

  890. marc0s has joined

  891. moparisthebest

    Guus: imho dialback is never the correct option, but "same cert" can be if the protocol guarantees it's secure, ie for .onion domains

  892. MSavoritias (fae,ve)

    So we are all moving back to 0447 now? /s

  893. con3 has left

  894. jgart has left

  895. pablo has left

  896. Hugo has joined

  897. neshtaxmpp has left

  898. neshtaxmpp has joined

  899. Hugo has left

  900. Hugo has joined

  901. marc0s has left

  902. marc0s has joined

  903. TheCoffeMaker has left

  904. TheCoffeMaker has joined

  905. konstantinos has left

  906. daags has joined

  907. konstantinos has joined

  908. Hugo has left

  909. marc0s has left

  910. marc0s has joined

  911. david has joined

  912. david has left

  913. TheCoffeMaker has left

  914. TheCoffeMaker has joined

  915. SteveF has left

  916. david has joined

  917. david has left

  918. konstantinos has left

  919. TheCoffeMaker has left

  920. catchy has left

  921. catchy has joined

  922. TheCoffeMaker has joined

  923. djorz has joined

  924. marc0s has left

  925. marc0s has joined

  926. Menel has left

  927. Menel has joined

  928. marc0s has left

  929. marc0s has joined

  930. uhoreg has left

  931. Half-Shot has left

  932. Matthew has left

  933. homebeach has left

  934. Half-Shot has joined

  935. Matthew has joined

  936. homebeach has joined

  937. uhoreg has joined

  938. marc0s has left

  939. marc0s has joined

  940. Maranda[x] has left

  941. Maranda[x] has joined

  942. neshtaxmpp has left

  943. neshtaxmpp has joined

  944. papatutuwawa has left

  945. praveen has joined

  946. goldbeardp has left

  947. david has joined

  948. david has left

  949. marc0s has left

  950. marc0s has joined

  951. inky has left

  952. marc0s has left

  953. marc0s has joined

  954. marc0s has left

  955. marc0s has joined

  956. Tim R has left

  957. marc0s has left

  958. david has joined

  959. david has left

  960. marc0s has joined

  961. marc0s has left

  962. marc0s has joined

  963. Maranda[x] has left

  964. Maranda[x] has joined

  965. 775857429 has joined

  966. marc0s has left

  967. marc0s has joined

  968. marc0s has left

  969. marc0s has joined

  970. floretta has left

  971. marc0s has left

  972. marc0s has joined

  973. inky has joined

  974. konstantinos has joined

  975. Fishbowler has left

  976. Fishbowler has joined

  977. marc0s has left

  978. 644043 has joined

  979. neshtaxmpp has left

  980. atomicwatch has left

  981. marc0s has joined

  982. catchy has left

  983. catchy has joined

  984. floretta has joined

  985. djorz has left

  986. david has joined

  987. david has left

  988. Vaulor has left

  989. wladmis has left

  990. wladmis has joined

  991. goldbeardp has joined

  992. sonny has left

  993. neshtaxmpp has joined

  994. goldbeardp has left

  995. goldbeardp has joined

  996. sonny has joined

  997. antranigv has left

  998. Andrzej has joined

  999. mirux has left

  1000. mirux has joined

  1001. marc0s has left

  1002. marc0s has joined

  1003. djorz has joined

  1004. konstantinos has left

  1005. neshtaxmpp has left

  1006. neshtaxmpp has joined

  1007. praveen has left

  1008. floretta has left

  1009. sonny has left

  1010. pep.

    https://bifurcation.github.io/mimi-aim/draft-barnes-mimi-aim.html « ActivityPub for Interoperable Messaging »

  1011. pep.

    Is there a need for such a document for XMPP btw? Or are the RFCs acting as a proposal or sth?

  1012. pep.

    There's also a thing for Matrix

  1013. MattJ

    Yes, someone would need to write one for XMPP

  1014. MattJ

    Even if it is mostly "see RFC 6120" for most things

  1015. pep.

    Was that a point at summit or sth?

  1016. sonny has joined

  1017. MattJ

    It was touched upon, yes, as part of a broader strategy discussion

  1018. MSavoritias (fae,ve)

    https://www.ietf.org/archive/id/draft-rosenberg-mimi-protocol-00.txt

  1019. MSavoritias (fae,ve)

    there is also this one

  1020. goldbeardp has left

  1021. MSavoritias (fae,ve)

    its another http transport. not matrix or xmpp based

  1022. pep.

    TIL https://www.rfc-editor.org/rfc/rfc7702 "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat"

  1023. pep.

    Another groupchat spec?

  1024. floretta has joined

  1025. pep.

    (t's referenced in the MIMI-AP thing)

  1026. neox has left

  1027. neox has joined

  1028. pep.

    MattJ, that means there are people on it?

  1029. MattJ

    Nobody actively, that I'm aware of

  1030. pep.

    Ok. Right now I wonder if we're gonna miss a deadline again because "there's nobody to do it" / "no money on the table"

  1031. Zash

    The deadline is already passed, innit?

  1032. MattJ

    I believe so

  1033. pep.

    great

  1034. mentos124 has left

  1035. Zash

    per https://mailarchive.ietf.org/arch/msg/mimi/alm5aSR0e20fuEM6z2RhIwyJuq4/

  1036. pep.

    So we don't have anything there, that settles it no?

  1037. MattJ

    Nothing is settled

  1038. pep.

    But we still don't have anything there

  1039. raucao has left

  1040. raucao has joined

  1041. MattJ

    Are you volunteering to write the draft?

  1042. pep.

    I would, but I'm really not good with all the blabla that needs to go in these things

  1043. BASSGOD has left

  1044. pep.

    I'd rather have the XSF pay someone that's good at this

  1045. MattJ

    Who is that, then? (aka "here we go again...") :)

  1046. snow has left

  1047. pep.

    Apart from the fact that this could have been done months ago, "I don't know, send something on members@ and ask if anyone is interested against compensation"

  1048. Wojtek has left

  1049. pep.

    Looks like it's important enough that it was mentioned at Summit and is part of a broader "strategy discussion". Hopefully for this one getting money out won't be this complicated

  1050. MattJ

    I have made multiple posts to members@

  1051. MSavoritias (fae,ve)

    fyi we are mentioned on https://datatracker.ietf.org/doc/draft-rosenberg-mimi-arch-options/

  1052. pep.

    Reading through the mails (I'm not on member I haven't seen them come through)

  1053. pep.

    Reading through the mails (I'm not on members@ I haven't seen them come through)

  1054. MSavoritias (fae,ve)

    there has been two

  1055. MSavoritias (fae,ve)

    https://mail.jabber.org/pipermail/members/2022-November/009472.html

  1056. MSavoritias (fae,ve)

    https://mail.jabber.org/pipermail/members/2022-July/009417.html

  1057. MSavoritias (fae,ve)

    but none of them mention money or a proposal

  1058. MSavoritias (fae,ve)

    as i can see

  1059. MSavoritias (fae,ve)

    from what i see the consensus is that the xmpp standards that exist within ietf are enough

  1060. MSavoritias (fae,ve)

    and matrix and such need to draft proposals because they are not a standard

  1061. marc0s has left

  1062. pep.

    If that's enough to be considered in MIMI then fine. Also why I asked that question first

  1063. MattJ

    Whatever your definition of "standard" may be, that's not enough. Even if you think RFC 6120 satisfies all the MIMI requirements, a document stating and demonstrating this would still be beneficial.

  1064. Zash

    And to remind people XMPP exists

  1065. pablo has joined

  1066. pep.

    Which we're always doing a great job at :P

  1067. MSavoritias (fae,ve)

    well no mention that we are looking for such a person has been made outside of this room as i am aware so..

  1068. MSavoritias (fae,ve)

    for the person and the proposal i mean

  1069. neshtaxmpp has left

  1070. moparisthebest

    Anyone capable and willing to write it is in this room already

  1071. MattJ

    I'm not engaging in this cyclic discussion about money and proposals again, we've had it too many times with the same participants, and nothing has changed since last time. I'm working on other stuff right now.

  1072. papatutuwawa has joined

  1073. MattJ

    If someone is blocked on working on something due to financial reasons, the XSF is in a position to help

  1074. marc0s has joined

  1075. MattJ

    But as usual, I am not aware that such a situation exists

  1076. neshtaxmpp has joined

  1077. Trung

    does telegram|whatsapp|facebook|… have some sort of a rfc or draft? To me they seems to be the standard for ordinary users

  1078. mentos124 has joined

  1079. Menel has left

  1080. Zash

    Are they even involved in this MIMI WG yet?

  1081. snow has joined

  1082. Zash

    (Not that I have seen)

  1083. pep.

    MattJ, thanks for the mails they're helpful

  1084. pep.

    Zash, they get a pass, they got the monies

  1085. MattJ

    WhatsApp/Facebook have stated they are not interested, I'm not aware that anyone else considered a gatekeeper has made any public statements

  1086. Zash

    MattJ, source?

  1087. MSavoritias (fae,ve)

    it was in the meeting recently at the eu day

  1088. Zash

    Plus IETF isn't an EU standards org, so there's some uncertainty at whether any of this will really go anywhere in the end

  1089. MSavoritias (fae,ve)

    they said they want something with signal based encryption

  1090. MSavoritias (fae,ve)

    not MLS

  1091. farenr has joined

  1092. Zash

    Ah. I should (re?)read the notes from that

  1093. Menel has joined

  1094. Wojtek has joined

  1095. inky has left

  1096. BASSGOD has joined

  1097. daags has left

  1098. neshtaxmpp has left

  1099. neshtaxmpp has joined

  1100. Vidak has left

  1101. inky has joined

  1102. Vidak has joined

  1103. wladmis has left

  1104. wladmis has joined

  1105. david has joined

  1106. david has left

  1107. sonny has left

  1108. sonny has joined

  1109. pablo has left

  1110. farenr has left

  1111. pep.

    Ok, I guess count me out of the MIMI stuff. Thinking about it I don't know why I am affected by it. It looks like the only thing that it may bring that I care about is "Hey look XMPP isn't dead". And maybe make it more easy on XMPP devs because we wouldn't have to write the bridging parts.. Entities to which it would bridge (bigtech) I don't want anything to do with them..

  1112. pep.

    Ok, I guess count me out of the MIMI stuff. Thinking about it I don't know why I am affected by it. It looks like the only thing that it may bring that I care about is "Hey look XMPP isn't dead". And maybe make it more easy on XMPP devs because we wouldn't have to write the bridging parts.. Entities to which it would bridge (bigtech) I don't want anything to do with..

  1113. pablo has joined

  1114. 775857429 has left

  1115. belove has left

  1116. belove has joined

  1117. Vidak has left

  1118. belove has left

  1119. david has joined

  1120. david has left

  1121. Andrzej has left

  1122. daags has joined

  1123. belove has joined

  1124. Vaulor has joined

  1125. floretta has left

  1126. 775857429 has joined

  1127. 775857429 has left

  1128. mentos124 has left

  1129. belove has left

  1130. Yagiza has left

  1131. konstantinos has joined

  1132. sonny has left

  1133. Trung

    Thank you for the the report MattJ. I was busy messing with your software (and Zashs') at that time. I'm going to throw my own opinion in here now that I know these things exists: 1) MLS looks like it is short for a 'Messy Layer of Security' in the similar fashion as Android is stucked on top of Linux. (Why don't you just use Linux in the first place and save the hassle of vendor restricting security updates?) 2) MIMI looks like the description of Slidge and this very XSF|XEP stuff that we have. Most importantly, both look very much like patches for closed source software to talk to each other. Please notice that I am *not* saying the people who are behind them are working for 'gate-keepers' here. So best I say to all devs is to ignore both of these things and focus on writing great open source software. As I understand how all these eXempt-Pee-Pee to work together, all you need for interoperability is to throw a XEP out when your stuff are working so everyone else knows how to do the same dance.

  1134. belove has joined

  1135. MSavoritias (fae,ve)

    from what i have heard MLS is not that bad

  1136. Zash

    Trung, "Dear gatekeepers, if you want to have interoperability, here's one way you could do it. Best wishes from the IETF"

  1137. bean has joined

  1138. pablo has left

  1139. moparisthebest

    And that way is XMPP, always has been

  1140. moparisthebest

    As evidenced by the fact they all ran open XMPP until they had sufficient mass for vendor lock-in

  1141. sonny has joined

  1142. belove has left

  1143. belove has joined

  1144. inky has left

  1145. pablo has joined

  1146. Vidak has joined

  1147. emus has left

  1148. david has joined

  1149. david has left

  1150. tbm16 has joined

  1151. Dele Olajide has left

  1152. belove has left

  1153. belove has joined

  1154. floretta has joined

  1155. pablo has left

  1156. snow has left

  1157. oshn has left

  1158. Mikaela has left

  1159. oshn has joined

  1160. pablo has joined

  1161. mentos124 has joined

  1162. pablo has left

  1163. pablo has joined

  1164. pablo has left

  1165. david has joined

  1166. david has left

  1167. petrescatraian has left

  1168. catchy has left

  1169. pablo has joined

  1170. antranigv has joined

  1171. chipmnk has left

  1172. chipmnk has joined

  1173. jgart has joined

  1174. 775857429 has joined

  1175. *IM* has left

  1176. xengineering has left

  1177. *IM* has joined

  1178. xengineering has joined

  1179. bean has left

  1180. Andrzej has joined

  1181. catchy has joined

  1182. edhelas

    I have a 0060 related question there https://github.com/processone/ejabberd/issues/3044#issuecomment-1478572573

  1183. belove has left

  1184. edhelas

    When pubsub#publish_options is available, are all the fields defined in https://xmpp.org/extensions/xep-0060.html#registrar-formtypes-config supported ? Or can the server only support a whitelist of it ? If its the case how can I know which fields I can set ?

  1185. belove has joined

  1186. singpolyma

    moparisthebest: "all" is a bit strong since only google has ever done that at scale

  1187. singpolyma

    Hey all: should https://xmpp.org/registrar/querytypes.html#register list the preauth query param?

  1188. moparisthebest

    singpolyma: Facebook did too right?

  1189. moparisthebest

    And WhatsApp started out as XMPP, but as far as I know not federated

  1190. Daniel

    edhelas: I think the intent is really all

  1191. 775857429 has left

  1192. Zash

    moparisthebest, facebook only ever did c2s

  1193. Daniel

    All the server supports

  1194. Daniel

    And can plausibly use in this auto create mode

  1195. edhelas

    > edhelas: I think the intent is really all So basically the same fields as when I'm doing a complete Pubsub node configuration ? https://xmpp.org/extensions/xep-0060.html#registrar-formtypes-config

  1196. edhelas

    Zash is it how it is done in Prosody ?

  1197. edhelas

    Okay thanks :)

  1198. Andrzej has left

  1199. Zash

    Knee deep in other things atm, no idea

  1200. Trung has left

  1201. Trung has joined

  1202. Daniel

    If someone finds an edge case of when or why this wouldn't work on the server side I'm happy to hear it and we can figure something else out

  1203. Daniel

    But the way I'm implementing it in the client is that if the publish options fail due to conflict I'm feeding the exact same form data into a node reconfiguration

  1204. edhelas

    Smart indeed

  1205. edhelas

    I might also do that

  1206. BASSGOD has left

  1207. Martin has left

  1208. Trung has left

  1209. BASSGOD has joined

  1210. Trung has joined

  1211. flashcore has left

  1212. inky has joined

  1213. Trung has left

  1214. Trung has joined

  1215. BASSGOD has left

  1216. Trung has left

  1217. Trung has joined

  1218. daags has left

  1219. david has joined

  1220. david has left

  1221. 644043 has left

  1222. snow has joined

  1223. Trung has left

  1224. Trung has joined

  1225. Vaulor has left

  1226. Vaulor has joined

  1227. Seve has left

  1228. Axel R. has left

  1229. goffi has left

  1230. daags has joined

  1231. konstantinos has left

  1232. emus has joined

  1233. Seve has joined

  1234. moparisthebest

    Zash: yea still that's XMPP for interop

  1235. atomicwatch has joined

  1236. atomicwatch has left

  1237. singpolyma

    Interop with clients isn't super interesting IMO

  1238. pablo has left

  1239. singpolyma

    Especially the barely works degenerate way that Facebook did it 😅

  1240. atomicwatch has joined

  1241. atomicwatch has left

  1242. atomicwatch has joined

  1243. atomicwatch has left

  1244. atomicwatch has joined

  1245. atomicwatch has left

  1246. atomicwatch has joined

  1247. atomicwatch has left

  1248. atomicwatch has joined

  1249. atomicwatch has left

  1250. atomicwatch has joined

  1251. atomicwatch has left

  1252. atomicwatch has joined

  1253. atomicwatch has left

  1254. atomicwatch has joined

  1255. atomicwatch has left

  1256. tbm16 has left

  1257. atomicwatch has joined

  1258. atomicwatch has left

  1259. matthias has left

  1260. atomicwatch has joined

  1261. atomicwatch has left

  1262. atomicwatch has joined

  1263. atomicwatch has left

  1264. mirux has left

  1265. BASSGOD has joined

  1266. atomicwatch has joined

  1267. atomicwatch has left

  1268. atomicwatch has joined

  1269. Skull Fucker has joined

  1270. belove has left

  1271. MSavoritias (fae,ve) has left

  1272. belove has joined

  1273. atomicwatch has left

  1274. atomicwatch has joined

  1275. Mario Sabatino has left

  1276. zonsopkomst has left

  1277. atomicwatch has left

  1278. pablo has joined

  1279. Skull Fucker has left

  1280. Skull Fucker has joined

  1281. asterix has left

  1282. asterix has joined

  1283. Wojtek has left

  1284. Menel has left

  1285. Vaulor has left

  1286. Vaulor has joined

  1287. mirux has joined

  1288. marc0s has left

  1289. Titi has left

  1290. 644043 has joined

  1291. Martin has joined

  1292. marc0s has joined

  1293. atomicwatch has joined

  1294. atomicwatch has left

  1295. 644043 has left

  1296. xnamed has left

  1297. atomicwatch has joined

  1298. tbm16 has joined

  1299. neox has left

  1300. Skull Fucker has left

  1301. neox has joined

  1302. Skull Fucker has joined

  1303. Skull Fucker has left

  1304. farenr has joined

  1305. atomicwatch has left

  1306. papatutuwawa has left

  1307. mirux has left

  1308. oshn has left

  1309. catchy has left

  1310. atomicwatch has joined

  1311. rubi has left

  1312. rubi has joined

  1313. Hugo has joined

  1314. kurisu has left

  1315. mentos124 has left

  1316. asterix has left

  1317. asterix has joined

  1318. mentos124 has joined

  1319. Vaulor has left

  1320. Vaulor has joined

  1321. atomicwatch has left

  1322. atomicwatch has joined

  1323. atomicwatch has left

  1324. Hugo has left

  1325. intosi has left

  1326. intosi has joined

  1327. atomicwatch has joined

  1328. atomicwatch has left

  1329. atomicwatch has joined

  1330. Kev has left

  1331. pablo has left

  1332. oshn has joined

  1333. atomicwatch has left

  1334. atomicwatch has joined

  1335. atomicwatch has left

  1336. atomicwatch has joined

  1337. Hugo has joined

  1338. Wojtek has joined

  1339. gooya has left

  1340. andrey.g has joined

  1341. 644043 has joined

  1342. zonsopkomst has joined

  1343. oshn has left

  1344. atomicwatch has left

  1345. atomicwatch has joined

  1346. Hugo has left

  1347. david has joined

  1348. david has left