XSF Discussion - 2020-04-21

  1. emus has left

  2. moparisthebest has left

  3. karoshi has left

  4. murabito has left

  5. murabito has joined

  6. larma has left

  7. larma has joined

  8. arc has left

  9. arc has joined

  10. arc has left

  11. arc has joined

  12. pdurbin has joined

  13. Shell has left

  14. Shell has joined

  15. stpeter has joined

  16. stpeter has left

  17. pdurbin has left

  18. lskdjf has left

  19. alexis has joined

  20. Wojtek has left

  21. arc has left

  22. arc has joined

  23. aj has joined

  24. stpeter has joined

  25. stpeter has left

  26. bear has left

  27. Shell has left

  28. Shell has joined

  29. aj has left

  30. stpeter has joined

  31. stpeter has left

  32. bear has joined

  33. adiaholic_ has joined

  34. adiaholic_ has left

  35. adiaholic_ has joined

  36. bear has left

  37. pdurbin has joined

  38. arc has left

  39. arc has joined

  40. stpeter has joined

  41. stpeter has left

  42. arc has left

  43. arc has joined

  44. alexis has left

  45. alexis has joined

  46. krauq has left

  47. krauq has joined

  48. bear has joined

  49. arc has left

  50. arc has joined

  51. stpeter has joined

  52. stpeter has left

  53. bear has left

  54. DebXWoody has joined

  55. stpeter has joined

  56. stpeter has left

  57. bear has joined

  58. Shell has left

  59. Shell has joined

  60. Tobias has joined

  61. bear has left

  62. stpeter has joined

  63. stpeter has left

  64. aj has joined

  65. moparisthebest has joined

  66. aj has left

  67. Daniel has left

  68. Daniel has joined

  69. alexis has left

  70. alexis has joined

  71. stpeter has joined

  72. stpeter has left

  73. bear has joined

  74. arc has left

  75. arc has joined

  76. debacle has joined

  77. lorddavidiii has joined

  78. moparisthebest has left

  79. moparisthebest has joined

  80. paul has joined

  81. waqas has left

  82. paul has left

  83. paul has joined

  84. wurstsalat has joined

  85. Tobias has left

  86. Tobias has joined

  87. nik3sh has joined

  88. Mikaela has joined

  89. stpeter has joined

  90. stpeter has left

  91. arc has left

  92. arc has joined

  93. arc has left

  94. arc has joined

  95. nik3sh has left

  96. andy has left

  97. andy has joined

  98. arc has left

  99. arc has joined

  100. stpeter has joined

  101. stpeter has left

  102. eta has left

  103. eta has joined

  104. krauq has left

  105. alexis has left

  106. krauq has joined

  107. Jeybe has joined

  108. alexis has joined

  109. Jeybe has left

  110. Jeybe has joined

  111. Maranda has left

  112. adiaholic_ has left

  113. Jeybe has left

  114. Jeybe has joined

  115. Jeybe has left

  116. Jeybe has joined

  117. Nekit has joined

  118. stpeter has joined

  119. stpeter has left

  120. mukt2 has joined

  121. Jeybe has left

  122. Jeybe has joined

  123. Jeybe has left

  124. Jeybe has joined

  125. Maranda has joined

  126. Jeybe has left

  127. Daniel has left

  128. Daniel has joined

  129. adiaholic_ has joined

  130. karoshi has joined

  131. Neustradamus has joined

  132. Yagiza has joined

  133. arc has left

  134. arc has joined

  135. flow

    pep.> I find the current experimental XEP updating flow a bit weird. Yep, it is not ideal that some big changes to experimental XEPs get merged without asking for feedback first

  136. arc has left

  137. arc has joined

  138. jonas’


  139. jonas’

    experimental XEPs shouldn’t be deployed either way :>

  140. flow

    doesn't matter, gathering feedback prior merge is still sensible as it potentially improves the XEP while avoiding frequent namespace bumps

  141. jonas’

    versions are cheap if nothing is deployed :)

  142. flow

    no they are not

  143. Neustradamus

    There is a problem to with inbox folder, there are not redirection to official XEPs...

  144. jonas’

    Neustradamus, Thanks! Now make a PR to fix it.

  145. flow

    I also question the sentiment that experimental XEPs shouldn't get deployed, at least for certain definitions of deployed. you obviously want to have them deployed in experimental setups

  146. jubalh has joined

  147. Neustradamus

    It is not up-to-date but I have listed here: https://github.com/xsf/xmpp.org/issues/421

  148. xecks has joined

  149. stpeter has joined

  150. stpeter has left

  151. contrapunctus has joined

  152. jonas’

    Neustradamus, that’s an issue, not a PR.

  153. arc has left

  154. Neustradamus

    jonas’: I have said, I have listed ;)

  155. jonas’

    and I said we need a PR to fix it

  156. jonas’

    not an issue

  157. jonas’

    issues are worthless if there’s no one working on it.

  158. jubalh has left

  159. contrapunctus has left

  160. contrapunctus has joined

  161. contrapunctus has left

  162. sonny has left

  163. contrapunctus has joined

  164. stpeter has joined

  165. stpeter has left

  166. j.r has left

  167. nyco has left

  168. nyco has joined

  169. govanify has left

  170. robertooo has joined

  171. j.r has joined

  172. rion has left

  173. emus has joined

  174. j.r has left

  175. j.r has joined

  176. eevvoor has joined

  177. rion has joined

  178. Max has left

  179. Max has joined

  180. goffi has joined

  181. goffi has left

  182. stpeter has joined

  183. stpeter has left

  184. goffi has joined

  185. Steve Kille has left

  186. Kev has left

  187. Steve Kille has joined

  188. Kev has joined

  189. LNJ has left

  190. sonny has joined

  191. kevin has joined

  192. Daniel has left

  193. Daniel has joined

  194. stpeter has joined

  195. stpeter has left

  196. Max has left

  197. Max has joined

  198. eevvoor has left

  199. eevvoor has joined

  200. eevvoor has left

  201. jubalh has joined

  202. goffi has left

  203. goffi has joined

  204. kevin has left

  205. stpeter has joined

  206. stpeter has left

  207. jubalh has left

  208. eevvoor has joined

  209. alexis has left

  210. alexis has joined

  211. lovetox has left

  212. stpeter has joined

  213. stpeter has left

  214. pep.

    flow: I wasn't talking about namespace bumps, even though I disagree about jonas’' “nothing gets deployed”, it's really all just a waste of time for editors not to leave a short period of time here for authors to hear/incorporate feedback :(

  215. mukt2 has left

  216. marc

    MattJ: are you interested in the 401 discussion?

  217. Zash

    https://xmpp.org/extensions/xep-0191.html#example-9 This error you should get when you send a stanza to a JID you yourself have blocked, it should have an error/@by attribute of the account, right?

  218. flow

    pep., I know that you didn't talk about namespace bump, I just mentioned it as consequence of this. To be fair, even if editors would keep PRs open for longer period of time to gather feedback, your process does not make it easy to review the proposed changes

  219. flow

    Zash, I think there is no reason it couldn't have the 'by' attribute. I haven't read the spec if it is required thoguh

  220. flow

    Zash, I think there is no reason it couldn't have the 'by' attribute. I haven't read the spec if it is required though

  221. pep.

    flow: agreed about the reviews

  222. flow

    pep., \o/ ;)

  223. lskdjf has joined

  224. lskdjf has left

  225. krauq has left

  226. lovetox has joined

  227. lskdjf has joined

  228. krauq has joined

  229. MattJ

    marc [11:21]: > MattJ: are you interested in the 401 discussion? For sure!

  230. pep.

    if that's a public discussion I'll definitely read it :)

  231. eta

    can you use chat markers in MUC?

  232. eta

    I tried and the clients I'm using don't seem to care about the markers

  233. marc

    MattJ: didn't you get the invitation?

  234. MattJ

    Maybe, MUC invitation?

  235. Zash

    I tried sending you one too

  236. MattJ

    Not sure if yaxim supports them

  237. MattJ

    Or maybe my firewall rules

  238. Zash

    Ge0rG, fix it

  239. pep.

    eta: I think it's done in some conditions. I merged MattJ 's PR re 0333 in MUC. waiting for iteam to pull the updates

  240. marc

    MattJ: I tried to reinvite you :-/

  241. eta

    pep., oh right, apparently you might need to include the 'id' field in the <displayed/> element

  242. eta

    that's odd

  243. eta

    oh wait, nvm, you always do that

  244. eta

    pep., is there a link to that PR?

  245. pep.

    eta, https://xmpp.org/extensions/xep-0333.html#appendix-revs it's live now :)

  246. pep.

    https://github.com/xsf/xeps/pull/927 PR

  247. eta

    pep., oh, you need unique and stable stanza IDs

  248. Ge0rG

    Zash: fix what? MattJ's broken default firewall?

  249. Ge0rG

    I'm pretty sure I reviewed the rules and highlighted that they break MUC invitation an eternity ago

  250. mukt2 has joined

  251. goffi has left

  252. goffi has joined

  253. stpeter has joined

  254. stpeter has left

  255. goffi has left

  256. goffi has joined

  257. sonny has left

  258. sonny has joined

  259. Neustradamus has left

  260. Neustradamus has joined

  261. xsf has left

  262. mukt2 has left

  263. stpeter has joined

  264. stpeter has left

  265. eevvoor has left

  266. jubalh has joined

  267. mukt2 has joined

  268. serge90 has joined

  269. serge90 has left

  270. serge90 has joined

  271. pdurbin has left

  272. serge90 has left

  273. serge90 has joined

  274. serge90 has left

  275. serge90 has joined

  276. serge90 has left

  277. serge90 has joined

  278. stpeter has joined

  279. stpeter has left

  280. Deep has joined

  281. serge90 has left

  282. serge90 has joined

  283. MattJ

    TIL `make preview` in xsf/xeps

  284. Jeybe has joined

  285. serge90 has left

  286. serge90 has joined

  287. marc has left

  288. Jeybe has left

  289. Jeybe has joined

  290. mukt2 has left

  291. serge90 has left

  292. serge90 has joined

  293. jubalh has left

  294. marc has joined

  295. serge90 has left

  296. serge90 has joined

  297. Jeybe has left

  298. Jeybe has joined

  299. werdan has joined

  300. stpeter has joined

  301. stpeter has left

  302. Jeybe has left

  303. serge90 has left

  304. serge90 has joined

  305. Jeybe has joined

  306. Jeybe has left

  307. Jeybe has joined

  308. serge90 has left

  309. serge90 has joined

  310. mukt2 has joined

  311. adiaholic_ has left

  312. adiaholic_ has joined

  313. serge90 has left

  314. serge90 has joined

  315. Blue has joined

  316. Jeybe has left

  317. Jeybe has joined

  318. jubalh has joined

  319. Jeybe has left

  320. Jeybe has joined

  321. Deep has left

  322. rion

    do we have unicode symbol for muc topic?

  323. Jeybe has left

  324. Jeybe has joined

  325. serge90 has left

  326. Ge0rG

    rion: you can sponsor one

  327. serge90 has joined

  328. Ge0rG


  329. Yagiza

    Just read latest version of XEP-0333.

  330. rion

    sponsor? no idea how.

  331. adiaholic_ has left

  332. Ge0rG

    rion: https://wiki.xmpp.org/web/Adopt-a-Character

  333. serge90 has left

  334. pep.

    I don't think that's what he asked

  335. serge90 has joined

  336. Ge0rG

    there should be a way to pay the unicode consortium to add *new* characters.

  337. adiaholic_ has joined

  338. Daniel

    I'm sure there is

  339. pep.


  340. pep.


  341. Daniel

    Little bit of both

  342. Ge0rG

    nah, they demand proof of importance or somesuch

  343. pep.

    Ge0rG, "My brand is very important!"

  344. Ge0rG


  345. goffi has left

  346. Yagiza

    It seems all the mentions about message type are removed. But section 8.1 says that "Only Messages that can be displayed in a chat SHOULD be markable".

  347. serge90 has left

  348. serge90 has joined

  349. Yagiza

    Does that mean that I should not set "type" attribute for a chat marker Message and if my client displays Normal message not in a chat but in a separate windows, I should no make Normal messages markable?

  350. bear has left

  351. bear has joined

  352. Blue

    That's actually a very sad thing about proof of importance. The wikipedia is into removing the article in russian about fediverse due to the lack of importance

  353. mukt2 has left

  354. andy has left

  355. serge90 has left

  356. stpeter has joined

  357. stpeter has left

  358. serge90 has joined

  359. Jeybe has left

  360. Jeybe has joined

  361. Neustradamus has left

  362. Neustradamus has joined

  363. serge90 has left

  364. serge90 has joined

  365. jubalh has left

  366. andy has joined

  367. Jeybe has left

  368. Jeybe has joined

  369. serge90 has left

  370. serge90 has joined

  371. Jeybe has left

  372. Jeybe has joined

  373. serge90 has left

  374. serge90 has joined

  375. Jeybe has left

  376. Jeybe has joined

  377. serge90 has left

  378. vanitasvitae has left

  379. serge90 has joined

  380. MattJ

    Yagiza, I'm not sure I understand. I made the last update to the XEP, I didn't remove anything, I only added.

  381. Yagiza

    MattJ, I know. It seems that part was removed before your last update.

  382. jubalh has joined

  383. mukt2 has joined

  384. MattJ

    Yagiza, I don't see any such changes

  385. MattJ

    It looks like it has all been typo fixes and state changes since 2013

  386. serge90 has left

  387. eevvoor has joined

  388. serge90 has joined

  389. MattJ

    Yagiza, hmm. Are you maybe confusing it with XEP-0085: Chat State Notifications?

  390. MattJ

    That one discusses types

  391. vanitasvitae has joined

  392. serge90 has left

  393. Jeybe has left

  394. serge90 has joined

  395. Jeybe has joined

  396. Max has left

  397. SamWhited has joined

  398. Max has joined

  399. SamWhited

    Quick question to get an overview of what people here think: When writing https://xmpp.org/extensions/inbox/password-storage.html I specified that SCRAM should be used because RFC 6120 mandates it anyways. However, I tend to think it would be better to start phasing it out and just using PLAIN, so maybe it's best if I don't add requirements for SCRAM-SHA-256. What do people think?

  400. Holger

    I'm all for it but am not sure you'll easily get a consensus on that 😉

  401. serge90 has left

  402. serge90 has joined

  403. jonas’

    SamWhited, I think this should be an RFC

  404. SamWhited

    The main reasons I consider PLAIN to be a better option are that it makes the password hash more agile (it's easy to update it to use a new hash, or a higher workfactor on login), it makes it so that server policy can contain password requirements like a minimum length and have a blacklist of common passwords (eg. it can reject "passw0rd", etc.)

  405. jonas’

    not a XEP

  406. Zash

    Can an Informational XEP even make such demands?

  407. jonas’

    it’s not really specific to XMPP, is it?

  408. SamWhited

    jonas’: I disagree, those are too hard for us to update regularly.

  409. Jeybe has left

  410. SamWhited

    Zash: it's just recommendations. I did feel that RFC 2119 language was important to distinguish the importance of various bits of the XEP, but at the end of the day it is informational

  411. Zash

    > start phasing [SCRAM] out and just using PLAIN Strongly disagree

  412. stpeter has joined

  413. stpeter has left

  414. Holger

    One downside is that hash recalculation is expensive so more prone to DoS.

  415. Zash

    I'd rather get rid of PLAIN and use only SCRAM

  416. andy has left

  417. SamWhited

    Zash: why? As far as I can tell PLAIN is much better in all the ways that really matter (eg. in terms of common attacks that can be prevented). The property of not sending the actual password to the server is kind of nice, but also that isn't where passwords are normally attacked

  418. SamWhited

    Holger: that's a fair point, but then again web servers always seem to manage to do it okay

  419. Zash

    So strong is my disagreement that I can't put it into words

  420. Zash

    SamWhited, you mean we should switch to OAuth?

  421. Yagiza

    MattJ, yes, maybe

  422. Ge0rG

    Sending passwords to the server requires storing them on the client though, and this is a very common stealing vector.

  423. SamWhited

    Ge0rG: also a good point, adding that to my pros/cons list

  424. Zash

    "The web does it" is not an argument that's going to work on me.

  425. Zash

    Not unless it's "bring back XHTML-IM"

  426. Ge0rG

    OTOH, you need to store _something_ on the client, and that will be usable to login to xmpp. However, it won't be usable to login into your Gmail

  427. jonas’

    but surely everyone uses separate credentials for all the things!!k

  428. Zash

    SCRAM lets you store some magic hash on the client and login with that.

  429. SamWhited

    It's not an argument for "we should do it because we need to do what the web does", it's a counterpoint that it doesn't seem to lead to DOS' in practice

  430. Zash

    Without doing the *expensive* PBKDF2 operation again

  431. Zash

    And without the server doing that either

  432. Ge0rG

    Mmmhmmm! Magic hash!

  433. Zash

    Just like 5 hash operations and some XOR magic and you're golden

  434. Zash

    Even if you set the iteration count to a larger number than I'll bother typing out

  435. serge90 has left

  436. serge90 has joined

  437. vanitasvitae has left

  438. L29Ah has joined

  439. vanitasvitae has joined

  440. SamWhited

    So rehashing may be expensive, and that's sad, but it's not a security issue so I'm not sure how much I care (unless there were literally no other common security issues to worry about). Requiring plaintext on the client is one, so I guess the question is: is that more common than not being able to set a password policy on the server or passwords being broken because SCRAm provides no agility for hashes and work factors

  441. andy has joined

  442. serge90 has left

  443. serge90 has joined

  444. SamWhited

    My guess is that the latter are much more common. In particular, letting servers define a blacklist (no "passw0rd", "aaaa", a dump downloaded from a recent <common web service> breach, etc.) is probably the biggest single way people break into accounts

  445. Zash

    This is why we need SASL2, which was supposed to provide credential upgrades and the like.

  446. SamWhited

    Yah, if we could at least get that problem solved it would be good. Not being able to set server policy seems much more dangerous than anything else though, and I think that's just not solvable with SCRAM.

  447. SamWhited

    I suppose I could mandate that clients all have a policy for disallowing common passwords and what not ("mandate" meaning "if you're following this XEPs advice, do this please", of course)

  448. SamWhited

    But that feels wrong and less likely to be widely adopted.

  449. Zash

    It's not solvable with SCRAM doesn't mean SCRAM needs to go.

  450. Zash

    It's not like you send SCRAM hashes from the client to register or change password, all that's by sending the plain text already.

  451. SamWhited

    Ahh, that's a good point that I was stupidly forgetting.

  452. SamWhited

    Okay, so maybe it's just the agility thing and promoting SASL2 is the way to go

  453. Zash

    The pains with upgrading to SCRAM-SHA-256 is more implementation issue and that you need the plain text password again

  454. Ge0rG

    Zash: did you just say PLAIN auth? :D

  455. Zash


  456. andy has left

  457. andy has joined

  458. Zash

    I mean Corporate Enterprise Mandatory Password Change Policy

  459. SamWhited

    Okay, thanks, that's what I needed to get out of this. I'm convinced for now; leaving it as is. Thanks for sanity checking me (and finding me insane)

  460. serge90 has left

  461. j.r has left

  462. SamWhited

    I should re-read SASL2. Did an experimental implementation of it when it came out, but I don't recall the details.

  463. serge90 has joined

  464. jonas’

    I still need convincing that this is a thing concerning XMPP specifically

  465. SamWhited

    Does it provide a way to force reset passwords? That seems like the most important thing to me

  466. SamWhited

    jonas’: it's not concerning XMPP specifically

  467. jonas’

    why is this a XEP then?

  468. jonas’

    an XMPP Extension Proposal document

  469. Zash

    You need some signal to say "hey, password change time", if you receive the password encoded in SASL PLAIN doesn't matter

  470. Zash

    Without letting clients fall victim to MITM

  471. SamWhited

    jonas’: because the XSF is in a position to make recommendations for the public jabber network and it's much better if people can get them in one place instead of all over the place and specific bits of it may be specific and common problems when implementing things for the Jabber network, eg. how to handle PLAIN alongside SCRAM-SHA-1 which are both mandated by RFC 6120)

  472. SamWhited

    that's not true, PLAIN isn't mandated by 6120 IIRC, but it's common to implement in Jabber alongside SCRAM-SHA-1 for compatibility with the widest range of clients, so having a recommendation for how to do that is good.

  473. SamWhited

    Another example is the PBKDF2 iteration count. Right now most people use 4096 which is rather outdated (NIST and OWASP recommend 10000). If you look around on the web you'll find a mix of recommendations for various numbers, but which one applies to the Jabber network? Is it a low security environment or a high security environment? Should I use 4096, 10k, or 100k?

  474. serge90 has left

  475. pep.

    Zash, any clues of how to use Coporate Enterprise Mandatory Password Change sasl policy without sending PLAIN? or was PLAIN assumed

  476. serge90 has joined

  477. SamWhited

    This document clarifies that, even though you're right, technically PBKDF2 iteration count isn't specific to jabber.

  478. pep.

    I know corporate setups can require password policies, but I'd prefer encouraging SCRAM also fwiw, even during account creation/password change (where it's not used atm)

  479. alexis has left

  480. pep.

    Ideally I'd use client certs, but for now we all have to deal with passwords..

  481. SamWhited

    pep. you can't mandate it during password change or you lose the ability to be agile and then when your password hashing mechanism is broken all your users get their passwords stolen. This is *much* worse than the server getting your password once in a blue moon.

  482. pep.

    once and for all you mean

  483. pep.

    Not entirely sure what you mean by not being able to mandate it during password change

  484. SamWhited

    You can't mandate using SCRAM or something during password change, like you were suggesting, I mean.

  485. pep.

    Ah otherwise I can't rehash myself

  486. alexis has joined

  487. SamWhited

    Hash and work factor agility is the most important thing, in my mind. Right now we don't have that and it's a major problem.

  488. SamWhited

    However, if SASL2 provides a way to say "you have to reset your password" or "you need to rehash with this iteration count and HMAC hash" that solves the problem nicely in my mind.

  489. serge90 has left

  490. pep.

    But via requiring another channel I can clear the hash/password altogether and for a reset via that other channel

  491. serge90 has joined

  492. SamWhited

    pep.: didn't understand that bit about another channel, sorry?

  493. pep.

    email etc.

  494. Zash

    If SASL2 lets you say "reset your password please" *after* you authed, then it's better than forcing PLAIN auth.

  495. alexis has left

  496. SamWhited

    Zash: right, definitely after auth :)

  497. pep.

    But yeah I would prefer what Zash just said

  498. Zash

    Then you can use SCRAM mutual auth magic to be sure you're giving the new password to someone who knew your previous password

  499. Kev

    *once* knew, I think.

  500. j.r has joined

  501. SamWhited

    Anyways, got what I needed. Ping me via PM or email or something if you have more suggestions for the best practices doc. Thanks again!

  502. pep.

    SamWhited, questions on IBR2

  503. SamWhited

    pep. good timing, I was just about to /part. What do you need?

  504. stpeter has joined

  505. stpeter has left

  506. pep.

    You specify a way to do the register procedure via <iq>, does that mean I can register an account after bind? Or is it specifically for components?

  507. serge90 has left

  508. serge90 has joined

  509. SamWhited

    pep. yah, that all needs to be flushed out a bit more. The idea was to make it compatible with components, but sure, if you're an admin and want to register some accounts for somebody it could be used to make that possible after bind

  510. SamWhited

    We'd probably want to add a discovery mechanism for that though so that servers could decide whether to implement it or not. And it should probably be ad-hoc based instead, but I'm not sure if that should all go in this XEP or a separate one.

  511. pep.


  512. SamWhited

    Bye for real now; thanks again for the discussion on PLAIN v SCRAM!

  513. SamWhited has left

  514. serge90 has left

  515. serge90 has joined

  516. andy has left

  517. serge90 has left

  518. jonas’ has left

  519. serge90 has joined

  520. jonas’ has joined

  521. andy has joined

  522. alexis has joined

  523. serge90 has left

  524. serge90 has joined

  525. werdan has left

  526. serge90 has left

  527. serge90 has joined

  528. Shell has left

  529. andy has left

  530. Max has left

  531. Max has joined

  532. serge90 has left

  533. serge90 has joined

  534. andy has joined

  535. serge90 has left

  536. serge90 has joined

  537. andrey.g has left

  538. serge90 has left

  539. goffi has joined

  540. serge90 has joined

  541. bear has left

  542. serge90 has left

  543. serge90 has joined

  544. Jeybe has joined

  545. serge90 has left

  546. serge90 has joined

  547. serge90 has left

  548. serge90 has joined

  549. Neustradamus has left

  550. Neustradamus has joined

  551. serge90 has left

  552. serge90 has joined

  553. Nekit has left

  554. serge90 has left

  555. serge90 has joined

  556. mukt2 has left

  557. eevvoor has left

  558. adiaholic_ has left

  559. adiaholic_ has joined

  560. murabito has left

  561. pdurbin has joined

  562. serge90 has left

  563. serge90 has joined

  564. lovetox has left

  565. mukt2 has joined

  566. adiaholic_ has left

  567. adiaholic_ has joined

  568. pep.

    Is there a way to maybe break the fork relation between linkmauve/memberbot and xsf/memberbot?

  569. pep.

    So I get suggested by default to PR against xsf/memberbot

  570. serge90 has left

  571. pep.

    And github is sloooooow

  572. serge90 has joined

  573. pep.

    "We are investigating degradations to GitHub.com."

  574. jonas’


  575. lovetox has joined

  576. pdurbin has left

  577. bear has joined

  578. serge90 has left

  579. serge90 has joined

  580. Wojtek has joined

  581. serge90 has left

  582. serge90 has joined

  583. murabito has joined

  584. serge90 has left

  585. serge90 has joined

  586. werdan has joined

  587. Mikaela has left

  588. Mikaela has joined

  589. lovetox has left

  590. lovetox has joined

  591. serge90 has left

  592. serge90 has joined

  593. bear has left

  594. adiaholic_ has left

  595. adiaholic_ has joined

  596. serge90 has left

  597. serge90 has joined

  598. Maranda

    degradations lol

  599. pep.

    It's dead Jim

  600. andrey.g has joined

  601. lovetox has left

  602. serge90 has left

  603. adiaholic_ has left

  604. adiaholic_ has joined

  605. serge90 has joined

  606. serge90 has left

  607. serge90 has joined

  608. Maranda

    It's some evil M$ plot, I bet 😂

  609. lorddavidiii has left

  610. lovetox has joined

  611. lorddavidiii has joined

  612. serge90 has left

  613. serge90 has joined

  614. debacle has left

  615. debacle has joined

  616. lovetox has left

  617. serge90 has left

  618. serge90 has joined

  619. Max has left

  620. Max has joined

  621. serge90 has left

  622. serge90 has joined

  623. Mikaela has left

  624. debacle has left

  625. Guus


  626. Mikaela has joined

  627. Max has left

  628. Max has joined

  629. !XSF_Martin

    Why GIF?

  630. Max has left

  631. Max has joined

  632. Max has left

  633. serge90 has left

  634. Max has joined

  635. Jeybe has left

  636. serge90 has joined

  637. Jeybe has joined

  638. jonas’

    because efficient 8-bit palette encoding?

  639. adiaholic_ has left

  640. adiaholic_ has joined

  641. flow

    pep., you can ask github to change the primary repo

  642. flow

    i've done that in the past

  643. flow

    simply write them a mail

  644. pep.

    you can do that with a simple click in gitlab :/

  645. serge90 has left

  646. lovetox has joined

  647. serge90 has joined

  648. pep.

    Also I'm no owner of that repo so maybe they will just tell me off

  649. pep.

    MattJ, ^ (?)

  650. bear has joined

  651. jonas’

    I don’t seem to wield power on that repo either.

  652. serge90 has left

  653. serge90 has joined

  654. Vaulor has left

  655. Seve has left

  656. lovetox has left

  657. jubalh has left

  658. serge90 has left

  659. serge90 has joined

  660. Seve has joined

  661. Vaulor has joined

  662. serge90 has left

  663. serge90 has joined

  664. serge90 has left

  665. serge90 has joined

  666. Shell has joined

  667. serge90 has left

  668. serge90 has joined

  669. serge90 has left

  670. serge90 has joined

  671. Ge0rG

    !XSF_Martin [18:51]: > Why GIF? The patent has expired. GIF is free now!

  672. Yagiza has left

  673. serge90 has left

  674. serge90 has joined

  675. Mikaela has left

  676. Mikaela has joined

  677. !XSF_Martin has left

  678. !XSF_Martin has joined

  679. !XSF_Martin has left

  680. !XSF_Martin has joined

  681. serge90 has left

  682. serge90 has joined

  683. pdurbin has joined

  684. govanify has joined

  685. serge90 has left

  686. serge90 has joined

  687. pdurbin has left

  688. serge90 has left

  689. serge90 has joined

  690. serge90 has left

  691. serge90 has joined

  692. serge90 has left

  693. serge90 has joined

  694. debacle has joined

  695. alexis has left

  696. serge90 has left

  697. serge90 has joined

  698. lovetox has joined

  699. serge90 has left

  700. serge90 has joined

  701. Shell has left

  702. Shell has joined

  703. serge90 has left

  704. serge90 has joined

  705. LNJ has joined

  706. Maranda has left

  707. Maranda has joined

  708. Shell has left

  709. xecks has left

  710. jubalh has joined

  711. serge90 has left

  712. serge90 has joined

  713. Shell has joined

  714. Shell has left

  715. xecks has joined

  716. lovetox has left

  717. serge90 has left

  718. serge90 has joined

  719. werdan has left

  720. serge90 has left

  721. serge90 has joined

  722. Daniel has left

  723. Daniel has joined

  724. Jeybe has left

  725. Jeybe has joined

  726. Daniel has left

  727. Daniel has joined

  728. Daniel has left

  729. Daniel has joined

  730. serge90 has left

  731. Max has left

  732. serge90 has joined

  733. Max has joined

  734. jubalh has left

  735. serge90 has left

  736. serge90 has joined

  737. werdan has joined

  738. serge90 has left

  739. serge90 has joined

  740. serge90 has left

  741. serge90 has joined

  742. eevvoor has joined

  743. serge90 has left

  744. serge90 has joined

  745. Mikaela has left

  746. MattJ

    I've sent Github a request

  747. pep.

    Thanks! :)

  748. serge90 has left

  749. serge90 has joined

  750. stpeter has joined

  751. stpeter has left

  752. mukt2 has left

  753. pep.

    These should be easy changes: https://github.com/xsf/memberbot/pull/2 https://github.com/xsf/memberbot/pull/3

  754. serge90 has left

  755. serge90 has joined

  756. yo has joined

  757. mukt2 has joined

  758. yo has left

  759. serge90 has left

  760. serge90 has joined

  761. pdurbin has joined

  762. serge90 has left

  763. serge90 has joined

  764. werdan has left

  765. serge90 has left

  766. serge90 has joined

  767. jubalh has joined

  768. lovetox has joined

  769. adiaholic_ has left

  770. adiaholic_ has joined

  771. Daniel has left

  772. Daniel has joined

  773. serge90 has left

  774. serge90 has joined

  775. pdurbin has left

  776. Shell has joined

  777. serge90 has left

  778. serge90 has joined

  779. mukt2 has left

  780. mukt2 has joined

  781. Daniel has left

  782. Daniel has joined

  783. Nekit has joined

  784. mukt2 has left

  785. Shell has left

  786. Shell has joined

  787. mukt2 has joined

  788. DebXWoody has left

  789. serge90 has left

  790. serge90 has joined

  791. adiaholic_ has left

  792. adiaholic_ has joined

  793. Daniel has left

  794. Daniel has joined

  795. serge90 has left

  796. serge90 has joined

  797. jubalh has left

  798. Daniel has left

  799. Daniel has joined

  800. robertooo has left

  801. serge90 has left

  802. Daniel has left

  803. Daniel has joined

  804. serge90 has joined

  805. Daniel has left

  806. Daniel has joined

  807. MattJ

    That email came out longer than I planned

  808. Syndace

    Awesome, thanks!&

  809. Shell has left

  810. Shell has joined

  811. serge90 has left

  812. Syndace

    I'm a little surprised that you don't see a difference between responses and actions, maybe I'm still missing something important. I think the two use-cases of memberbot and and mercurial (:D) bot are already an example of why these two are separate, aren't they? One of them you only want for the last message, the other you want for all (or more) messages. One of them you want with backward compatibility using only plaintext, the other one you want with unique ids so that multiple messages are flexibly possible.

  813. serge90 has joined

  814. Daniel has left

  815. Daniel has joined

  816. waqas has joined

  817. Daniel has left

  818. Daniel has joined

  819. mukt2 has left

  820. mukt2 has joined

  821. lovetox has left

  822. Daniel has left

  823. Daniel has joined

  824. Syndace

    You could merge both and then define that responses that define a body may only be available on the most recent message.

  825. lorddavidiii has left

  826. lorddavidiii has joined

  827. Syndace

    I'd imagine you'd end up with a set of rules that depend on the body to be there or not, essentially splitting the merged element based on that. But that might just be wrong?

  828. serge90 has left

  829. serge90 has joined

  830. serge90 has left

  831. serge90 has joined

  832. serge90 has left

  833. serge90 has joined

  834. Daniel has left

  835. Daniel has joined

  836. Jeybe has left

  837. Jeybe has joined

  838. Daniel has left

  839. Daniel has joined

  840. Daniel has left

  841. Daniel has joined

  842. serge90 has left

  843. serge90 has joined

  844. serge90 has left

  845. eta has left

  846. eta has joined

  847. serge90 has joined

  848. serge90 has left

  849. MattJ

    I don't think I necessarily agree that actions can't have a body

  850. MattJ

    "!merge 245" seems like a good example

  851. serge90 has joined

  852. emus has left

  853. alexis has joined

  854. pep.

    "merge !245" :p

  855. Zash

    !merge !245

  856. Zash


  857. pep.

    hmm I wasn't even picturing "normal" bot commands using this tbh

  858. pep.

    In general I'd also prefer bots to use ad-hoc I think

  859. Zash

    in muc?

  860. pep.

    dunno, it just rejoins my usual rants about semantics in body :P

  861. pep.

    Even though with a bot you can generally make that more obvious and slightly restricted

  862. serge90 has left

  863. serge90 has joined

  864. serge90 has left

  865. serge90 has joined

  866. MattJ

    When one of the people proposing forms or ad-hoc commands goes and implements either in one of the mobile clients in a nice way, I'll listen

  867. Zash

    Shall I dig up my Buttons implementation?

  868. Zash

    Had a working prototype hacked up in JabberCat back when I wrote the protoxep

  869. Syndace

    > "!merge 245" seems like a good example It is a good example, there is no reason to forbid this. But how to handle this cleanly. Have an "unique" flag on each <response>, if set allow selecting the response even if it's not the most recent message, if not set limit to the most recent message?

  870. Syndace

    Or actually, my argument was that a bot can totally still accept this, just that there is no button for it

  871. serge90 has left

  872. serge90 has joined

  873. Syndace

    The button would say "merge" and send an <action-selected> with the corresponding id, the bot could obviously still accept a manually written "!merge 45"

  874. MattJ

    Sure. But I see no reason to hide the button either

  875. MattJ

    And as noted there is UX weirdness if buttons just disappear

  876. Syndace

    No it wouldn't be hidden, just the button would not generate the "!merge 45" output

  877. MattJ

    Why not?

  878. Syndace

    No hard reason. It probably doesn't have to, because the mercurial bot will send a "45 merged by foo" notification as soon as you click "merge"

  879. Zash

    MattJ, question about room activity indicators: Is it supposed to only work while the client is online?

  880. MattJ


  881. MattJ

    Which is why it uses presence

  882. Zash


  883. serge90 has left

  884. serge90 has joined

  885. wurstsalat has left

  886. Syndace

    My idea was that the bot knows best when to print stuff and when not to. Thus the action buttons would not print anything, because the bot can just do so with much finer control.

  887. MattJ

    That's kinda my reasoning for giving it the decision about whether there should be a <body> in the user response

  888. pep.

    MattJ, I'm not really thinking about mobile right now :)

  889. emus has joined

  890. pep.

    definitely not my main use-case

  891. MattJ

    pep.: non-mobile is not this protocol's main use case... console users are used to typing ;)

  892. pep.

    But accepting and having this buttons xep being used does bring "concerns"

  893. pep.

    As dwd said

  894. MattJ


  895. pep.

    > So I can see that these are useful, but I'm worried they'll end up baking in a data-as-text-body construction which is less than ideal, and tricky to move away from.

  896. Nekit has left

  897. Nekit has joined

  898. Zash

    So much text

  899. MattJ

    Sorry, but that's what we have today

  900. pep.

    Yeah and I don't like that either :/

  901. serge90 has left

  902. serge90 has joined

  903. MattJ

    I know you would like to replace all text messaging with semantic XML

  904. MattJ

    But users don't care, sorry

  905. pep.

    Users don't have to know, as usual

  906. Syndace

    Take the following scenario: a bot for voting. The votes of some members count double, for whatever reason. Now the bot could decide to only print votes of these double-weighted voters, and hide all single-weighted votes to prevent spam. While a little theoretical, that would only possible if the body isn't fixed in the <response>.

  907. Tobias has left

  908. MattJ

    Sure, so it sets unique ids, no body, and echoes whatever it wants whenever it wants

  909. pep.

    (fwiw, dave's quote here is a borderline argument in favour of XHTML-IM. I note :p)

  910. Syndace

    The bot would decide what goes into the body. So why not just have the bot do the printing itself?

  911. Seve has left

  912. MattJ

    I think in most cases it will flow nicer if the response comes from the user rather than the bot. But I agree it depends on the use case

  913. eta has left

  914. eta has joined

  915. MattJ

    Feels borderline security-ish too

  916. MattJ

    Seeing Ralph write "+1" in a meeting is more reliable than seeing a not write "Ralph said +1"

  917. Syndace

    Having the bot specify text that appears to be from the user?

  918. MattJ

    Not == bot, my phone refuses to recognise the word

  919. serge90 has left

  920. Syndace

    Oh, I guess both directions can appear borderline security-ish :D

  921. serge90 has joined

  922. pep.

    I'm sure ralph would be able to correct that itself if it happened

  923. Syndace

    Clicking on "yes" and having "no" appear in the chat because the bot defined it that way is also weird

  924. MattJ

    True, that is definitely a consideration

  925. Jeybe has left

  926. Jeybe has joined

  927. MattJ

    Agreed, no UI should send a body the user isn't aware of

  928. Syndace

    okay. That's an argument for a) removing labels from (what is now) <response> b) not adding a body to (what is now) <action>

  929. MattJ

    But you have to trust the bot either way

  930. MattJ

    Otherwise it will just echo the "wrong" thing

  931. serge90 has left

  932. serge90 has joined

  933. Syndace

    yes, you'd have to clarify that then followed by kicking the bot from the MUC :P

  934. Zash

    Could recommend showing it in UI like "Merge (sends "merge #123")" or somesuch.

  935. Zash

    or something something descriptions

  936. serge90 has left

  937. serge90 has joined

  938. Jeybe has left

  939. xsf has joined

  940. Syndace

    I'd like to avoid mandating such kinds of UI details, though if you want something like that super hard I won't veto

  941. serge90 has left

  942. serge90 has joined

  943. Syndace

    I think the cleanest thing we can do is: - Have buttons for plaintext responses display exactly what they will send - Have buttons that trigger actions display what the action does

  944. Zash

    Yeah, protocol specifications should stay away from UI design, tho offering suggestions is fine.

  945. paul has left

  946. MattJ

    There is plenty of precedent for UI requirements in security considerations ("This piece of information MUST be clearly visible to the user")

  947. Zash

    I'm going to default to "that's silly"

  948. MattJ

    Syndace, makes sense I think

  949. MattJ

    But we still need to figure out visibility I think

  950. MattJ

    e.g. now if I wanted to make an in-MUC voting bot, and I wanted to make quick responses for +1/-1, I can't detect what they are in response to

  951. serge90 has left

  952. MattJ

    Those kinds of buttons would need to be hidden if the bot sent a new voting item

  953. Syndace

    I imagined that the (action) buttons would be displayed right with the message they belong to

  954. MattJ

    and then people with clients that don't do actions can't vote?

  955. MattJ

    or they have to manually type +1 now, and we aren't able to offer them quick responses on mobile

  956. Syndace

    they could only vote via +1/-1 for the newest vote then, yes

  957. Zash

    Unless! <delay/> tag something something

  958. MattJ

    Let's keep the awkward <delay/> tag out of it :)

  959. Syndace

    oh you're talking about clients that support only the quick response subset of the xep?

  960. Zash eyes `~/src/xeps/origin-timestamps.md`

  961. Syndace

    i.e. not the actions thing

  962. MattJ

    No, I'm working on the assumption that clients would implement the whole thing

  963. MattJ

    But probably not explaining myself well, tired

  964. Syndace

    Okay. Then if actions are used for +1/-1, people with supporting clients could also vote for older items. Which the bot would and should probably prevent. People with clients that don't support would have to manually type +1/-1 and have it count only to the most recent vote item

  965. MattJ

    Yeah, you're right

  966. serge90 has joined

  967. serge90 has left

  968. serge90 has joined

  969. Zash

    That's usually not how voting works tho

  970. goffi has left

  971. Syndace

    There is a third option which is not covered currently: a quick response that is not limited to the most recent messrage, but maybe until it is explicitly ended. MattJ> !vote votebot> vote started. *+1 and -1 quick responses appear for everybody* someone> +1 anotherone> -1 MattJ> !done votebot> vote done. *quick responses disappear for everybody*

  972. mukt2 has left

  973. MattJ

    I worry about adding work for clients

  974. MattJ

    But indeed, that is a possible solution

  975. Syndace

    yeah, that would probably be complicated.

  976. Zash

    `<in-reply to="xmpp:id"/>`

  977. MattJ

    (removing the merge button after merging a PR would be great)

  978. MattJ

    Going to sleep on this - good night!

  979. Syndace

    I should too, good night :)

  980. serge90 has left

  981. serge90 has joined

  982. adiaholic_ has left

  983. adiaholic_ has joined

  984. adiaholic_ has left

  985. adiaholic_ has joined

  986. xecks has left

  987. serge90 has left

  988. serge90 has joined

  989. lovetox has joined

  990. serge90 has left

  991. serge90 has joined

  992. Neustradamus has left

  993. Neustradamus has joined

  994. serge90 has left

  995. serge90 has joined

  996. andy has left

  997. serge90 has left

  998. serge90 has joined

  999. lorddavidiii has left

  1000. serge90 has left

  1001. serge90 has joined

  1002. Shell has left

  1003. Shell has joined

  1004. Shell has left

  1005. Shell has joined

  1006. j.r has left

  1007. j.r has joined

  1008. eevvoor has left

  1009. serge90 has left

  1010. serge90 has joined

  1011. serge90 has left

  1012. serge90 has joined

  1013. serge90 has left

  1014. serge90 has joined

  1015. Seve has joined

  1016. serge90 has left

  1017. serge90 has joined

  1018. j.r has left

  1019. j.r has joined

  1020. bear has left

  1021. serge90 has left

  1022. Half-Shot has left

  1023. Half-Shot has joined

  1024. serge90 has joined

  1025. emus has left

  1026. Nekit has left

  1027. mukt2 has joined

  1028. serge90 has left

  1029. serge90 has joined

  1030. bear has joined

  1031. serge90 has left

  1032. serge90 has joined

  1033. pdurbin has joined

  1034. Wojtek has left

  1035. serge90 has left

  1036. serge90 has joined

  1037. serge90 has left

  1038. serge90 has joined

  1039. adiaholic_ has left

  1040. adiaholic_ has joined