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’ why?
  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. bribery?
  340. pep. lobbying?
  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 kinda-sorta
  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 no
  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. ok
  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’ yeah
  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 https://igniterealtime.org:443/httpfileupload/c463ba66-b75a-4fe0-b500-11202e11be40/dt180322.gif
  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 !merge!!245!!!
  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 Yes
  881. MattJ Which is why it uses presence
  882. Zash Mhm
  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 "concerns"
  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