XSF Discussion - 2019-08-09

  1. jcbrand has left
  2. arc has left
  3. arc has joined
  4. Zash has left
  5. mr.fister has joined
  6. larma has left
  7. arc has left
  8. arc has joined
  9. lumi has left
  10. Lance has joined
  11. pdurbin has joined
  12. pdurbin has left
  13. Lance has left
  14. Lance has joined
  15. Lance has left
  16. pdurbin has joined
  17. david has left
  18. david has joined
  19. pep. jonas’: also who would set that critical flag?
  20. Yagiza has joined
  21. adityaborikar has left
  22. adityaborikar has joined
  23. jubalh has joined
  24. xnamed has left
  25. LNJ has joined
  26. Nekit has joined
  27. jubalh has left
  28. debacle has joined
  29. krauq has left
  30. pdurbin has left
  31. jubalh has joined
  32. adityaborikar has left
  33. sezuan has joined
  34. krauq has joined
  35. adityaborikar has joined
  36. jubalh has left
  37. lovetox has joined
  38. wurstsalat has joined
  39. sezuan has left
  40. jcbrand has joined
  41. karoshi has joined
  42. Seve ralphm: yes, as far as I remember dwd was the most on the loop regarding MLS
  43. adityaborikar has left
  44. adityaborikar has joined
  45. alameyo has left
  46. alameyo has joined
  47. alameyo has left
  48. Douglas Terabyte has joined
  49. jubalh has joined
  50. sezuan has joined
  51. Douglas Terabyte has left
  52. Steve Kille has left
  53. alameyo has joined
  54. Steve Kille has joined
  55. Douglas Terabyte has joined
  56. jubalh has left
  57. pdurbin has joined
  58. jonas’ pep., sender, and the spec would mandate it
  59. flow jonas’, I wonder what the motivation and envisioned use case behind that is?
  60. Ge0rG flow: if you encounter an element that's marked as critical, and that you don't know, you engage the airbags and make the computer explode
  61. Steve Kille has left
  62. jonas’ flow, it came up the other day, and I’m still playing with the thought. It *could* be useful for entities to (a) learn that the peer who received the message cannot deal with an extension and (b) for the recipient of such a message (generalized, could be an IQ or a presence or whatever) to show an indiciator, e.g. if it’s received in the context of a 1:1 conversation
  63. Steve Kille has joined
  64. jubalh has joined
  65. Dele (Mobile) has joined
  66. Dele (Mobile) has left
  67. pdurbin has left
  68. moparisthebest has left
  69. dele has joined
  70. dele has left
  71. dele has joined
  72. dele has left
  73. Dele (Mobile) has joined
  74. Dele (Mobile) has left
  75. Douglas Terabyte has left
  76. Douglas Terabyte has joined
  77. debacle has left
  78. ralphm What about multi-device, offline, etc. It feels a bit like the urgent flag in e-mail.
  79. Douglas Terabyte has left
  80. Douglas Terabyte has joined
  81. Zash has joined
  82. jonas’ ralphm, especially in multi-device it’s useful in replacement of feature discovery. It is kind of a "ask for forgiveness instead of permission" thing
  83. andy has joined
  84. ralphm Won't every extension be marked critical?
  85. ralphm Especially if at some point large corps world be forced to federate using XMPP.
  86. larma has joined
  87. waqas has left
  88. jubalh has left
  89. Zash Kind of a large shift to move away from ignoring what you don't understand
  90. ralphm This
  91. ralphm IMNSHO client and feature/protocol developers should include fallback behaviour in their design.
  92. lovetox whats the fallback for chatstates? :D
  93. lovetox i think its a failed approach to say everything needs a fallback
  94. Kev The fallback for chatstates is not rendering chatstates.
  95. Kev The fallback for most things is ignoring them.
  96. lovetox there are things where it makes sense, and there are things where the client just ignores it
  97. Kev In fact the majority of fallbacks are probably ignoring them.
  98. lovetox yeah if you consider ignoring a fallback, then im fine with it
  99. Kev Ignoring as a fallback has worked well for most things over the last 20 years.
  100. lovetox i agree, although im not on board for 20 years :D
  101. Kev Nor me, only 18.
  102. lovetox regarding having a body fallback for reactions, i can see both sides, but i find it unlikely that somebody uses a legacy client for very important conversations and depends on that new clients send a body fallback
  103. Daniel Seeing how very much annoying message correction is in clients that don't support it (looking at you Dino) I can only imagine that reactions with fallbackswill be much much more annoying once a popular client has support for it and people start using it
  104. Kev reacts to Daniel > Seeing how very much annoying message correction is in clients that don't support it (looking at you Dino) I can only imagine that reactions with fallbackswill be much much more annoying once a popular client has support for it and people start using it with a 👍
  105. Kev reacts to Daniel > Seeing how very much annoying message correction is in clients that don't support it (looking at you Dino) I can only imagine that reactions with fallbackswill be much much more annoying once a popular client has support for it and people start using it with a ❤
  106. Kev It's taking the piss, but it's genuinely going to be like that.
  107. Kev And assuming we take this as the new model, it'll continue long beyond when 'all' clients support reactions.
  108. Kev And, of course, you'll never be able to stop supporting old versions, or it'll start getting worse again.
  109. Kev reacts to Kev > It's taking the piss, but it's genuinely going to be like that. with a 🎇
  110. Kev reacts to Kev > It's taking the piss, but it's genuinely going to be like that. with a 🎆
  111. Mikaela has joined
  112. mimi89999 has left
  113. mimi89999 has joined
  114. debacle has joined
  115. Zash reacts to /me reacts to /me reacts to /me reacts to /me with :chutulu:
  116. Andrew Nenakhov has joined
  117. intosi has joined
  118. Andrew Nenakhov has left
  119. Mikaela has left
  120. Mikaela has joined
  121. marc_ has left
  122. intosi has left
  123. marc_ has joined
  124. marc_ has left
  125. marc_ has joined
  126. marc_ has left
  127. intosi has joined
  128. marc_ has joined
  129. marc_ has left
  130. marc_ has joined
  131. marc_ has left
  132. marc_ has joined
  133. marc_ has left
  134. marc_ has joined
  135. marc_ has left
  136. marc_ has joined
  137. marc_ has left
  138. marc_ has joined
  139. marc_ has left
  140. marc_ has joined
  141. ralphm Doesn't look too bad.
  142. marc_ has left
  143. marc_ has joined
  144. adityaborikar has left
  145. adityaborikar has joined
  146. marc_ has left
  147. marc_ has joined
  148. ralphm But another choice for reactions could be not having a fallback body. Yes, non-supporting clients wouldn't see anything. Not sure if that's bad.
  149. marc_ has left
  150. marc_ has joined
  151. marc_ has left
  152. marc_ has joined
  153. marc_ has left
  154. marc_ has joined
  155. marc_ has left
  156. marc_ has joined
  157. MattJ How much do we care about non-supporting clients?
  158. marc_ has left
  159. MattJ Even if a client wanted to not show the fallback, but otherwise not show reactions, that would be trivial to implement
  160. flow I think it is. But I also believe the whole discussion is mostly pointless as we do not have any implementation experience, is heavily dependent on the personal taste and you can't forbid clients developers to add a fallback body (even if the XEP states so)
  161. marc_ has joined
  162. flow also I think it is trivial for clients to not show fallback bodies if the XEP is designed right
  163. flow i.e. messages with fallback bodies will also have that special extension element
  164. pdurbin has joined
  165. andrey.g has left
  166. adityaborikar has left
  167. adityaborikar has joined
  168. rion has left
  169. rion has joined
  170. rion has left
  171. ralphm Indeed
  172. lovetox flow, fallback is for clients that dont get updated
  173. lovetox a client who gets updated, just ignores evey message that has the reactions namespace
  174. lovetox no need for fallback
  175. lskdjf has joined
  176. rion has joined
  177. larma a client that gets updated can also produce the fallback body on their side for incoming messages. So if you'd want to annoy pidgin users, you could have libpurple render the reactions fallback body even if there was none transmitted on the wire 😉
  178. pdurbin has left
  179. lskdjf has left
  180. lskdjf has joined
  181. lskdjf has left
  182. lskdjf has joined
  183. lskdjf has left
  184. lskdjf has joined
  185. lskdjf has left
  186. lskdjf has joined
  187. jubalh has joined
  188. lskdjf has left
  189. Neustradamus has left
  190. Neustradamus has joined
  191. remko has joined
  192. winfried has left
  193. winfried has joined
  194. andrey.g has joined
  195. jubalh has left
  196. Ge0rG > also I think it is trivial for clients to not show fallback bodies if the XEP is designed right This is the minimum I will insist on. But given that, I think that annoying legacy users is less bad than silently leave them out of the conversation.
  197. Kev I think the 'legacy users' thing is fallacious.
  198. Kev If I implement this this afternoon, everyone in here other than me is a 'legacy user', and will start getting annoyed.
  199. jubalh has joined
  200. Ge0rG Kev: yaxim is implementing the suggested quoting format for a year or so now, and emoji on their own line will be displayed in 6x size. Nobody complained about that so far.
  201. Kev And then I start developing a new extension that does similar things, so do the same, and not only is everyone else a legacy user, but there's no spec yet for them to implement. So if we believe that it would be 'annoying' to 'legacy users', that means it's annoying to current users too.
  202. Kev If we believe it's not annoying, that's a different thing (I don't currently see how it could not be annoying, but it would be a different thing).
  203. balu_der_baer has joined
  204. lskdjf has joined
  205. lskdjf has left
  206. lskdjf has joined
  207. lskdjf has left
  208. lskdjf has joined
  209. lskdjf has left
  210. lskdjf has joined
  211. lskdjf has left
  212. lskdjf has joined
  213. Ge0rG Even if we believe that it's annoying, we need to weigh between the right of legacy users to participate and the importance of reactions. That said, annoying them is probably a very good way to increase the pressure on the respective client authors.
  214. jubalh has left
  215. Zash It can easily backfire into "xmpp sucks" tho
  216. Kev Assuming that users have control over which clients they use is fine in the personal-user-on-the-Internal case (mostly), but not in many other environments, but you still might get interactions with other clients. I don't believe we can reasonably have a policy of "Inconvenience people who don't support feature X so that they upgrade".
  217. Zash Kev "This message is encrypted but your client sucks, switch or GTFO"
  218. Kev Idd.
  219. Ge0rG Kev: my humble opinion is that it's much more annoying to learn, by accident, after the fact, that you missed out on a part of the conversation.
  220. Nekit has left
  221. Kev Maybe <fallback>...</fallback> is the least bad option. It's a bootstrap problem for now, but in the future we could rely on it.
  222. Zash How is that different from body?
  223. Nekit has joined
  224. Kev It doesn't get shown in the conversation flow automatically.
  225. Ge0rG what would <fallback> be good for, then?
  226. Ge0rG For the clients that implement the XEP but decide to not show the actual reaction?
  227. Ge0rG So they can show the ugly <fallback> text element?
  228. Kev Assuming <fallback/> to be be a generic fallback mechanism, It'd allow a client to alert the user that there are parts of the content that they're missing.
  229. Kev While not flooding the log with potentially more meaningless reactions than there is message content.
  230. Zash Like EME but generic?
  231. Kev EME?
  232. Zash Encrypted Message Eeeeeh, what was it?
  233. Ge0rG Element?
  234. Zash XEP-0380: Explicit Message Encryption
  235. Kev Kinda, ish.
  236. Zash So a generic variant of this would be "this message won't make sense unless you understand feature x"
  237. Kev Or, rather, "If you don't understand this element, the meaning is X", I think.
  238. Ge0rG Would that be just a tag, or an actual text element?
  239. Kev But I could imagine a client saying "This chat contains content that Swift can't render: 5000 messages containing [An emoji reaction to a previous message]" or something, where the [] has come from the <fallback/>.
  240. Ge0rG also it can't be inside of the non-supported element, because it's not supported, so it needs to be outside, and have the ns of the non-supported element as an attribute, because a message can contain multiple fallbacks.
  241. Ge0rG It's all a PITA
  242. Zash How is saying that better than just having some fallback "foo reacted with bar" in body?
  243. Kev Zash: Because that's one message rendered in an info box somewhere outside the log, rather than 5000 messages inside the message box preventing you seeing the 1000 messages of content.
  244. Ge0rG Speaking of which. This MUC mostly contains irrelevant presence changes.
  245. Zash And can't you do this any time you see a message with unknownnamespaces?
  246. Kev Ge0rG: Yes. Imagine if your client was showing each of those to you because it didn't understand they were presence updates, it'd be insufferable.
  247. alameyo has left
  248. alameyo has joined
  249. Kev Zash: You can warn that there's content you don't understand, but not know whether it's interesting content, or what the content represents.
  250. Ge0rG Kev: my client does understand that, but fails to aggregate / hide them in a meaningful way.
  251. Kev Talk to your client author :)
  252. Ge0rG Because apparently, you can't force client authors to do useful things.
  253. Kev Swift hides updates other than joins/parts, and even those it condenses in a (hopefully) smart way.
  254. Kev And even that I'm considering dropping.
  255. Ge0rG It's something that's actually useful for admins, and for when you are writing a message to somebody who just disappeared.
  256. Kev The join/part, yes. Which is why I'm only considering dropping, rather than having actually done so :)
  257. Zash Someone who was recently active (sent messages) leaving is more interesting than some idling and then dropping out, right?
  258. Kev Depends entirely on the situation, I think.
  259. Kev (But may well be)
  260. Nekit has left
  261. Nekit has joined
  262. curen has joined
  263. pdurbin has joined
  264. winfried has left
  265. winfried has joined
  266. alameyo has left
  267. pdurbin has left
  268. adityaborikar has left
  269. adityaborikar has joined
  270. winfried has left
  271. winfried has joined
  272. jubalh has joined
  273. afrogeek has left
  274. Ge0rG Only show the leave if a message by that person is visible on screen. The next logical step is to add a presence indicator to that message.
  275. Ge0rG Which is actually something I plan to add to yaxim
  276. Ge0rG You could also add a notification bubble if you mention an occupant that's offline.
  277. adityaborikar has left
  278. Chobbes has joined
  279. alameyo has joined
  280. alameyo has left
  281. adityaborikar has joined
  282. adityaborikar has left
  283. adityaborikar has joined
  284. jubalh has left
  285. Chobbes has left
  286. Chobbes has joined
  287. kokonoe has left
  288. kokonoe has joined
  289. Chobbes has left
  290. Chobbes has joined
  291. ralphm Also want to note that MIX would handle these cases better in sense that you can choose to not subscribe or display certain streams.
  292. adityaborikar has left
  293. adityaborikar has joined
  294. Ge0rG Like the Emoji Reactions stream?
  295. ralphm I can see a use for an explicit fallback element. That said, I'm also curious about stanzas with more than one namespaced element.
  296. ralphm Ge0rG: I suppose that would be a very decent idea. However, then you'd have different handling for one-on-one chats.
  297. ralphm I meant presence and join/leave above.
  298. Alex has left
  299. Ge0rG Yeah, got that.
  300. Chobbes has left
  301. ralphm I don't think doing reactions over pubsub for one-on-one chats is a good idea. But then, having both options for MIX would suck.
  302. rion Isn't xmpp going to fully migrate to pubsub?
  303. ralphm So I'm tempted to say: don't put reactions in a separate stream. Unless we have multiple streams that are delivered with regular message stanzas, and I don't like that either.
  304. ralphm rion: going strong since 2004
  305. ralphm Eh 2002 I mean
  306. xnamed has joined
  307. ralphm rion: seriously though, something like reactions is likely considered part of a conversation. Taking it "out" by using pubsub events breaks that.
  308. Steve Kille has left
  309. ralphm Unlike, say, a stream of code commits, the tunes you are playing, or news flashes.
  310. ralphm If I'd work on Slack, for example, I'd build something that takes such streams out of the channel, and move them to the side bar.
  311. ralphm However, you could still start a thread from such notifications, e.g. causing the commit with comments to become embedded in the chat stream.
  312. eevvoor has joined
  313. ralphm Or allow the user the choice at least.
  314. alameyo has joined
  315. LNJ has left
  316. LNJ has joined
  317. pdurbin has joined
  318. moparisthebest has joined
  319. curen has left
  320. alameyo has left
  321. alameyo has joined
  322. pep. Guus, it wasn't intended. I don't think we'll migrate the logs, meh
  323. pep. I'll move to the new url
  324. alameyo has left
  325. krauq has left
  326. adityaborikar has left
  327. adityaborikar has joined
  328. pdurbin has left
  329. Steve Kille has joined
  330. LNJ has left
  331. LNJ has joined
  332. krauq has joined
  333. alameyo has joined
  334. Alex has joined
  335. sezuan has left
  336. Alex has left
  337. Alex has joined
  338. alameyo has left
  339. alameyo has joined
  340. alameyo has left
  341. Guus has left
  342. alameyo has joined
  343. Guus has joined
  344. moparisthebest has left
  345. moparisthebest has joined
  346. adityaborikar has left
  347. adityaborikar has joined
  348. winfried has left
  349. winfried has joined
  350. adityaborikar has left
  351. adityaborikar has joined
  352. pdurbin has joined
  353. Nekit has left
  354. Nekit has joined
  355. arc has left
  356. arc has joined
  357. kokonoe has left
  358. kokonoe has joined
  359. pdurbin has left
  360. neshtaxmpp has joined
  361. wojtek has joined
  362. xnamed has left
  363. xnamed has joined
  364. wojtek has left
  365. Steve Kille has left
  366. Steve Kille has joined
  367. arc has left
  368. arc has joined
  369. patrick has joined
  370. krauq has left
  371. curen has joined
  372. krauq has joined
  373. eevvoor has left
  374. eevvoor has joined
  375. pep. All URIs in 0372 references pubsub are incorrect right? They use "?node=" and not "?;node="
  376. pep. All URIs in 0372 referencing pubsub are incorrect right? They use "?node=" and not "?;node="
  377. ralphm Hmm, yes, that's wrong
  378. pep. https://github.com/xsf/xeps/pull/810 here
  379. Lance has joined
  380. pdurbin has joined
  381. Lance has left
  382. ralphm Query parameters should be separated by semicolons, too, not ampersands.
  383. curen has left
  384. pep. As in, "xmpp:fdp.shakespeare.lit?;node=fdp/submitted/stan.isode.net/accidentreport&item=ndina872be" should be "xmpp:fdp.shakespeare.lit?;node=fdp/submitted/stan.isode.net/accidentreport;item=ndina872be" ?
  385. remko has left
  386. pep. will do
  387. pdurbin has left
  388. pep. done
  389. eevvoor has left
  390. lovetox that semicolon after the ? looks weird
  391. lovetox sure this is right?
  392. Ge0rG 0372 is weird.
  393. Ge0rG my gut feeling would be that the question mark is not needed, but what do I know of URIs.
  394. Yagiza has left
  395. debacle has left
  396. kokonoe has left
  397. pdurbin has joined
  398. kokonoe has joined
  399. arc has left
  400. arc has joined
  401. pdurbin has left
  402. lumi has joined
  403. xnamed has left
  404. xnamed has joined
  405. waqas has joined
  406. murabito has left
  407. murabito has joined
  408. ralphm Yeah, your gut feeling is wrong. Without question mark, there's no query component.
  409. ralphm lovetox: the position before the first semicolon is for an action. Without action, eg. when pointing to a node (or item within), that position is empty.
  410. lovetox ah, thanks
  411. wurstsalat has left
  412. Douglas Terabyte has left
  413. wurstsalat has joined
  414. Douglas Terabyte has joined
  415. Douglas Terabyte has left
  416. Douglas Terabyte has joined
  417. Douglas Terabyte has left
  418. Nekit has left
  419. Douglas Terabyte has joined
  420. patrick has left
  421. jubalh has joined
  422. wurstsalat has left
  423. wurstsalat has joined
  424. pdurbin has joined
  425. neshtaxmpp has left
  426. jubalh has left
  427. lovetox has left
  428. pdurbin has left
  429. sex www.realamater.com has joined
  430. sex www.realamater.com www.realamater.com
  431. sex realamater has joined
  432. sex realamater https://www.realamater.com
  433. sex realamater ralphm Alex Alex Alex Alex Alex Alex Alex
  434. sex realamater Alex
  435. sex www.realamater.com has left
  436. sex realamater has left
  437. Ge0rG https://twitter.com/matrixdotorg/status/1159787827636441088 why don't we have a merch shop?
  438. j.r has joined
  439. j.r Hello, I'm currently developing a little XMPP admin helper app for Android and now I want to make a icon... I have an Idea involving the XMPP Logo but a) I'm not sure if I can modify it so that it fits in the Icon context and b) how I have to meantion that it's based on the XMPP Logo wich is as Wikipedia tells me under MIT... (My app is btwe under GPLv3)
  440. moparisthebest has left
  441. moparisthebest has joined
  442. andy has left
  443. moparisthebest has left
  444. moparisthebest has joined
  445. pep. Ge0rG, we should indeed
  446. moparisthebest has left
  447. moparisthebest has joined
  448. wurstsalat has left
  449. pep. j.r, re licensing, you'd just need to mention somewhere in your COPYING file or README that you're using the XMPP logo with license XYZ and put the license there. If it's really MIT, I don't know, you'll have to copy that specific version of the license, because the copyright line is also part of the license and that makes MIT things somewhat unique
  450. pep. Also if it's MIT then you can of course reuse/modify/etc. etc.
  451. j.r pep., ok so I just have to find the license put it into my readme and I'm good to go?
  452. pep. IANAL, but that's generally how it works :)
  453. pep. Maybe it's even in the file itself. Is it an svg you got?
  454. pep. hmm no it's not in the one from xmpp.org. Too bad
  455. pep. hmm, CI for xmpp.org is borked. There's a PR to fix it: https://github.com/xsf/xmpp.org/pull/595, is anything blocking for it?
  456. pep. If it's blocking on editor(s) not having time (which I'm not blaming him for), I'll rush my application for that. Where do I send my resume again?
  457. pep. jonas’, ^
  458. Mikaela has left
  459. jcbrand has left
  460. UsL has left
  461. UsL has joined
  462. pdurbin has joined
  463. jcbrand has joined
  464. winfried has left
  465. winfried has joined
  466. pdurbin has left
  467. neshtaxmpp has joined