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


  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


  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


  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


  232. Zash

    Encrypted Message Eeeeeh, what was it?

  233. Ge0rG


  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.


  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


  431. sex realamater has joined

  432. sex realamater


  433. sex realamater

    ralphm Alex Alex Alex Alex Alex Alex Alex

  434. sex realamater


  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