XSF Discussion - 2019-11-03

  1. mimi89999 has left

  2. mimi89999 has joined

  3. remko has left

  4. mimi89999 has left

  5. mimi89999 has joined

  6. karoshi has left

  7. krauq has left

  8. krauq has joined

  9. debacle has joined

  10. mimi89999 has left

  11. Mikaela has left

  12. mimi89999 has joined

  13. mimi89999 has left

  14. mimi89999 has joined

  15. david has left

  16. jubalh has joined

  17. david has joined

  18. Daniel has left

  19. jubalh has left

  20. mathijs has left

  21. mathijs has joined

  22. mimi89999 has left

  23. mimi89999 has joined

  24. mimi89999 has left

  25. mimi89999 has joined

  26. mimi89999 has left

  27. mimi89999 has joined

  28. Daniel has joined

  29. Tobias has left

  30. lskdjf has left

  31. pdurbin has joined

  32. Chobbes has joined

  33. xalek has joined

  34. pdurbin has left

  35. debacle has left

  36. xalek has left

  37. xalek has joined

  38. remko has joined

  39. mukt2 has left

  40. adiaholic has left

  41. adiaholic has joined

  42. mukt2 has joined

  43. andy has left

  44. Chobbes has left

  45. Chobbes has joined

  46. j.r has left

  47. Chobbes has left

  48. mukt2 has left

  49. pdurbin has joined

  50. neshtaxmpp has left

  51. neshtaxmpp has joined

  52. andrey.g has joined

  53. andrey.g has left

  54. andrey.g has joined

  55. emus has left

  56. Douglas Terabyte has left

  57. Douglas Terabyte has joined

  58. mathijs has left

  59. Daniel has left

  60. mathijs has joined

  61. remko has left

  62. Daniel has joined

  63. mathijs has left

  64. mathijs has joined

  65. mathijs has left

  66. mathijs has joined

  67. remko has joined

  68. mukt2 has joined

  69. pdurbin has left

  70. mathijs has left

  71. mathijs has joined

  72. mathijs has left

  73. mathijs has joined

  74. debxwoody has left

  75. mukt2 has left

  76. debxwoody has joined

  77. mukt2 has joined

  78. Daniel has left

  79. Daniel has joined

  80. waqas has joined

  81. adiaholic has left

  82. krauq has left

  83. Douglas Terabyte has left

  84. winfried has left

  85. winfried has joined

  86. adiaholic has joined

  87. winfried has left

  88. winfried has joined

  89. winfried has left

  90. winfried has joined

  91. mimi89999 has left

  92. mimi89999 has joined

  93. aj has left

  94. Shell has left

  95. Shell has joined

  96. Shell has left

  97. Shell has joined

  98. Shell has left

  99. Shell has joined

  100. mukt2 has left

  101. lskdjf has joined

  102. APach has joined

  103. wurstsalat has left

  104. winfried has left

  105. winfried has joined

  106. winfried has left

  107. winfried has joined

  108. pdurbin has joined

  109. lskdjf has left

  110. adiaholic has left

  111. debxwoody has left

  112. mukt2 has joined

  113. xalek has left

  114. pdurbin has left

  115. mukt2 has left

  116. adiaholic has joined

  117. mukt2 has joined

  118. mukt2 has left

  119. remko has left

  120. remko has joined

  121. rion has left

  122. debxwoody has joined

  123. rion has joined

  124. mukt2 has joined

  125. remko has left

  126. remko has joined

  127. debxwoody has left

  128. debxwoody has joined

  129. remko has left

  130. remko has joined

  131. remko has left

  132. remko has joined

  133. jubalh has joined

  134. Tobias has joined

  135. mukt2 has left

  136. mukt2 has joined

  137. Daniel has left

  138. remko has left

  139. Daniel has joined

  140. andy has joined

  141. jubalh has left

  142. pdurbin has joined

  143. remko has joined

  144. winfried has left

  145. winfried has joined

  146. adiaholic has left

  147. adiaholic has joined

  148. rion has left

  149. karoshi has joined

  150. mathijs has left

  151. mathijs has joined

  152. Nekit has left

  153. mathijs has left

  154. mathijs has joined

  155. pdurbin has left

  156. aj has joined

  157. winfried has left

  158. winfried has joined

  159. lovetox has joined

  160. winfried has left

  161. winfried has joined

  162. wurstsalat has joined

  163. mimi89999 has left

  164. winfried has left

  165. winfried has joined

  166. winfried has left

  167. winfried has joined

  168. winfried has left

  169. winfried has joined

  170. emus has joined

  171. winfried has left

  172. winfried has joined

  173. mukt2 has left

  174. waqas has left

  175. Mikaela has joined

  176. mimi89999 has joined

  177. mukt2 has joined

  178. mukt2 has left

  179. alameyo has left

  180. alameyo has joined

  181. debacle has joined

  182. mukt2 has joined

  183. alameyo has left

  184. winfried has left

  185. winfried has joined

  186. !XSF_Martin has left

  187. alameyo has joined

  188. winfried has left

  189. winfried has joined

  190. marc_ has joined

  191. winfried has left

  192. winfried has joined

  193. !XSF_Martin has joined

  194. debacle has left

  195. debacle has joined

  196. winfried has left

  197. winfried has joined

  198. mukt2 has left

  199. dwd has joined

  200. mukt2 has joined

  201. j.r has joined

  202. kokonoe has left

  203. kokonoe has joined

  204. alameyo has left

  205. alameyo has joined

  206. lskdjf has joined

  207. adiaholic has left

  208. marc_ has left

  209. mukt2 has left

  210. marc_ has joined

  211. jubalh has joined

  212. winfried has left

  213. winfried has joined

  214. winfried has left

  215. winfried has joined

  216. pdurbin has joined

  217. !XSF_Martin has left

  218. debacle has left

  219. debacle has joined

  220. !XSF_Martin has joined

  221. debacle has left

  222. debacle has joined

  223. mukt2 has joined

  224. debacle has left

  225. debacle has joined

  226. adiaholic has joined

  227. debacle has left

  228. debacle has joined

  229. pdurbin has left

  230. debacle has left

  231. debacle has joined

  232. adiaholic has left

  233. mukt2 has left

  234. adiaholic has joined

  235. LNJ has joined

  236. Shell has left

  237. LNJ has left

  238. LNJ has joined

  239. mathijs has left

  240. mathijs has joined

  241. mathijs has left

  242. mathijs has joined

  243. mathijs has left

  244. mathijs has joined

  245. mukt2 has joined

  246. mathijs has left

  247. mathijs has joined

  248. mukt2 has left

  249. adiaholic has left

  250. winfried has left

  251. winfried has joined

  252. jubalh has left

  253. jubalh has joined

  254. mukt2 has joined

  255. winfried has left

  256. winfried has joined

  257. adiaholic has joined

  258. mathijs has left

  259. mathijs has joined

  260. Chobbes has joined

  261. mukt2 has left

  262. dwd has left

  263. dwd has joined

  264. Chobbes has left

  265. winfried has left

  266. winfried has joined

  267. Chobbes has joined

  268. marc_ has left

  269. marc_ has joined

  270. winfried has left

  271. winfried has joined

  272. winfried has left

  273. winfried has joined

  274. mathijs has left

  275. mathijs has joined

  276. winfried has left

  277. winfried has joined

  278. j.r has left

  279. dwd has left

  280. dwd has joined

  281. matlag has left

  282. winfried has left

  283. winfried has joined

  284. mathijs has left

  285. mathijs has joined

  286. j.r has joined

  287. matlag has joined

  288. winfried has left

  289. winfried has joined

  290. mukt2 has joined

  291. Chobbes has left

  292. kokonoe has left

  293. mukt2 has left

  294. pdurbin has joined

  295. adiaholic has left

  296. Guus has left

  297. Guus has joined

  298. Chobbes has joined

  299. winfried has left

  300. winfried has joined

  301. winfried has left

  302. kokonoe has joined

  303. winfried has joined

  304. winfried has left

  305. winfried has joined

  306. winfried has left

  307. winfried has joined

  308. pdurbin has left

  309. winfried has left

  310. winfried has joined

  311. goffi has joined

  312. Chobbes has left

  313. Chobbes has joined

  314. winfried has left

  315. winfried has joined

  316. Link Mauve

    Why is SXE based on message instead of iq?

  317. Link Mauve

    Also, why is it entirely ad-hoc instead of reusing e.g. MUC or PubSub primitives?

  318. Zash

    Why not?

  319. Link Mauve

    Zash, because the semantics very much match iqs.

  320. pep.


  321. Link Mauve


  322. pep.


  323. Chobbes has left

  324. winfried has left

  325. winfried has joined

  326. Link Mauve

    Also, why is there both a Jingle initialisation and another initialisation based on messages afterward?

  327. larma

    Link Mauve, I guess so that you don't have to ack state changes? Not that I like it, but it could have been the motivation. And also doesn't apply to the initial state offer which really is exactly iq semantics.

  328. winfried has left

  329. larma

    Because someone said: "You should use Jingle for that"? 😀

  330. Link Mauve

    Most likely; I’ll have to go and read the council minutes from back then.

  331. Shell has joined

  332. larma

    Seems it was only added in 0.0.8, but there is no history from before 2010 in git 🙁

  333. winfried has joined

  334. winfried has left

  335. winfried has joined

  336. Link Mauve

    virtual void send( const std::string& message, const std::string& subject, const StanzaExtensionList& sel = StanzaExtensionList() );

  337. Link Mauve

    And what if I want to send a message without a body and a subject…?

  338. mathijs has left

  339. mathijs has joined

  340. jonas’

    "", ""

  341. jonas’


  342. Link Mauve


  343. jonas’


  344. Link Mauve

    This is an API I probably can’t modify.

  345. jonas’


  346. Link Mauve

    I could add a new one I guess.

  347. Link Mauve

    Still not sure why I’m doing this in C++ and not in Rust.

  348. jonas’

    because C++ is more awesome than this newfangled mess of "systems programming" languages :)

  349. kokonoe has left

  350. Link Mauve

    I’m not doing systems programming though, just adding collaborativeness to a text editor.

  351. Zash

    Link Mauve: Aaaah, CW those C++ lines plz!!!! NSFMybrain

  352. Link Mauve

    Sorry, XEP-0382 still isn’t implemented in my client.

  353. larma

    Link Mauve, how is your council candidacy going? Not sure which timezone we are using for the deadline, but it's something like today...

  354. Link Mauve

    Some timezone. :)

  355. Link Mauve

    I’ll start working on it once I give up on this C++.

  356. mukt2 has joined

  357. larma

    You can not become a candidate after the election 😉

  358. Link Mauve

    I know that!

  359. winfried has left

  360. winfried has joined

  361. dwd has left

  362. dwd has joined

  363. debacle has left

  364. adiaholic has joined

  365. mathijs has left

  366. mathijs has joined

  367. mukt2 has left

  368. adiaholic has left

  369. adiaholic has joined

  370. winfried has left

  371. winfried has joined

  372. mukt2 has joined

  373. winfried has left

  374. winfried has joined

  375. mathijs has left

  376. mathijs has joined

  377. Ge0rG

    Link Mauve: just give up on it. I never thought I'd say that, but: RIIR!

  378. Zash


  379. Zash


  380. winfried has left

  381. winfried has joined

  382. jonas’

    we already have >5 candidates. I am amazed

  383. jonas’

    and two new ones at that

  384. Link Mauve

    Ge0rG, I wonder if Swiften might not be better than gloox.

  385. Link Mauve

    But I’ll definitely have to fix the SXE spec too.

  386. Zash

    Link Mauve: Existing thing already using gloox?

  387. Link Mauve

    No, it isn’t collaborative yet.

  388. jonas’

    larma, from your application > That said, my criteria for accepting a XEP as experimental would be: […]

  389. jonas’

    I think this misses an important part (which is even mentioned in XEP-0001 IIRC): "It should not duplicate existing protocols."

  390. jonas’

    although that might be implicit in "It should solve a problem."

  391. larma

    Yeah, I think it's implicit in there. A duplicate doesn't solve any problems

  392. jonas’

    fair enough

  393. jonas’

    in any case, thanks for running

  394. winfried has left

  395. winfried has joined

  396. Zash

    jonas’: How do you replace / improve on existing things without duplication?

  397. Zash

    Does XEP-0313 not duplicate some subset of XEP-0136?

  398. winfried has left

  399. winfried has joined

  400. kokonoe has joined

  401. winfried has left

  402. winfried has joined

  403. pep.

    Ge0rG, https://i.imgur.com/10k62WA.png RIIR!

  404. pep.

    larma, ^

  405. Zash

    RIIR https://www.r-project.org/

  406. pep.


  407. marc_ has left

  408. marc_ has joined

  409. Mikaela has left

  410. Mikaela has joined

  411. Chobbes has joined

  412. winfried has left

  413. winfried has joined

  414. rion has joined

  415. larma

    pep., I will consider it for version 2.0 😉

  416. pep.


  417. mathijs has left

  418. mathijs has joined

  419. winfried has left

  420. winfried has joined

  421. jonas’

    larma, re your council election again and since you have an interesting view about personal opinions: One thing which has repeatedly come up is the debate between amending existing standards vs. creating new documents to add features (specifically around XEP-0045 and XEP-0060). Do you think this is a matter of opinion or "taste"? If not, what is the objectively correct way? If it is, how would voting on this question work with your goal to avoid personal preferences?

  422. jubalh has left

  423. jubalh has joined

  424. mukt2 has left

  425. winfried has left

  426. winfried has joined

  427. pep.

    jonas’, tbh, I don't care which, but I want things to move

  428. pep.

    I think it's similar for larma(?)

  429. Nekit has joined

  430. larma

    jonas’, I just put something related to that topic on my candidacy page. 1. I think both 45 and 60 should probably be Final already. Most of the changes actually applied to them could be done to Final XEPs as well. 2. Many of the changes proposed to 45 and 60 could also be standalone XEPs. 3. Even if things are not properly defined, it can be later clarified that they are not part of that specification and (even opposing) proposals can then be made in new XEPs (for example IQ routing in 45).

  431. pep.

    To me it's exactly the same if somebody modifies a XEP or recreates a new XEP amending the first one. it's just the form. We as a group could settle on sth if necessary

  432. jonas’

    larma, thanks

  433. larma

    pep., yes and no: the rules how things are advanced to Draft should also apply to significant changes and that won't be possible without a new XEP.

  434. Daniel has left

  435. jonas’

    larma, I think you make a very good point in that

  436. Daniel has joined

  437. pep.

    larma, but in the end, you add a new disco feature anyway

  438. jonas’

    and at that point it’s questionable whether namespace bumps should be needed at all anymore... but that’s a bigger topic, too big for me right now (-> afk)

  439. larma

    I would like to get rid of "namespace bumps" and introduce "new namespaces" in new XEPs (which might just look like a namespace bump, i.e. can have only a version number added/increased)

  440. pep.

    "which might just look like a namespace bump", it's exactly the same to me indeed. and I'm fine with both, as long as things move

  441. adiaholic has left

  442. adiaholic has joined

  443. Zash


  444. pep.


  445. Zash

    Namespaced mini-extension protocols without breaking everything using the previous version/namespace?

  446. winfried has left

  447. winfried has joined

  448. pdurbin has joined

  449. winfried has left

  450. winfried has joined

  451. pep.

    "without breaking everything using the previous version/namespace", we're not magicians

  452. Zash

    Something something like semantic versioning? You can to some extent add new stuff without replacing the namespace.

  453. waqas has joined

  454. waqas has left

  455. waqas has joined

  456. pep.

    You mean "clarify"

  457. Zash


  458. aj has left

  459. Zash

    I mean add new features

  460. Zash

    Something supporting the previous version won't know about those features, so no problem.

  461. pep.

    Yeah ok that's fine. I'm mostly talking about breaking stuff

  462. Zash

    I'm confused

  463. winfried has left

  464. winfried has joined

  465. winfried has left

  466. winfried has joined

  467. adiaholic has left

  468. adiaholic has joined

  469. Mikaela has left

  470. Mikaela has joined

  471. Mikaela has left

  472. larma

    Namespace bumps should in general be barely needed IMO. Most of it can be done using disco and just additional elements

  473. larma

    but of course it's so much easier to just break things and do a namespace bump

  474. Zash


  475. larma

    Well it's easier for the XEP author, not easier for the developers 😉

  476. flow

    I don't think that you can make a specific statement, it really depends on the specific case.

  477. flow

    err "generic statement"

  478. larma


  479. larma

    I am also not against new namespaces, I just feel they belong in a new XEP

  480. pdurbin has left

  481. flow

    A fresh experimental XEP only a few months old where are developers, and that includes implementing developers, are in the same groupchat is probably easier to namespace bump than a year old xep in draft state

  482. larma

    If it's easy to namespace bump, it's also easy to just not namespace bump. That's exactly the point

  483. flow

    so what's your stance on jingle ft then? should be collect improvements and bump it?

  484. larma

    flow, not sure what improvements are you talking about?

  485. larma

    IMO Jingle FT should be at least Draft already, so if there are significant changes required they should go in a new XEP

  486. flow

    I wouldn't be suprised to find some if I am going to implement it.

  487. Zash

    Maybe what we should do is bump the namespace of Experimental XEPs even more often, so everyone either gets used to it or gets together and makes it Draft?

  488. flow

    larma, so what is the advantage if having a new XEP versus a major overhaul of the existing? (note that i have no strong opinion in that direction, just wanting to hear the rationale behind it)

  489. winfried has left

  490. winfried has joined

  491. Shell has left

  492. Shell has joined

  493. larma

    Zash, would actually be fine as well. Point is: Experimental XEPs should be deployed in wild, so any changes (if they bump namespace or not) shouldn't have any influence on any running systems.

  494. flow

    I'm not opposed to having Jingle-FT-2, but it doesn't feel like the question if we should new-xep or bump-the-existing-xep is something that tackles our most important issues

  495. rion

    Jingle-ft is fine as for me. Maybe separate XEPs may describe various meta information for it. Like it was done with thumbnails. Jingle-s5b needs fixes

  496. larma

    flow, If it's a new protocol it should get a new XEP number so we have a proper name/identifier for the protocol.

  497. Zash

    Jingle FT Base and a File Metadata XEP?

  498. larma

    "My server supports archives." "Which version?" "XEP-0313" isn't really helpful

  499. Zash

    larma, "XEP-0313 v0.6" tho?

  500. Zash

    == `urn:xmpp:mam:2`

  501. goffi has left

  502. goffi has joined

  503. larma

    So we don't define protocols in XEPs anymore but in XEP versions?

  504. larma

    and a different version could be a completely different protocol?

  505. Zash

    That's how it is now

  506. larma

    Only for very few XEPs, and I consider this an issue.

  507. winfried has left

  508. winfried has joined

  509. Ge0rG

    So we should define protocols by namespaces instead?

  510. Zash

    Don't we already, in a way?

  511. winfried has left

  512. winfried has joined

  513. Ge0rG

    On the wire, but not in the documentation.

  514. flow

    larma> flow, not sure what improvements are you talking about? That is actually a nice example for one of the major issues we have. We are incredibly bad at collecting and organizing protocol feedback, leave allone incooperating it into a new protocol revision

  515. Ge0rG

    Speaking of which, do I need to rewrite CS-2020 now in terms of feature namespaces? Which version of MAM should it require? From clients? From servers?

  516. Zash

    This seems like pain that comes naturally from having protocols under development be implemented and deployed in the wild.

  517. larma

    We don't always change namespace for protocol changes of Experimental XEPs

  518. flow

    Ge0rG, "From Client? From servers"? What is the issue if the compliance suites that state xep313 (and that implies the current state of xep313)?

  519. rion

    Ah yes. Jingle-ft needs some clarification how to properly finish file transfer. For example when we have multiple files in one session. Or when final checksum isn't sent

  520. larma

    Probably nobody would care to bump the references namespace if 372 is changes...

  521. kokonoe has left

  522. flow

    larma, I think there is a sensible policy that protocol changes that break interoperability require a namespace bump in place

  523. Ge0rG

    larma: normally we do bump, except under very closely defined conditions.

  524. winfried has left

  525. winfried has joined

  526. Zash

    > that break interoperability This!

  527. Ge0rG

    flow: that it's not clear at which moment of time that version is pinned. On January 1st?

  528. flow

    Ge0rG, who said something about pinning the version? :)

  529. larma

    Ge0rG, I had the feeling we bump if it would break interoperability of live deployments. As per XEP-0001 there shouldn't be live deployments of Experimental XEPs so there shouldn't be namespace bumps. Draft XEPs should and Final XEPs must not break interoperability, so no chance of a namespace bump there.

  530. Ge0rG

    We _normally_ don't bump if it doesn't affect interoperability, but this is not what larma was asking about?

  531. Ge0rG

    flow: you implied that. Otherwise, what happens if a namespace is bumped during the CS year?

  532. flow

    Ge0rG, larma wrote about "protocol changes". we obviously don't bump for every protocol change

  533. larma

    The problem is that we fail to move XEPs to Draft fast enough so that everybody started considering Experimental or even Deferred XEPs as if they were Draft

  534. Zash

    larma, isn't that the root problem? Experimental deployed in the wild?

  535. Zash

    LC all the XEPs!

  536. flow

    Ge0rG, then the compliance suite refers to the current state of the xep

  537. Ge0rG

    flow: so you say the CS defines a moving target?

  538. Zash

    Should the compliance suite even be allowed to reference Experimental XEPs outside the "future stuff" section?

  539. flow

    Zash, or, maybe even better, make XEPs IETF style immutable

  540. Ge0rG

    Zash: should we have a process in place that moves Experimental XEPs forward when they are needed?

  541. Zash

    flow, I kinda like that, but not enough to rewrite XEP-0001 for it

  542. flow

    Ge0rG, XEPs are, to some degree, always a moving target

  543. larma

    Ge0rG, IMO CS shouldn't be able to point to Experimental XEPs so that it cannot point to a moving target

  544. larma

    *highly moving target

  545. flow

    And I don't see the point in pinning XEPs to particular namespace in the compliance suites

  546. Ge0rG

    larma: that would stall XEP progress even more

  547. flow

    What Ge0rG said

  548. larma


  549. emus has left

  550. flow

    I have the feeling because XEPs have a hard time transitioning from 'experimental' to 'draft'

  551. Ge0rG

    larma: developers have hardly the time to implement one version of the most relevant XEPs. How are they supposed to implement multiple versions?

  552. larma

    Why should they be required to implement multiple versions just because we move experimental to draft?

  553. Ge0rG

    Can we please focus on realistic ideas, given the overall xsf time budget?

  554. kokonoe has joined

  555. Zash

    Plz no

  556. flow

    Ge0rG, I too, fail to see where the "multiple versions" now comes from

  557. Zash

    flow, ns bump transitions?

  558. flow

    Zash, yes, but why do developers have to implement multiple namespaces if the compliance suites are not allowed to point to experimental XEPs?

  559. Ge0rG

    If we have one version in the CS and then the XEP is bumped, nobody will implement the new one.

  560. Ge0rG

    Speaking of time budget, I'm out.

  561. adiaholic has left

  562. Chobbes has left

  563. adiaholic has joined

  564. Chobbes has joined

  565. larma

    Ge0rG, You mean if there is one version in CS and there is a new Experimental XEP replacing it, it's not going to be widely implemented? Yes that's the whole idea of Experimental XEPs. As soon as it becomes Draft, the (next) CS can point to the new version. No need to implement two versions at the same time.

  566. Chobbes has left

  567. Ge0rG

    larma: and then next year everybody already has implemented the changes, disables the old version and enables the new one at midnight, January 1st?😉

  568. Zash

    Flag days?

  569. larma

    Ge0rG, well transitions are certainly a problem when breaking backwards compatibility, but that isn't any difference to the current situation. I do agree we should try to not namespace bump as long as possible, a new XEP doesn't imply a new namespace as it can also build on top of an existing XEP.

  570. dwd has left

  571. dwd has joined

  572. Ge0rG

    larma: just because you call it "new XEP" it doesn't automatically give people the time to implement it and maintain it aside to the old one

  573. Ge0rG

    Reality is, some developers will keep multiple versions in parallel, sometimes in different modules with different feature sets. Other will just bump in the least uncomfortable version release

  574. Ge0rG

    That would break CS compatibility with pinned namespaces

  575. larma

    I don't see the point you want to make here

  576. pep.

    “Zash> isn't that the root problem? Experimental deployed in the wild?” not put like this but yes. The problem is that we live stuff lingering as experimental. So yes, LC more things

  577. Ge0rG

    People wouldn't adopt new versions, meaning that the CS won't be updated in a meaningful way

  578. pep.

    “Zash> I kinda like that, but not enough to rewrite XEP-0001 for it“, what's wrong about rewriting 0001?

  579. Zash

    pep., thanks for volonteering

  580. pep.

    People are afraid of change and that's the one thing I want to stop, it's quite annoying

  581. pep.

    Zash, I'm sure I'm not alone

  582. pep.

    And can we stop this "blame game", or pushing stuff onto each other game

  583. pep.

    I'm sure we can manage to do stuff collectively and not just as one person at a time

  584. pep.

    Yes we're all volonteers, so what

  585. Zash

    Welcome to volonteer based organizations.

  586. Zash

    Getting volonteers to do things is Hard.

  587. pep.

    I believe we can do better than pushing stuff onto each other because

  588. larma

    Ge0rG, The CS isn't supposed to be "This is what everyone else implements" but "This is what everyone should implement". Thus you can update the CS to the new version even without everyone implementing if you think it should be. You can also say something "you are still CS compliant this year if you implement the old standard, but next year we will probably require the new one". However I wouldn't call a client or server Advanced CS2020 compliant that only implements mam:tmp, it should probably be at least mam:1

  589. winfried has left

  590. winfried has joined

  591. mathijs has left

  592. mathijs has joined

  593. larma

    "This is what everyone should implement" -> "This is what Council suggests everyone should implement"

  594. mathijs has left

  595. mathijs has joined

  596. winfried has left

  597. winfried has joined

  598. larma

    Zash, "Getting volonteers to do things is Hard." especially if they ask to help and receive the answer "it's none of your business"

  599. larma

    (not meaning you)

  600. Zash

    Is that something someone said here?

  601. larma

    It did happen in the past yes.

  602. mathijs has left

  603. mathijs has joined

  604. Zash

    pep., FWIW, nothing wrong with rewriting XEP 0001, just not a current priority for me.

  605. pep.

    Zash, what I meant by that is, if we have to rewrite 0001, then so be it. I won't be afraid of it

  606. pep.

    I'm annoyed by the "thou shalt not change XEP-xxxx" and all the fearmongering around changing things

  607. winfried has left

  608. winfried has joined

  609. winfried has left

  610. winfried has joined

  611. pep.

    We cannot go ahead without changing things. XMPP would be dead already if it were not possible to do so. (Some still say it still is, but that's an opinion I'm happy to discard. Lots of changes happened in the previous years and change will come again)

  612. mathijs has left

  613. Ge0rG

    pep.: people even dared to change 0045

  614. Zash

    pep., just do it!

  615. Kev

    Somewhere in the previous 300 messages someone mentioned me. If it's important, drop me a mail please.

  616. mathijs has joined

  617. Shell

    XMPP honestly feels like it's been reviving - especially with omemo being supported by more things now.

  618. pep.

    I wouldn't especially name OMEMO, but ok :)

  619. Chobbes has joined

  620. pep.

    That definitely played in the acceptance by users

  621. Shell

    it's what got my circle using it instead of things like Signal, at least - encrypted group chats combined with being able to pick a client according to individual preferences is a big deal.

  622. winfried has left

  623. winfried has joined

  624. pep.

    I'd like to avoid security discussions right now when we're talking about process

  625. Shell


  626. pep.

    (Not that I want to prevent you from talking about this, just that this topic is a minefield, and we're already discussing another)

  627. winfried has left

  628. winfried has joined

  629. pep.

    well, we were..

  630. mukt2 has joined

  631. Zash

    pep., so, where's your board|council application? 🙂

  632. pep.

    I'm procrastinating it. Give me a sec..

  633. mathijs has left

  634. mukt2 has left

  635. adiaholic has left

  636. adiaholic has joined

  637. marc_ has left

  638. marc_ has joined

  639. mathijs has joined

  640. xalek has joined

  641. debacle has joined

  642. waqas has left

  643. waqas has joined

  644. waqas has left

  645. waqas has joined

  646. waqas has left

  647. DebXWoody has joined

  648. mukt2 has joined

  649. winfried has left

  650. winfried has joined

  651. Douglas Terabyte has joined

  652. dwd has left

  653. dwd has joined

  654. winfried has left

  655. winfried has joined

  656. mukt2 has left

  657. winfried has left

  658. winfried has joined

  659. kokonoe has left

  660. kokonoe has joined

  661. mathijs has left

  662. mathijs has joined

  663. dwd has left

  664. matlag has left

  665. matlag has joined

  666. lskdjf has left

  667. lskdjf has joined

  668. winfried has left

  669. winfried has joined

  670. jubalh has left

  671. Chobbes has left

  672. Chobbes has joined

  673. Chobbes has left

  674. Zash

    Wait really? XEP-0081: Jabber MIME Type https://xmpp.org/extensions/xep-0081.xml

  675. Zash

    And https://tools.ietf.org/html/rfc3923#section-10

  676. Zash

    I was looking for this very thing the other day

  677. kokonoe has left

  678. Zash

    haha what

  679. Zash


  680. kokonoe has joined

  681. UṣL has left

  682. kokonoe has left

  683. kokonoe has joined

  684. winfried has left

  685. winfried has joined

  686. mukt2 has joined

  687. pdurbin has joined

  688. mukt2 has left

  689. marc_ has left

  690. pdurbin has left

  691. Ge0rG

    This is shameful

  692. jonas’


  693. jonas’

    there is the precedent I needed!!

  694. flow

    hmm the prefix in xep104 seems unnecessary

  695. flow

    just like the UTF-8 requirement in rfc3923 § 10

  696. flow

    but: yeah, using prefixes /o/ \o\ /o/

  697. Zash

    Oh no

  698. flow

    although I'd rather use them only when there is no alternative

  699. jonas’

    they can be used to reduce traffic, but (in most cases) not in an RFC-compliant way.

  700. flow

    RFC-compliant way?

  701. zach has left

  702. zach has joined

  703. Zash

    RFC says something about avoiding prefixes?

  704. Zash

    https://xmpp.org/rfcs/rfc6120.html#streams-ns-declarations sounds like a relevant heading

  705. Zash

    > It is conventional in the XMPP community for implementations to not generate namespace prefixes for elements that are qualified by extended namespaces https://xmpp.org/rfcs/rfc6120.html#stanzas-extended

  706. Zash

    jonas’: so, we-dont-do-that-here.jpg

  707. Zash

    > Routing entities (typically servers) SHOULD try to maintain prefixes when serializing XML stanzas for processing, but receiving entities MUST NOT depend on the prefix strings to have any particular value E.g. Prosody will likely spit out such things as ns1:foo, ns2:bar etc

  708. flow

    Zash, does any of this talk about attributes?

  709. Zash

    Not directly from what I can see

  710. Zash

    Why wouldn't that be the same as for elements?

  711. emus has joined

  712. dwd has joined

  713. DebXWoody has left

  714. Chobbes has joined

  715. Shell has left

  716. winfried has left

  717. winfried has joined

  718. winfried has left

  719. winfried has joined

  720. Daniel has left

  721. Daniel has joined

  722. Daniel has left

  723. Daniel has joined

  724. dwd has left

  725. andrey.g has left

  726. Daniel has left

  727. Daniel has joined

  728. remko has left

  729. mukt2 has joined

  730. lovetox has left

  731. pdurbin has joined

  732. andrey.g has joined

  733. mukt2 has left

  734. pep.

    here we go

  735. pep.

    Link Mauve, your application.

  736. pdurbin has left

  737. Tobias has left

  738. rion has left

  739. rion has joined

  740. LNJ has left

  741. remko has joined

  742. Shell has joined

  743. remko has left

  744. adiaholic has left

  745. adiaholic has joined

  746. emus has left

  747. goffi has left

  748. xalek has left

  749. jubalh has joined

  750. Chobbes has left

  751. Chobbes has joined

  752. Chobbes has left

  753. Chobbes has joined

  754. remko has joined

  755. Chobbes has left

  756. Chobbes has joined

  757. karoshi has left

  758. jubalh has left

  759. mukt2 has joined

  760. Daniel has left

  761. pdurbin has joined

  762. waqas has joined

  763. remko has left

  764. mukt2 has left

  765. pdurbin has left