XSF Discussion - 2017-03-20

  1. suzyo has left
  2. Tobias has joined
  3. Guus has left
  4. nicolas.verite has joined
  5. waqas has left
  6. waqas has joined
  7. nicolas.verite has left
  8. nicolas.verite has joined
  9. arc has left
  10. arc has joined
  11. nicolas.verite has left
  12. kaboom has left
  13. Guus has left
  14. waqas has left
  15. waqas has joined
  16. Zash has left
  17. waqas has left
  18. waqas has joined
  19. Tobias has joined
  20. Vinilox has joined
  21. waqas has left
  22. waqas has joined
  23. sonny has left
  24. nicolas.verite has joined
  25. sonny has joined
  26. uc has joined
  27. nicolas.verite has left
  28. jere has left
  29. jere has joined
  30. sonny has left
  31. sonny has joined
  32. sonny has left
  33. sonny has joined
  34. sonny has left
  35. sonny has joined
  36. jere has joined
  37. nicolas.verite has joined
  38. nicolas.verite has left
  39. sonny has joined
  40. vurpo has left
  41. vurpo has joined
  42. nicolas.verite has joined
  43. sonny has joined
  44. Guus has left
  45. sonny has joined
  46. nicolas.verite has left
  47. sonny has joined
  48. Guus has left
  49. nicolas.verite has joined
  50. nicolas.verite has left
  51. Tobias has joined
  52. suzyo has joined
  53. waqas has left
  54. Guus has left
  55. SamWhited has left
  56. nyco has joined
  57. nicolas.verite has joined
  58. daniel has left
  59. daniel has joined
  60. ralphm has left
  61. daniel has left
  62. nicolas.verite has left
  63. efrit has joined
  64. Guus has left
  65. suzyo has left
  66. daniel has joined
  67. nicolas.verite has joined
  68. daniel has left
  69. daniel has joined
  70. nicolas.verite has left
  71. Vinilox has joined
  72. blabla has left
  73. blabla has joined
  74. blabla has joined
  75. blabla has joined
  76. moparisthebest has left
  77. moparisthebest has joined
  78. tim@boese-ban.de has joined
  79. tim@boese-ban.de has joined
  80. nyco has left
  81. nicolas.verite has joined
  82. efrit has joined
  83. nicolas.verite has left
  84. nyco has joined
  85. nicolas.verite has joined
  86. kalkin has left
  87. nyco has joined
  88. winfried has left
  89. Tobias has left
  90. kalkin has joined
  91. nyco has joined
  92. Zash has left
  93. nyco has left
  94. vurpo has left
  95. vurpo has joined
  96. Guus has left
  97. Valerian has joined
  98. goffi has joined
  99. Ge0rG has left
  100. nyco has joined
  101. ralphm has left
  102. jubalh has joined
  103. jubalh has left
  104. goffi has left
  105. goffi has joined
  106. pep. has left
  107. Steve Kille has left
  108. Steve Kille has left
  109. nyco has joined
  110. Steve Kille has joined
  111. vurpo has left
  112. vurpo has joined
  113. Martin has joined
  114. nicolas.verite has left
  115. kalkin has left
  116. mhterres has joined
  117. Steve Kille has left
  118. kalkin has joined
  119. nyco has joined
  120. nicolas.verite has joined
  121. nicolas.verite has left
  122. nyco has left
  123. nicolas.verite has joined
  124. nicolas.verite has left
  125. Steve Kille has left
  126. Steve Kille has joined
  127. Alex has joined
  128. nyco has left
  129. jcbrand has joined
  130. blipp has left
  131. jcbrand has left
  132. jcbrand has joined
  133. nyco has joined
  134. jubalh has joined
  135. goffi has left
  136. goffi has joined
  137. blipp has joined
  138. goffi has left
  139. nyco has joined
  140. kaboom has joined
  141. nicolas.verite has joined
  142. blipp has left
  143. nyco has joined
  144. Tobias has joined
  145. nicolas.verite has left
  146. Yagiza has joined
  147. nyco has joined
  148. nyco has left
  149. arc has left
  150. arc has joined
  151. goffi has joined
  152. kalkin has left
  153. kalkin has joined
  154. jubalh has left
  155. Martin has left
  156. Martin has joined
  157. nicolas.verite has joined
  158. nicolas.verite has left
  159. goffi has left
  160. Tobias has joined
  161. blipp has joined
  162. nyco has joined
  163. nyco has left
  164. Martin has left
  165. Martin has joined
  166. daniel has left
  167. daniel has joined
  168. Martin has left
  169. Martin has joined
  170. goffi has joined
  171. daniel has left
  172. daniel has joined
  173. Valerian has left
  174. daniel has left
  175. daniel has joined
  176. Valerian has joined
  177. jcbrand has left
  178. nyco has joined
  179. blipp has left
  180. daniel has left
  181. daniel has joined
  182. daniel has left
  183. daniel has joined
  184. tim@boese-ban.de has left
  185. nicolas.verite has joined
  186. Yagiza has joined
  187. daniel has left
  188. daniel has joined
  189. daniel has left
  190. nicolas.verite has left
  191. daniel has joined
  192. jonasw I’m not an XML Schema guru, but we’re currently looking at the schema for XEP-0084. It appears to me that it doesn’t allow any attributes for <pointer/>, but in the text it is specified that pointer MAY have some attributes (those already specified for <info/>).
  193. moparisthebest has joined
  194. jere has joined
  195. Holger has left
  196. jcbrand has joined
  197. Valerian has left
  198. Valerian has joined
  199. Martin has left
  200. Martin has joined
  201. moparisthebest has left
  202. jubalh has joined
  203. jubalh has left
  204. moparisthebest has joined
  205. vurpo has left
  206. vurpo has joined
  207. daniel has left
  208. daniel has joined
  209. daniel has left
  210. daniel has joined
  211. vurpo has left
  212. nicolas.verite has joined
  213. nicolas.verite has left
  214. vurpo has joined
  215. daniel has left
  216. daniel has joined
  217. daniel has left
  218. daniel has joined
  219. jcbrand has left
  220. jcbrand has joined
  221. Alex has left
  222. Alex has joined
  223. jcbrand has left
  224. jcbrand has joined
  225. dwd jonasw, Our schemas are often rubbish, yes. In the case of the <pointer/>, I take it you're interested in implementing this? I don't *think* anyone else has.
  226. jonasw not really
  227. jonasw just a stub
  228. jonasw well, we’re implementing XEP-84, but not <pointer/>, to make it clear
  229. dwd I'd be inclined to strip <pointer/>, even if it's Draft, to be honest. I can't see how it's interoperable.
  230. jonasw I find it a bit annoying that one can only save image/png in PEP there
  231. jonasw I understand and welcome that image/png is required, but from my reading the XEP explicitly forbids anything but image/png in the :data node :(
  232. Zash Only when only one node is supported, like how some popular implementation(s?) do it.
  233. jonasw what do you mean?
  234. dwd Zash, No, I think the text as written restricts the <data/> element to be image/png only.
  235. Zash What
  236. jonasw yes
  237. Zash Where?
  238. dwd Zash, §4.1
  239. Zash -xep 84
  240. jonasw > The XML character data MUST represent the image data for the avatar with a content-type of "image/png", Base64-encoded in accordance with Section 4 of RFC 4648 [10]. (Note: Line feeds SHOULD NOT be added but MUST be accepted.)
  241. Bunneh Zash: XEP-0084: User Avatar (Standards Track, Draft, 2016-07-09) See: https://xmpp.org/extensions/xep-0084.html
  242. kalkin has left
  243. Zash Is that new?
  244. jonasw hopefully not. this is a MUST and the XEP has been in draft since 2008 or something :)
  245. jonasw 2007 even
  246. kalkin has joined
  247. dwd Changed in 2007, just before Last Call.
  248. dwd Version 0.12. Or at least, that's when the line was edited.
  249. Zash I thought that it said "If only one item is published, it has to be PNG. Other items can be whatever."
  250. bjc has left
  251. dwd Oh, mind you, "The XML character data MUST represent the image data for the avatar with a content-type of "image/png"", edited in 2007-02-23, which doesn't appear in the version history.
  252. bjc has joined
  253. nicolas.verite has joined
  254. nicolas.verite has left
  255. nicolas.verite has joined
  256. Zash But since in practice you are going to have a hard time publishing multiple items...
  257. nicolas.verite has left
  258. Zash The png-only text shows up in https://xmpp.org/extensions/attic/jep-0084-0.7.html#proto
  259. jonasw wait, if PEP won’t allow more than one item the XEP has a data race
  260. winfried has left
  261. Zash Wasn't there a feature for that?
  262. waqas has joined
  263. Alex has left
  264. Flow has joined
  265. Steve Kille has left
  266. nicolas.verite has joined
  267. nicolas.verite has left
  268. Steve Kille has left
  269. jonasw dwd: let’s keep <pointer/>
  270. jonasw it may be useful if we ever want to extend XEP-84.
  271. jonasw saves a replacement.
  272. nicolas.verite has joined
  273. Steve Kille has left
  274. bjc has left
  275. Steve Kille has left
  276. bjc has joined
  277. Tobias fippo, what's google meet? their new duo?
  278. Zash Yet another Google messenger?
  279. Tobias https://meet.google.com/
  280. Tobias maybe a gotomeeting like thing from google?
  281. Tobias https://techcrunch.com/2017/02/28/google-quietly-launches-meet-an-enterprise-friendly-version-of-hangouts/
  282. nyco yes, more or less
  283. nyco whereas the other is more like a Slack/HipChat
  284. Tobias they got an alternative to Slack/hipchat?
  285. Ge0rG Hey, while we are talking about Slack. If you slack a message to yourself, it's just stored on the server and reflected to your other devices. In XMPP (with Carbons), every one of your devices has two copies in the end
  286. Ge0rG Would it be sensible to change Core routing / Carbons to only deliver the message to your _other_ clients?
  287. Ge0rG or is this something that should be handled in the client?
  288. nyco Ge0rG, marginal case, as I guess? or is there real use?
  289. Tobias Ge0rG, MAM should be the source of truth, not?
  290. Ge0rG nyco: I'm messaging myself all the time (URLs to my mobile etc), and I'm using a secondary JID because duplicates look bad
  291. Ge0rG Tobias: MAM will obviously also contain two copies
  292. Ge0rG Tobias: the incoming and the outgoing one
  293. xnyhps has joined
  294. Tobias Ge0rG, yeah?
  295. nyco so why not store those things in a private pubsub node?
  296. Tobias Ge0rG, maybe there could be a mention of it in MAM to allow server to optionally remove that one duplicate
  297. Ge0rG nyco: because every client supports messaging, and no clients support private pubsub nodes.
  298. Ge0rG Tobias: that's not so easy.
  299. Ge0rG Tobias: MAM is only if you come online later on. Carbons / core 6121 is when you are online
  300. Ge0rG Which is one of the reasons I'm insisting on making MAM-subscribe a thing.
  301. intosi Ge0rG: that's what M-Link does. Messages to self are archived just once.
  302. intosi And, as a result, returned just once.
  303. Ge0rG intosi: are carbons of messages-to-self also inhibited?
  304. intosi Carbons are not archived.
  305. Ge0rG intosi: if I'm online with /A and /B, and I send a message from /A to bare-JID (or even to /A), which client will receive how many copies again?
  306. intosi And messages to self follow the normal carbons rules. Only interested clients that aren't snders or recipients already will receive them,
  307. Ge0rG intosi: because a message-to-self is two messages in most cases :>
  308. blipp has joined
  309. Ge0rG and from my reading of 6121+Carbons, you can't strip out one of them without violating the protocol
  310. Alex has joined
  311. intosi I'll probably regret asking immediately, but why?
  312. nicolas.verite has left
  313. Ge0rG intosi: an incoming message must be delivered to a subset of the available resources by 6121, and to all other resources that have carbons by 0280
  314. uc has left
  315. Ge0rG intosi: and an outgoing message must be carboned to all other carbon-enabled resources
  316. uc has joined
  317. intosi Yeah, sure. And you're claiming a server must do both sent and received handling separate?
  318. Ge0rG from a technical PoV, a message to self is first an outgoing message from your sending client, and then an incoming message to wherever it was addressed
  319. intosi I chose not to do that, it's stupid.
  320. Ge0rG intosi: actually I'll gladly accept a different reading of the RFC, but it seems like you were the only one to do the "right" thing, and I'd be surprised if it's backed by the RFC
  321. Steve Kille has left
  322. fippo tobias: video hangouts with a new interface. watch https://www.youtube.com/watch?v=8a-mmT9ifss if you're interested
  323. Tobias fippo, ta
  324. intosi It followed from my reading of 280, interpreting it as a hint on which resources should receive the message. It makes no sense at all to handle the sent and received carbons separately when from and to are the same account.
  325. intosi On which resources, apart from normal RFC routing, I mean.
  326. Ge0rG intosi: you are right of course. But even normal RFC routing is convoluted in this case.
  327. intosi Didn't touch RFC routing rules at all.
  328. Ge0rG intosi: if you don't touch RFC routing, you'll end up in an even weirder place. Imagine that RFC routing rules require you to send the message back to the sending client.
  329. Ge0rG Then the sending client will end up with two copied, and every other client with only 1.
  330. intosi Ge0rG: perhaps in your code base.
  331. Steve Kille has left
  332. Ge0rG intosi: no, RFC 6121 is very clear on this. https://tools.ietf.org/html/rfc6121#section-8.5.2 and https://tools.ietf.org/html/rfc6121#section-8.5.3
  333. Ge0rG there is no "you can ignore the sending JID of self-messages" exception
  334. Ge0rG I wish there were.
  335. nicolas.verite has joined
  336. intosi I'm probably too stupid to understand what your problem is.
  337. lovetox has joined
  338. Flow Ge0rG: So you are saying we can't add a sentence to 280 that carbons of self-messages should not be send to the sending resource?
  339. Ge0rG intosi: I want to ask my favorite server's developers to reduce the number of self-messages from 2 to 1, but RFC6121 disallows that.
  340. Ge0rG Flow: no. I'm saying that, carbons-aside, you'll end up with partial message duplication based on 6121.
  341. goffi has left
  342. Ge0rG Flow: this can't be fixed in carbons only. And if we try, we'll end up with {1..2} messages arriving at different clients
  343. nyco has left
  344. nicolas.verite has left
  345. nicolas.verite has joined
  346. nicolas.verite has left
  347. nicolas.verite has joined
  348. nicolas.verite has left
  349. nicolas.verite has joined
  350. nicolas.verite has left
  351. nicolas.verite has joined
  352. nicolas.verite has left
  353. Flow Hmm, I think I don't have the whole picture of the problem. Maybe post to standards@?
  354. Ge0rG But then again, I also think that 6121 bare-JID routing rules are fundamentally broken for the IM use case.
  355. bit has joined
  356. jonasw has left
  357. goffi has left
  358. Ge0rG Flow, lovetox, intosi: https://mail.jabber.org/pipermail/standards/2017-March/032421.html
  359. daniel has left
  360. daniel has joined
  361. sonny has joined
  362. intosi Ah, now I understand you. Yes, foo/A sending to foo will result in a copy to self.
  363. intosi See, I'm too stupid to understand your words.
  364. Ge0rG intosi: I'm too stupid to find the right words to make the problem accessible
  365. intosi What will not happen, is sent carbons to be generated, even if you send to a bound JID foo/B.
  366. Ge0rG intosi: feel free to comment that you won't violate 6121, and that my claim of such is a blatant lie
  367. intosi Like I said, I didn't touch core routing rules for carbons. Not delivering the message to self when insisting on an unbound bare self jid would violate the RFC.
  368. intosi Anyway, sensible clients bind to a full jid as soon as they can anyway.
  369. Ge0rG intosi: resource-binding only adds to the uncertainity
  370. Ge0rG sensible clients should always send to bareJID because the server knows better which resources are there.
  371. Ge0rG the only exception is OTR, which is considered generally broken.
  372. intosi I disagree, except for the OTR bit.
  373. dwd Ge0rG, "always"?
  374. Ge0rG dwd: yeah.
  375. dwd https://xmpp.org/extensions/xep-0296.html
  376. daniel has left
  377. daniel has joined
  378. jubalh has joined
  379. Ge0rG dwd: following that XEP leads right into madness land.
  380. Holger It would be so nice if that idea worked out in practice ...
  381. Ge0rG dwd: just consider the race conditions between sending a message to a locked JID and that locked JID disappearing.
  382. Ge0rG Things are getting even funnier if you change client behavior based on the locked JID's supported features.
  383. Lance has joined
  384. Ge0rG You start typing a LMC correction, but then another client of your buddy comes online, you get unlocked and your client refuses to LMC.
  385. Ge0rG ..or doesn't ask for a 0184 ack.
  386. Ge0rG And I don't even want to get started about different message routing rules, which cause a "real" message vs. a carbon to arrive at your destination.
  387. dwd You seem to have got started on the thing you claim you don't want to get started on.
  388. Ge0rG Seriously, we need to reconsider all that and just say that unless explicitly required, all messages should go to bare-JID, because we want to talk to the "account" and not to the "client".
  389. Guus has left
  390. Ge0rG dwd: no, I didn't. Carbons are a whole different can of worms.
  391. Flow Ge0rG: I believe any sensible client does already that
  392. Ge0rG Flow: does what?
  393. moparisthebest has left
  394. Ge0rG Flow: intosi> Anyway, sensible clients bind to a full jid as soon as they can anyway.
  395. Flow Ge0rG: But with carbons on both ends, where is the issue when performing resource locking?
  396. Ge0rG Flow: see above.
  397. Ge0rG Flow: also, if the receiving client goes offline, even with carbons, the server will generate error responses for the queued messages
  398. Flow fair point, but you don't have to convince me. If I where to write an XMPP IM client I would probably always send messages to bare JIDs
  399. sonny has joined
  400. Ge0rG is an ignorant developer as well. Just doesn't care about CAPS and sends whatever features he wants to the bare JID
  401. Ge0rG because most of the features supported by yaxim fail safe, and because it doesn't support many features, it works out excellently.
  402. Flow CAPS?
  403. Ge0rG Flow: 0030/0115
  404. jubalh has left
  405. sezuan has left
  406. daniel has left
  407. daniel has joined
  408. vurpo has left
  409. daniel has left
  410. vurpo has joined
  411. daniel has joined
  412. Guus has left
  413. kaboom has left
  414. jcbrand has left
  415. sonny has joined
  416. kalkin has left
  417. kalkin has joined
  418. jubalh has joined
  419. sonny has joined
  420. jubalh has left
  421. Valerian has left
  422. nicolas.verite has joined
  423. nicolas.verite has left
  424. nicolas.verite has joined
  425. nicolas.verite has left
  426. jonasw has left
  427. vurpo has left
  428. vurpo has joined
  429. daniel has left
  430. daniel has joined
  431. nicolas.verite has joined
  432. nicolas.verite has left
  433. nicolas.verite has joined
  434. nicolas.verite has left
  435. arc has left
  436. arc has joined
  437. jonasw has left
  438. daniel has left
  439. daniel has joined
  440. ralphm has left
  441. daniel has left
  442. daniel has joined
  443. daniel has left
  444. daniel has joined
  445. daniel has left
  446. daniel has joined
  447. mimi89999 has left
  448. daniel has left
  449. tim@boese-ban.de has joined
  450. daniel has joined
  451. xnyhps has left
  452. daniel has left
  453. daniel has joined
  454. nyco has joined
  455. daniel has left
  456. daniel has joined
  457. tim@boese-ban.de has joined
  458. nicolas.verite has joined
  459. lovetox so is there any use case for https://xmpp.org/extensions/xep-0201.html except the ones described in the xep, because i dont really feel i dont need the ones described in the xep
  460. jonasw lovetox: actually, those use cases are awesome. the problem is only that noone has ever found a good UI for them.
  461. lovetox they feel like "look what we could do if somebody would find some use case for this"
  462. Ge0rG I'd love to be able to collapse threads I'm not interested in. But that would require XMPP clients to actively mark messages with the correct thread-id
  463. nicolas.verite has left
  464. jonasw +1 Ge0rG
  465. jonasw haven’t had a good idea yet, unfortunately
  466. Ge0rG I'm actually thinking about adding a thread-ID in yaxim when you tap on a nickname to do nickname completion
  467. jonasw not sure that’d perform well
  468. Ge0rG jonasw: it would probably cause gazillions of false-positives, but then again: no sane client relies on thread-ids to mean anything :P
  469. lovetox you mean in a muc
  470. Ge0rG lovetox: yeah
  471. lovetox so that you tap a button and start a new thread
  472. lovetox and how does the other client respond to the thread?
  473. jonasw with tapping I can actually imagine that this would work
  474. Ge0rG lovetox: no. you tap on a message to continue that thread
  475. jcbrand has joined
  476. jonasw I cannot imagine how that works in a desktop application
  477. jonasw as soon as you have multiple threads with overlapping participants :(
  478. Ge0rG jonasw: also tab completion :P
  479. jonasw Ge0rG: see above
  480. jonasw with yaxim you could use the thread of the message which the user tapped at for completion
  481. lovetox and then reorder messages so messages from threads are grouped?
  482. jonasw maybe
  483. Ge0rG maybe one could add colors to message threads
  484. Ge0rG as a subtle hint
  485. jonasw like this? https://wiki.xmpp.org/web/Contact_Colors
  486. Ge0rG anyway, I gotta run.
  487. devnull has left
  488. Ge0rG jonasw: yeah, nickname --> text color; thread --> bg color
  489. Ge0rG severe eye injury!
  490. jonasw ouch
  491. lovetox so for muc i feel this is not too hard to implement
  492. lovetox its just the ui how you respnd
  493. lovetox or switch thread
  494. jonasw yes, the UI is hard
  495. jonasw exactly
  496. jonasw unfortunately; because I think it could add a lot of it worked magically
  497. Ge0rG that would intuitively work for pseudo-forums, but not for IM
  498. jonasw wtf
  499. lovetox there needs to be a feature, that lets me add a name to the thread
  500. jonasw the wiki dropped my non-latin1-characters
  501. jonasw what the heck
  502. daniel has left
  503. lovetox so then someone could hit a key and cycle the thread names
  504. lovetox and write to the one he wants
  505. daniel has joined
  506. Ge0rG lovetox: why names? just use <Tab> to color-highlight the threads one by one.
  507. lovetox can we just add a name tag to the thread element
  508. jcbrand has left
  509. Ge0rG Or maybe... Meta-Tab, because Tab is already used for nick completion :P
  510. lovetox on desktop i have endless possibilities with shortcuts i dont see a problem with that
  511. Valerian has joined
  512. Ge0rG lovetox: yes, but your users don't have infinite memory for shortcuts
  513. jonasw right
  514. lovetox so the client automatically gives a color to a new thread
  515. jonasw this is IM, not blender
  516. lovetox this can get tricky in a muc with much threads
  517. lovetox names are better i think
  518. jonasw names requires extra user interaction
  519. jonasw -> won’t be used
  520. Valerian has left
  521. Valerian has joined
  522. Ge0rG lovetox: MS Teams has multiple input boxes per thread level. The one in the bottom starts new threads, and then there is a box in each thread at each level, to allow answering there
  523. jonasw hm, interesting approach, too
  524. lovetox but to be honest, on a smartphone, a muc is cramped already
  525. lovetox on desktop this could be a really nice feature
  526. lovetox i mean you have space for 3 messages on a smartphone ^^
  527. Ge0rG I have enough space for five
  528. lovetox threads or not, you will not have a sense of overview in a muc on a smartphone
  529. lovetox especially not one where much goes on
  530. jonasw depends, if the threads are properly done and you view only those you are interested in…
  531. jonasw but I doubt that will work reliably, because users will accidentally post messages in the wrong thread
  532. jonasw interesting question: can LMC modify the <thread/>?
  533. Ge0rG yeah, collapsing / ignoring threads would be awesome on smartphones
  534. goffi has left
  535. Ge0rG "The Sender MUST NOT include a correction for a message with non-messaging payloads." - looks to me like it's not forbidden
  536. Ge0rG &
  537. jonasw fg
  538. daniel has left
  539. daniel has joined
  540. SamWhited has left
  541. nicolas.verite has joined
  542. nicolas.verite has left
  543. Steve Kille has left
  544. Steve Kille has left
  545. Ge0rG What? Hey!
  546. mhterres has left
  547. Steve Kille has joined
  548. nicolas.verite has joined
  549. lovetox yeah pretty nice idea for threads
  550. nicolas.verite has left
  551. lovetox but i see this more as a feature for serious work groups etc
  552. lovetox not for your everyday muc
  553. jonasw lovetox, indeed
  554. lovetox on desktop you could capture all threads put them into a list
  555. lovetox let the user name them
  556. Ge0rG If done right, it could work for both
  557. lovetox on click open a tab that displays only msgs from that thread
  558. lovetox that way i also know to which thread a user wants to respond
  559. Ge0rG But then, there will be the one client that fails, the Outlook of XMPP, the Pidgin of Carbons, where it's just plain broken
  560. lovetox i just treat it like a new conversation
  561. nicolas.verite has joined
  562. nicolas.verite has left
  563. lovetox yeah Ge0rG thats why i said its probably only for serious groups
  564. lovetox that know what they are doing
  565. Ge0rG lovetox: rule number 1 of interface design: users don't know what they are doing
  566. jonasw that
  567. SamWhited has joined
  568. Martin has left
  569. jere has left
  570. jere has joined
  571. lovetox Ge0rG, on the topic of self messaging
  572. lovetox receipts have no use in my opinion
  573. lovetox on sent message if you dont get a error stanza from the server, you can see it as delivered
  574. lovetox it doesnt matter if your other client is online and sends a received stanza..
  575. jonasw right, stream management tells you that it has been processed by the server
  576. nicolas.verite has joined
  577. lovetox i dont know when i ever would need that info
  578. lovetox i mean if you client is not totally broken you will get that message via MAM or offline message or carbons or whatever
  579. nicolas.verite has left
  580. jonasw you’d want to be sure that you can find it in MAM later
  581. jonasw for this you need to make sure that the message actually makes it to the server
  582. jonasw -> SM
  583. Ge0rG lovetox: see, some client developers can't even send a coherent message with a highlight, how are Normal Users supposed to manage threads? 😀
  584. lovetox so i think i will deactivate receipts for self messaging, its only noise
  585. Ge0rG lovetox: sounds good enough to me.
  586. lovetox chatstates dito
  587. Ge0rG Yeah, ideally 0198 will manage the thing. However, I'd still like to show green checkmarks, just maybe with a different logic to create them.
  588. jonasw Ge0rG: SM should be a sufficient source for that, no?
  589. lovetox yeah though, in most cases i dont have events for sm stanzas in my application, and its maybe not so easy to link them to messages, for example my first idea would also be just to use the "sent" carbon that i get as a receipt
  590. lovetox at least in gajim that would be way easier then to do this via sm stanzas
  591. Ge0rG lovetox: no 'sent' receipt on outgoing message
  592. Tobias fippo, regarding that video..."you want ford be able to call general motors, etc." that all sounds like a nice fit for a federated system, but then again it's google
  593. lovetox Ge0rG, then the received ?
  594. lovetox that we want to get rid off ^^
  595. Ge0rG lovetox: Yeah, unless you're on mlink
  596. fippo tobias: well, meet. doesn't work in Firefox anymore than hangouts does...
  597. lovetox see now would be cool when we could join our own thread Ge0rG :D
  598. Tobias hangouts requires a plugin in FF anyway, not?
  599. fippo well, npapi died.
  600. blipp has left
  601. nicolas.verite has joined
  602. nicolas.verite has left
  603. Ge0rG lovetox: Yeah. Good luck getting that UX sorted out and introduced into all Jabber.. No, XMPP clients.
  604. lovetox maybe i do it once just for fun, i think gajim has already everything set up for it, window manager, thread managing, it just needs to be connected and a little bit of UI :)
  605. jonasw i doubt that it is "a little bit of UI", but sure. make a nice demo, I’d be interested in how this can work nicely
  606. nyco has joined
  607. lovetox i described it above, i would gather the different threads and display them in a list
  608. lovetox when the user clicks that list, a window opens where the messages are filtered with the thread
  609. Ge0rG This might also not be the biggest problem that gajim has...
  610. lovetox if he writes into that window, message goes to the thread
  611. lovetox seems pretty easy
  612. blipp has joined
  613. bit has left
  614. lovetox on desktop i dont have to put everything into one window :)
  615. jonasw yes you have.
  616. jonasw (but that is just my humble opinion ;-))
  617. lovetox dont limit the desktop to a bigger smartphone :)
  618. jonasw don’t litter my desktop with windows
  619. lovetox i actually dont, i can also use tabs inside one window ^^
  620. SamWhited What happens if I'm in a client that doesn't support threading and I reply to the discussion, then other people reply to me? It probably doesn't show up in your tab, and then you only see half the discussion and the thread is broken.
  621. lovetox yeah SamWhited of course you can sabotage it .. but if only gajim clients talk with each other it would work good :)
  622. lovetox and maybe others adopt it
  623. lovetox :)
  624. jonasw that’s not sabotaging, that’s simply interoperating
  625. SamWhited I read that as "so it will never work"
  626. jonasw or rather not interoperating
  627. SamWhited I'd love to see the UX issues around threading worked out; I've thought about this a lot and never been able to come up with a good way to do it that didn't just break constantly.
  628. lovetox but the breaking has nothing to do with your UX
  629. lovetox it has to do with other clients
  630. Ge0rG You just add a context menu "join with thread" that opens a sub menu with a list of all threads
  631. jonasw SamWhited: however, in lovetox’ defense: you will never be able to interoperate with clients which do not do threading properly. that’s simply how it is, it’s the same for email.
  632. SamWhited It doesn't matter; there will be other clients in the chat, and if they break the threading on my end and I'm a user all I know is "threading is broken, this is bad"
  633. jonasw indeed
  634. nicolas.verite has joined
  635. lovetox somebody has to start
  636. nicolas.verite has left
  637. jonasw yes, it’s tricky
  638. jonasw it would be good if one could somehow sanely detect these clients and fall back to a sane non-threaded UI for those
  639. jonasw or rather if those clients participate
  640. Ge0rG Or you'll end up with implausible requirements similar to OMEMO/MUC. All of the participants need to implement "Easy XMPP" and you need to have them in your roster for threading to work.
  641. SamWhited Now you have a UI inconsistency between rooms that have some other client joined, and rooms that don't, which also feels poor (maybe better, maybe worse? I'm not sure)
  642. lovetox as i said i would just show a list with all threads, you dont have to click them and join, you can just watch the muc like now ..
  643. lovetox its just a addtional tab when you want to use it and it works
  644. jonasw SamWhited: I think it’s better, because it is a more or less sane upgrade path to a world where all clients can do that
  645. SamWhited Also between the same room on one day and the same room 10 minutes later
  646. jonasw ugh
  647. jonasw it’s all a mess.
  648. SamWhited When I'm in a room, and a client that doesn't support threading joins, do all my threads just close? That will feel poor
  649. jonasw on a related matter: a XEP which allows me to post a simple reaction to a post would be great
  650. jonasw I’ve seen that with slack I think. or like you can on github issues
  651. jonasw those wouldn’t trigger any UI notifications, and it saves vertical space
  652. Lance https://xmpp.org/extensions/xep-0367.html ?
  653. lovetox SamWhited, why would a thread close? the messages have that thread on them and i can filter the window for it, it doesnt matter what another client does, except spamming my thread maybe
  654. SamWhited Yah, that's one of the things we were going to use 0367 for, although it's not called out explicitly and I don't think it's happening now
  655. jonasw SamWhited: do it like youtube "User XY does not have threading, thus we have to fold it all. We are sorry. (Blame them and hunt them with pitchforks & torches)"
  656. jonasw ah cool, SamWhited
  657. jonasw I was already thinking about 367, but it seemed to be too broad for that. if it is intended to serve that purpose, great!
  658. SamWhited lovetox: But now when that user replies, your threads break and we're back to the beginning
  659. Ge0rG Somehow, my smartphone miscompleted roster into rosette...
  660. waqas has left
  661. lovetox why would it break? what does breaking mean for you?
  662. lovetox adding a message that doesnt belong to the thread is breaking?
  663. jonasw lovetox: not correctly showing semantically related messages all the time
  664. jonasw yes.
  665. jonasw that’s breaking.
  666. SamWhited Their messages don't show up in the thread, and people are replying to the conversation both in the threaded room and in the non-threaded room
  667. Lance SamWhited: it'd also need message retracted to do the full reaction UX, but yeah that's what I had plans for with 367 too
  668. SamWhited now the thread is split between two places
  669. lovetox so when i go to a message board and post in the wrong topic, i broke the topic?
  670. SamWhited Lance: ah yah, good point; we never actually got that far
  671. lovetox yeah that people answer to it with the wrong thread on the message, ok
  672. lovetox that is a problem in the start
  673. lovetox that the filtering is not good
  674. lovetox but it would get better and better as more clients adapt
  675. lovetox this does not even mean implementing the same thing
  676. lovetox just use some sane rules on threads
  677. SamWhited It's nto that people are posting to the wrong topic though; a message board will show everyone a consistent view of what the topics are. It's juts that users are posting the only way they can, and it's breaking the thread for some users but not others.
  678. Ge0rG lovetox: in 20 years, there will still be people on the xsf MIX using Pidgin.
  679. nyco has joined
  680. lovetox i bet i get Ge0rG and inputmice, Link Mauve , mathieui and probably one or two other devs to not break my shiny new thread feature
  681. lovetox and we ban the rest from all mucs :D
  682. Lance has left
  683. Ge0rG lovetox: on mobile, people will just tap on the first instance of the person they want to complete.
  684. Ge0rG And you really really really don't want to promote lightweight threads to windows
  685. kaboom has left
  686. SamWhited I tried a web chat thing recently that did threads as windows; I thought it worked pretty well, the only problem was that it also kept the threads in the main chat view, which meant everyone just replied in the main chat view and the threads never got used
  687. Ge0rG SamWhited: sounds like slack
  688. lovetox UI for naming the threads then use tab completion
  689. SamWhited I haven't actually tried Slack since they introduced threading
  690. SamWhited lovetox: It's still more work than just typing your message and hitting enter, which means most people will ignore it
  691. Ge0rG SamWhited: I was the only one to try threading, so I consider it a UX failure
  692. lovetox not everything has to be used by everyone
  693. SamWhited Ge0rG: Yah, that's how I was with this messenger (I forget what it's called) that our team was playing with
  694. SamWhited lovetox: it does in this case, otherwise the threading is always broken and worthless
  695. SamWhited everyone or at least most people
  696. Ge0rG lovetox: you would need to provide visual hints, like color codes for the U to work out
  697. SamWhited That's what this did, which was actually rather nice, let me ask what it was called…
  698. lovetox ok what about this
  699. lovetox a work feature: there is no main chat view
  700. lovetox only a add thread button
  701. lovetox every thread gets his own window
  702. lovetox you can only answer to threads
  703. SamWhited Isn't taht just making new mucs at that point? (also, that still requires every client to do it)
  704. lovetox when you join you load mam, and get automatically a list with all threads
  705. Ge0rG lovetox: Yeah, will be broken immediately by an incompatible client
  706. lovetox thats why i said its a work feature
  707. lovetox like a company if they all use the same client
  708. Ge0rG And then some client will use auto increment integers for threads ids
  709. lovetox making a new muc has considerable overhead
  710. SamWhited yah, fair enough, it can work in closed environments
  711. lovetox actually is that not exactly what we need for mailing list replacement ^^
  712. lovetox a search function added and its perfect
  713. lovetox and its all archived in one single muc :D
  714. Ge0rG "Sending of MUC messages without a thread ID is disallowed by group policy. Please contact your chat administrator."
  715. nyco has joined
  716. Ge0rG lovetox: and you only can get the last 50 messages.
  717. SamWhited CA Flowdock is the thing we were looking at that did threading, btw; might be worth experimenting with if you're trying to do this: https://www.flowdock.com/
  718. daniel has left
  719. SamWhited It was pretty nice looking, but when we tried it no one used threads, so I felt like it was a failure.
  720. SamWhited Or rather, one person did, and everyone else replied in the normal chat and then they didn't see replies in the thread
  721. Ge0rG SamWhited: maybe they were using the xmpp transport? 😀
  722. daniel has left
  723. uc has left
  724. Tobias has joined
  725. uc has joined
  726. uc has left
  727. uc has joined
  728. Tobias has left
  729. daniel has left
  730. lovetox so lets recap this, instead of the participant list in the muc i show a thread list, the client has MAM so gets all backlog, the muc is moderated, only people with voice can post (members) and maybe a server addon kicks people that dont identify with the correct client
  731. jubalh has joined
  732. lovetox and you can only click on a thread and answer to a thread, never into the main muc
  733. SamWhited Does this mean there always ends up being an "offtopic" or "general" thread that's the new main muc?
  734. SamWhited (which is probably fine, just trying to nitpick things that feel odd)
  735. lovetox there is no main muc
  736. lovetox you have to add a thread to post
  737. lovetox like on the mailing list
  738. lovetox i mean you could create a general thread
  739. lovetox which is probably the same as posting to the main muc
  740. efrit has joined
  741. daniel has left
  742. lovetox could we not even write a application on the server that transforms the stanzas and groups them via threads, for a webview
  743. uc has left
  744. daniel has left
  745. uc has joined
  746. lovetox wonder that nobody did something like that already
  747. uc has left
  748. uc has joined
  749. daniel has left
  750. Ge0rG lovetox: sounds like a web forum to me
  751. lovetox yeah though via xmpp :D
  752. Ge0rG Yeah, let's reinvent a bad clone of NNTP over XML
  753. SamWhited wishes he could just have his usenet back and be done with it.
  754. uc has left
  755. SouL Forum + xmpp, would be really cool
  756. uc has joined
  757. daniel has left
  758. Ge0rG SamWhited: Yeah! But it'll never come back.
  759. Ge0rG 😟
  760. SamWhited Indeed; when I was in school we had free usenet on the campus network; it was great. All the clubs and frats and what not got issued a git.sga.yourclub or something (not that anyone ever used it; the theater did a bit for whatever reason though); but sometime during my junior year the guy who had built the system in the 90's came back to work at the school, was suprised to still find it running, and shut it down. It was very sad.
  761. Ge0rG We had a sat feed during the second half of the 90ies, it was awesome. Then the feed provider went bankrupt
  762. nicolas.verite has joined
  763. nicolas.verite has left
  764. SamWhited The problem with usenet in a nutshell… everyone who tried to run the infrastructure decided to synchronize alt.binaries or whatever, and then went bankrupt :)
  765. daniel has left
  766. jonasw :D
  767. Ge0rG SamWhited: that's because every user wanted alt.binaries ...
  768. Ge0rG And nothing else
  769. daniel has left
  770. daniel has left
  771. nicolas.verite has joined
  772. nicolas.verite has left
  773. nicolas.verite has joined
  774. nicolas.verite has left
  775. nicolas.verite has joined
  776. nicolas.verite has left
  777. nicolas.verite has joined
  778. nicolas.verite has left
  779. nicolas.verite has joined
  780. nicolas.verite has left
  781. daniel has left
  782. nicolas.verite has joined
  783. nicolas.verite has left
  784. arc has left
  785. arc has joined
  786. nicolas.verite has joined
  787. nicolas.verite has left
  788. nicolas.verite has joined
  789. nicolas.verite has left
  790. nicolas.verite has joined
  791. nicolas.verite has left
  792. nicolas.verite has joined
  793. nicolas.verite has left
  794. nyco has left
  795. jubalh has left
  796. jere has left
  797. goffi has joined
  798. nicolas.verite has joined
  799. nicolas.verite has left
  800. nicolas.verite has joined
  801. nicolas.verite has left
  802. Tobias has left
  803. daniel has left
  804. nicolas.verite has joined
  805. nicolas.verite has left
  806. jere has joined
  807. daniel has left
  808. daniel has left
  809. uc has left
  810. daniel has left
  811. Alex has left
  812. Alex has joined
  813. daniel has left
  814. daniel has left
  815. Flow jonasw: any particular reason the ecaps2 example uses BombusMod?
  816. Flow :)
  817. jonasw Flow: i think I even mention how I picked the examples
  818. jonasw ("first one in my capsdb which has this and that thing I want to show in that particular example")
  819. Flow jonasw: ok, I obviously didn't read that
  820. jonasw I knew people would wonder that :-)
  821. Flow is BombosMod still acticely developed?
  822. jonasw I have no idea.
  823. jonasw I am open to choosing different examples if it matters.
  824. Flow no, was just wondering
  825. Flow I do like what I read in ecaps2 so far
  826. jonasw that’s nice to hear :)
  827. daniel has left
  828. Flow did you already get feedback from wasqas?
  829. jonasw I don’t think so
  830. jonasw should probably ping him directly
  831. Flow why not, I don't think he would mind
  832. Flow jonasw: Once this is accepted, you should add references to the RFCs for UTF-8 and base64
  833. jonasw right, I’ll add it to my notes
  834. Flow using hashes:hash is also uncommen, but likely not invalid XMPP, but I wonder how many XMPP libs would break
  835. jonasw right, quite a few
  836. jonasw might adapt that example, even though it’s valid.
  837. jonasw makes it shorter to read though
  838. jonasw note also that in the wire format examples, I use xmlns="…" instead of prefixes
  839. nyco has joined
  840. Flow jonasw: also possible s/Append a "."./append a FULL STOP character (U+002E, ".")/, which would be how RFCs reference characters
  841. jonasw that sounds better
  842. jonasw noted
  843. SamWhited ooh, I didn't actually notice that. FWIW, I would have -1ed it if I did.
  844. SamWhited I obviously didn't read this carefully enough :)
  845. jonasw SamWhited: which exactly?
  846. SamWhited Use of namespace prefixes
  847. jonasw uh
  848. Flow what's wrong with namepsace prefixes?
  849. jonasw didn’t know that it was such a red flag. it’s not even in a wire format example though.
  850. SamWhited Ah, yah, reading over this and it doesn't look like they're required, just part of the example so I don't care as much. But yah, I deeply hate them.
  851. Flow SamWhited: I don't think that you hate them is a valid reason to -1 a ProtoXEP
  852. jonasw I like them. of course I don’t require them, because at the layer we’re working at, there’s nothing we can do to require them, really :-)
  853. SamWhited Nothing handles namespaces properly, and I constantly have to fight with the fact that stream's use prefixes and if you don't do it stuff breaks even if your stuff is technically still valid
  854. jonasw s/Nothing/Nothing you use/
  855. jonasw libxml and expat handle them just fine
  856. Flow We had the discussion to introduce a generic 'by' attribute using a prefix which gets re-used by other XEPs
  857. SamWhited Yah, fair; nothing I use. But as far as I can tell libxml2 and expat are just about the only things that handle them fine
  858. Flow And I still like the idea
  859. jonasw frankly I don’t understand what’s so hard about handling XML namespaces in parsing or serialisation.
  860. SamWhited It's not "hard" there are just too many edge cases because there are so many ways to represent the same data
  861. SamWhited Which leads to bugs
  862. SamWhited At least, that was my take from briefly playing around with creating a namespace aware XML parser
  863. waqas has joined
  864. SamWhited But personally I think we shouldn't encourage the use of namespace prefixes, it will just lead to interoperability issues. Just keep it simple.
  865. jonasw Personally I think we shouldn’t cater for broken XML implementations.
  866. SamWhited I agree in principle, but not in practice.
  867. jonasw but I bow to reality
  868. Guus has left
  869. nyco has joined
  870. nyco has joined
  871. lovetox has left
  872. lovetox has joined
  873. daniel has left
  874. nyco has joined
  875. pep. has joined
  876. Guus has left
  877. daniel has left
  878. waqas has left
  879. waqas has joined
  880. Guus has left
  881. Guus has left
  882. jonasw has left
  883. daniel has left
  884. lovetox if i send a message out to my own bareJID, will i always get the message back at the sending resource? or could the server choose another resource?
  885. lovetox Ge0rG,
  886. nicolas.verite has joined
  887. nicolas.verite has left
  888. nicolas.verite has joined
  889. nicolas.verite has left
  890. nicolas.verite has joined
  891. nicolas.verite has left
  892. nicolas.verite has joined
  893. nicolas.verite has left
  894. dwd lovetox, It's the same as any other message to your bare jid, and will be routed to one or more resources as per RFC 6121.
  895. nicolas.verite has joined
  896. nicolas.verite has left
  897. moparisthebest has joined
  898. Zash What have you people been up to today?
  899. goffi has left
  900. kaboom has left
  901. lovetox that is a bit vague
  902. lovetox deliver the message to the "most available" resource or resources (according to the server's implementation-specific algorithm, e.g., treating the resource or resources with the highest presence priority as "most available")
  903. lovetox thats my question, is the resource that sends the message out also the "most available" in that moment
  904. lovetox so can i assume it will always get it back and not another resource
  905. Zash -xep best practices for resource locking
  906. daniel has left
  907. dwd lovetox, Implementation-defined.
  908. winfried has left
  909. daniel has left
  910. nicolas.verite has joined
  911. nicolas.verite has left
  912. Alex has left
  913. SamWhited has left
  914. nyco has joined
  915. kaboom has left
  916. Alex has joined
  917. intosi has left
  918. Tobias has left
  919. bear has left
  920. suzyo has joined
  921. bear has joined
  922. Kev FWIW, we've had a long-standing stance to avoid namespaced attributes in the XMPP community.
  923. Kev On the basis that it's likely to break lots of things.
  924. Kev And that's about all I've got the energy to read up and notice.
  925. dwd Wait, namespaced *attributes*? I hadn't realised it was attributes. Nobody understands those (to a first approximation).
  926. Flow has joined
  927. goffi has joined
  928. Flow has left
  929. Zash What's attributes?
  930. Lance has joined
  931. dwd Oh. It's not. It's just a prefixed element, albeit with the prefix defined in a containing element. That's fine, and I see nothign wrong in that.
  932. Kev It is? I thought someone said about namespaced attributes.
  933. dwd Assumign the "hashes:hash" comment is referring to the bit just above https://xmpp.org/extensions/inbox/ecaps2.html#usecases
  934. dwd I can't see anythign using namespaced attributes in there.
  935. dwd Also, I cannot type.
  936. Kev Ah, this is ecaps, not ISR?
  937. Kev I've just checked, they seem to be heavily used in ISR.
  938. Kev e.g. <enabled xmlns='urn:xmpp:sm:3' xmlns:isr='urn:xmpp:isr:0' isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52' isr:location='isr.example.org:5222'/>
  939. Ge0rG lovetox:
  940. Kev Which is what I understand by the term 'namespaced attribute', at least.
  941. Ge0rG You are totally
  942. dwd Oh, I've been staring at that recently and didn't notice them.
  943. Ge0rG breaking my highlights.
  944. dwd Ge0rG, You should have them done at my place, that Julian he does my hair lovely.
  945. Ge0rG lovetox: there is no guarantee that you will receive the Self-JID message, unless you send it to your own full JID. But you will probably receive the carbon, unless you are on m-link,which is now breaking expectations by doing the right thing
  946. Ge0rG And this is why everything in XMPP is complicated.
  947. lovetox thats the problem i found out just now
  948. lovetox if the server doesnt sent it back to the sending resource
  949. lovetox the resource that gets the message, gets also a "sent" carbon
  950. lovetox so double message again
  951. lovetox and this time i can only deduplicate if i go to the db and see if the stanza id is already there
  952. Ge0rG lovetox: the best thing to do is to rely on 0198 acks and filter out the duplicate
  953. Ge0rG lovetox: yes, unless you already got the same stanza id some time in the past
  954. lovetox gajim uses uuid
  955. Ge0rG My MUC code used to rely on unique stanza ids, it was a bad idea
  956. Ge0rG lovetox: okay, if you only ever t check an ID generated by gajim, you'll be fine
  957. lovetox but thats a lot of work to get self messaging to what i want it to be :/
  958. Ge0rG lovetox: the good thing is that you are probably guaranteed to receive the message and the carbon right after each other.
  959. lovetox yeah its actually not a problem right now, because gajim has a mechansim in which it caches a hash of various message attributes, and drops messages with the same hash
  960. Ge0rG That sounds like somebody could exploit it
  961. lovetox to what end?
  962. Ge0rG lovetox: to prevent you from seeing messages?
  963. lovetox you can only achieve the same hash when you write the same message
  964. lovetox so i dont want to see that
  965. Valerian has left
  966. Ge0rG lovetox: is it a cryptographic hash?
  967. lovetox sha256
  968. lovetox you would have to put in real effort to not let me see that message
  969. lovetox you could also just not write it :D
  970. Zash has left
  971. lovetox ok have to go, good night :)
  972. lovetox has left
  973. Valerian has joined
  974. kalkin has left
  975. efrit has joined
  976. kalkin has joined
  977. daniel has left
  978. kalkin has left
  979. devnull has joined
  980. Guus has left
  981. daniel has left
  982. Valerian has left
  983. kalkin has joined
  984. daniel has joined
  985. moparisthebest has left
  986. moparisthebest has joined
  987. efrit has joined
  988. suzyo has left
  989. devnull has left
  990. devnull has left
  991. sezuan has left
  992. Alex has left
  993. winfried has left
  994. blabla has left
  995. blabla has joined
  996. kalkin has left
  997. winfried has left