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