jdev - 2020-04-01


  1. paul has left
  2. debacle has left
  3. moparisthebest has left
  4. moparisthebest has joined
  5. strar has left
  6. strar has joined
  7. DebXWoody has joined
  8. moparisthebest has left
  9. DebXWoody has left
  10. adrien has left
  11. adrien has joined
  12. paul has joined
  13. wurstsalat has joined
  14. Martin has left
  15. rion has left
  16. rion has joined
  17. rion has left
  18. rion has joined
  19. debacle has joined
  20. kikuchiyo has joined
  21. rion has left
  22. rion has joined
  23. pulkomandy has left
  24. pulkomandy has joined
  25. DebXWoody has joined
  26. Martin has joined
  27. Martin Is XEP-0333: Chat Markers the XEP currently used when you want to sync the state of your read position between devices?
  28. asterix has joined
  29. pulkomandy has left
  30. pulkomandy has joined
  31. dendang has joined
  32. dendang has left
  33. pulkomandy has left
  34. pulkomandy has joined
  35. dendang has joined
  36. asterix has left
  37. asterix has joined
  38. goffi has joined
  39. pulkomandy has left
  40. pulkomandy has joined
  41. wurstsalat has left
  42. MattJ has left
  43. jonas’ has left
  44. flow has left
  45. paul has left
  46. larma has left
  47. flow has joined
  48. asterix has left
  49. asterix has joined
  50. jonas’ has joined
  51. lovetox has left
  52. pulkomandy has left
  53. pulkomandy has joined
  54. MattJ has joined
  55. larma has joined
  56. goffi has left
  57. goffi has joined
  58. lovetox has joined
  59. asterix has left
  60. asterix has joined
  61. pulkomandy has left
  62. pulkomandy has joined
  63. asterix has left
  64. asterix has joined
  65. asterix has left
  66. asterix has joined
  67. goffi has left
  68. goffi has joined
  69. kikuchiyo has left
  70. kikuchiyo has joined
  71. pulkomandy has left
  72. pulkomandy has joined
  73. lovetox yes Martin
  74. Martin thanks
  75. pulkomandy has left
  76. pulkomandy has joined
  77. wurstsalat has joined
  78. dendang has left
  79. dendang has joined
  80. Ge0rG flow: I've just encountered an issue on smack 4.3.4 that looks like an exact reappearance of https://discourse.igniterealtime.org/t/issue-reporting-concerning-smack-312-and-rosterentry-setname/71838 and https://discourse.igniterealtime.org/t/smack-4-1-0-rosterentry-setname-doesnt-change-the-name/73006 - do you know anything about that?
  81. adrien has left
  82. adrien has joined
  83. Ge0rG I suppose it's related to 86548b87bb
  84. pep. Martin: see also 0430-Inbox
  85. pep. (which is probably gonna use 333 to some extent)
  86. flow Ge0rG, its not easy to comment on "an issue" without a clear issue description. I guess you probably talking about RosterEntry.setName() not changing the name? And why do you suppose that it is related to 86548? That information would be helpful. I am not aware of issues with that part of the API. But if a previously closed issues reappears that this should probably lead to an integreation test to avoid regressions in this area. A minimal reproducer would be nice, to debug the issue and to act as base for a potential integration test.
  87. Ge0rG flow: RosterEntry.setName() does change the name but it doesn't fire the RosterListener.entriesUpdated() callback. In 86548 the code was changed from changing an internal shadow copy of the name in RosterEntry to silently changing the "master" value in the RosterItem. So there is no entriesUpdated() from setName(), and then the incoming roster push is processed, but the RosterItem already has the new name so no entriesUpdated() is fired either
  88. Ge0rG flow: do you have integration tests for handling multiple IQs in sequence?
  89. asterix has left
  90. asterix has joined
  91. Ge0rG the issue description in https://discourse.igniterealtime.org/t/issue-reporting-concerning-smack-312-and-rosterentry-setname/71838 is very accurate
  92. flow Ge0rG, I am sorry, but I do not understand the "multiple IQs in sequence" part of the question
  93. Ge0rG flow: setName() issues a roster update IQ and waits for the result, which is allowed to be empty. The actual roster change then would come as a roster push from the server
  94. Ge0rG thus one outgoing roster change IQ plus response, one incoming roster push IQ
  95. flow so? As far as I understand the issue, an integration test would invoke setName() and check that the exepcted callback is invoked
  96. Ge0rG flow: yes, but that integration test would require a mock server to send a push after the roster change
  97. flow Ge0rG, integration tests run against real servers
  98. flow but unrelated, this probably can be also done as unit test as smack has test fixtures to simulte the responses from a server
  99. Ge0rG flow: I haven't checked for the presence of either kind of tests for this specific issue
  100. strar has left
  101. flow unrelated: this probably can be also done as unit test as smack has test fixtures to simulate the responses from a server
  102. strar has joined
  103. pulkomandy has left
  104. pulkomandy has joined
  105. Ge0rG testChangeNameToUnfiledEntry() looks like it *might* be doing this kind of test
  106. Ge0rG but maybe roster.reload() in the middle actually breaks it?
  107. rion has left
  108. rion has joined
  109. flow potentially. I had a quick look at the code, could be that simply removing item.setName(name) in RsoterEntry.setName() does the trick
  110. Ge0rG flow: I'm pretty sure it will, except that you won't get an update on the incoming IQ result ack but only after the push
  111. Ge0rG I suppose the cleaner solution would be to have a different method than setName() that would also trigger the callback
  112. flow yeah, i somehow feel that's the reason the item.setName() is there in the first place
  113. Martin pep.: > Martin: see also 0430-Inbox Thanks 😃
  114. flow ahh hmm, right, RosterEntry.setName() could invoke the callback itself
  115. Ge0rG flow: looks like it is only ever called from RosterItem.setName() so that sounds valid
  116. asterix has left
  117. asterix has joined
  118. pulkomandy has left
  119. pulkomandy has joined
  120. asterix has left
  121. asterix has joined
  122. asterix has left
  123. asterix has joined
  124. asterix has left
  125. asterix has joined
  126. asterix has left
  127. asterix has joined
  128. moparisthebest has joined
  129. Sam Whited has left
  130. asterix has left
  131. asterix has joined
  132. pulkomandy has left
  133. pulkomandy has joined
  134. DebXWoody has left
  135. asterix has left
  136. asterix has joined
  137. asterix has left
  138. asterix has joined
  139. asterix has left
  140. asterix has joined
  141. asterix has left
  142. asterix has joined
  143. tsk has joined
  144. asterix has left
  145. asterix has joined
  146. asterix has left
  147. asterix has joined
  148. asterix has left
  149. asterix has joined
  150. DebXWoody has joined
  151. pulkomandy has left
  152. pulkomandy has joined
  153. asterix has left
  154. asterix has joined
  155. tsk has left
  156. asterix has left
  157. asterix has joined
  158. pulkomandy has left
  159. pulkomandy has joined
  160. asterix has left
  161. asterix has joined
  162. asterix has left
  163. asterix has joined
  164. Wojtek has joined
  165. lovetox Ge0rG, i dont get your reply on list regarding muc versioning
  166. lovetox why would you need to query the member list?
  167. lovetox ah because of offline members
  168. lovetox but the XEP says you get a presence for those aswell
  169. Ge0rG exacttly
  170. lovetox so why?
  171. Ge0rG lovetox: it doesn't say that.
  172. lovetox hm
  173. Ge0rG lovetox: it suggests that as an optional optimization
  174. lovetox but would that not be preferable instead of redesigning member querying
  175. lovetox this would make impl much more easy for clients
  176. lovetox and not try to mach infos from different querys into one
  177. Ge0rG lovetox: yes, it would be great.
  178. lovetox the problem is it breaks clients
  179. Ge0rG does it?
  180. lovetox because the server cannot know if a client supports the XEP, so it cant just send unavailable presences on join
  181. Ge0rG MattJ said it shouldn't, as it is also used to inform clients about live membership changes
  182. lovetox which is not in the spec
  183. lovetox ah ok
  184. lovetox if thats so, then im in favor of just adding this to that xep
  185. Ge0rG and GC1 clients already were exposed to presence-unavailable for occupants they didn't ever see
  186. asterix has left
  187. asterix has joined
  188. lovetox this is definitly strong contender for XEP of the year
  189. asterix has left
  190. asterix has joined
  191. lovetox this is an insane performance boost when joining mucs
  192. lovetox i want to implement it right now
  193. MattJ :)
  194. Ge0rG lovetox: maybe you should wait for the Council to accept it ;)
  195. pulkomandy has left
  196. Ge0rG Oh, one thing I missed mentioning: > The value MUST be generated only by the server and MUST be treated by the client as opaque.
  197. serge90 has left
  198. serge90 has joined
  199. lovetox what im missing in the XEP is, does the server summary of presence stanzas?
  200. lovetox like if since my last join a user 200times changed his nickname
  201. lovetox do i get all those changes?
  202. MattJ You don't
  203. Ge0rG MattJ: that should be mentioned more explicitly
  204. MattJ +1
  205. MattJ On the other hand...
  206. Ge0rG MattJ: also the note regarding @ver being opaque
  207. MattJ It don't make much difference to the client, does it? (apart from performance)
  208. asterix has left
  209. asterix has joined
  210. Ge0rG MattJ: in theory, you should send all changes to occupation and messages interleaved.
  211. lovetox yeah with nickchanges it gets tricky
  212. Zash Presence in MAM?
  213. lovetox hmm
  214. lovetox no really the nick changes are a problem or not?
  215. MattJ Oh, regarding the opaque thing I assumed you were quoting from the XEP... I had agreed with JC that it would be opaque to the client (because this leaves a lot of doors open for the server implementation, which is important)
  216. Ge0rG MattJ: I was quoting from XEP-0237
  217. MattJ lovetox, at a minimum you would see the old nick leave and the new one join
  218. lovetox MattJ the problem is if that nick sent messages in between
  219. MattJ I guess the nick change status code /should/ be included, but if we can avoid mandating that I'd like to...
  220. Ge0rG what if somebody else joined under that nick inbetween?
  221. MattJ Yeah, though this problem exists without presence versioning
  222. Ge0rG and wrote nasty messages.
  223. MattJ Leave room, nick change, message, nick change, rejoin the room
  224. Zash Tie it into Occupant ID?
  225. lovetox yeah true, if i get this message via MAM i cant say who wrote it
  226. MattJ So I don't see that this spec makes the situation any worse than today, nor is it this spec's duty to solve that problem
  227. lovetox i guess this is the point of an anonymous muc anyway
  228. lovetox but yeah occupant id would solve that
  229. lovetox although no idea how i should display such thing UI wise to the user :D
  230. lovetox probably add the occupant-id into the color hash
  231. Ge0rG lovetox: maybe you should only care about this problem in private closed-group MUCs
  232. Ge0rG and in non-anon MUCs MAM will append the real-jid, or something?
  233. lovetox hm yeah
  234. lovetox though UI wise i could simply display real jids in a tooltip
  235. lovetox so at least there is a way for the user to discover that
  236. lovetox and no in non-anon room the color hash is of the real jid anyway
  237. lovetox so in theory the user is more than equiped to notice that
  238. Ge0rG color hash ❤
  239. lovetox or whatever it is called
  240. lovetox the thing that generates the user color
  241. Ge0rG I just love the feature
  242. pulkomandy has joined
  243. lovetox its great though i get sometimes very similiar colors
  244. lovetox but added with avatars it should be ok
  245. asterix has left
  246. asterix has joined
  247. asterix has left
  248. asterix has joined
  249. asterix has left
  250. asterix has joined
  251. asterix has left
  252. asterix has joined
  253. pep. Is anybody actually having perf issues with current MUC btw? And from what amount of users?
  254. pep. That is noticeable to other users*
  255. Ge0rG joining the Matrix HQ takes a minute or two. Some client implementations will use that to time-out the join
  256. MattJ The conversation that sparked this XEP involved a MUC with 5-10k users
  257. pep. Right, so not a typical XMPP channel
  258. Ge0rG Are there actual MUCs with this many people?
  259. MattJ (it's not clear that this spec alone is going to suffice for solving that)
  260. MattJ Ge0rG, yes, though obviously in custom deployments
  261. asterix has left
  262. asterix has joined
  263. Zash Might wanna limit presence to those recetly active?
  264. asterix has left
  265. asterix has joined
  266. Ge0rG Also... if most of these users are joining and leaving at typical rates, the delta will be longer than the absolute list ;)
  267. MattJ Things like "dump all employees into a single MUC" (if you've used Slack, something like their default #general channel)
  268. MattJ Ge0rG, yes, as in roster versioning the server should be free to just send the current list
  269. pulkomandy has left
  270. pulkomandy has joined
  271. lovetox has left
  272. asterix has left
  273. asterix has joined
  274. Ge0rG MattJ: see my marker token response on the ML
  275. asterix has left
  276. asterix has joined
  277. asterix has left
  278. asterix has joined
  279. asterix has left
  280. asterix has joined
  281. pulkomandy has left
  282. paul has joined
  283. pulkomandy has joined
  284. asterix has left
  285. asterix has joined
  286. pulkomandy has left
  287. asterix has left
  288. asterix has joined
  289. asterix has left
  290. asterix has joined
  291. pulkomandy has joined
  292. Ge0rG flow: do you have the setName() thing on your agenda or are you anticipating a PR?
  293. asterix has left
  294. asterix has joined
  295. asterix has left
  296. asterix has joined
  297. asterix has left
  298. asterix has joined
  299. asterix has left
  300. asterix has joined
  301. lovetox has joined
  302. asterix has left
  303. asterix has joined
  304. asterix has left
  305. asterix has joined
  306. serge90 has left
  307. serge90 has joined
  308. pulkomandy has left
  309. pulkomandy has joined
  310. serge90 has left
  311. serge90 has joined
  312. flow Ge0rG, I would anticipate something that reminds me that it is an open issue. Either a forum post, PR or an new Smack issue (IIRC your JIRA account can create smack issues?).
  313. serge90 has left
  314. serge90 has joined
  315. sonny has left
  316. serge90 has left
  317. pulkomandy has left
  318. serge90 has joined
  319. serge90 has left
  320. pulkomandy has joined
  321. serge90 has joined
  322. serge90 has left
  323. serge90 has joined
  324. serge90 has left
  325. serge90 has joined
  326. serge90 has left
  327. serge90 has joined
  328. pulkomandy has left
  329. serge90 has left
  330. serge90 has joined
  331. Ge0rG flow: it looks like RosterEntry.setName() is the only relevant place to change, as there are no other methods for manipulating individual entries, and the RosterGroup modifer functions all rely on the reflected roster push
  332. sonny has joined
  333. pulkomandy has joined
  334. serge90 has left
  335. serge90 has joined
  336. serge90 has left
  337. serge90 has joined
  338. serge90 has left
  339. serge90 has joined
  340. lovetox hm so i get the ver attribute only on my self presence
  341. Ge0rG it needs to be on every presence
  342. lovetox this means i receive X presences and dont know if this is a catchup or not
  343. Ge0rG and yes, the reset token must come first, before any presence
  344. alexis has left
  345. serge90 has left
  346. serge90 has joined
  347. serge90 has left
  348. serge90 has joined
  349. pulkomandy has left
  350. adrien has left
  351. serge90 has left
  352. serge90 has joined
  353. adrien has joined
  354. serge90 has left
  355. serge90 has joined
  356. pulkomandy has joined
  357. pulkomandy has left
  358. serge90 has left
  359. serge90 has joined
  360. pulkomandy has joined
  361. lovetox was there ever an update to Serverless Messaging
  362. lovetox maybe some xep that defines some transport encryption
  363. lovetox Even most E2E is hard, because we have no PEP to share keys and stuff
  364. jonas’ OTR would work just fine
  365. jonas’ :>
  366. lovetox legacy PGP works also
  367. jonas’ see, all the good stuff is just fine
  368. lovetox Link Mauve, tells me often he like that feature on conferences
  369. serge90 has left
  370. lovetox but not so sure if people really like it to send messages plain over open wlan networks
  371. serge90 has joined
  372. Martin has left
  373. Martin has joined
  374. serge90 has left
  375. serge90 has joined
  376. flow I am not sure if transport encryption is feasible with serverless messaging
  377. jonas’ it is, anonymous TLS is (was?) a thing
  378. jonas’ it’s only useful against passive attackers though
  379. Zash jonas’: Is it still?
  380. jonas’ if it isn’t, you can still generate a self-signed certificate for your hostname
  381. jonas’ could even do TOFU key pinning
  382. Zash Tie it into the E2EE thing of your choice
  383. Zash or into a overlay network like Tor
  384. Zash There's an RFC about using OpenPGP keys in TLS
  385. serge90 has left
  386. serge90 has joined
  387. flow ahh right, that would be worth an experiment
  388. Zash Anon TLS and then use some E2EE or similar magic to authenticate the connection, like how SCRAM-PLUS works
  389. mathieui is there any client other than gajim that does serveless messaging though?
  390. Zash Pidgin
  391. Zash There's a thing in the Swift tree too
  392. Zash and Telepathy I think?
  393. Zash > thing in Swift thing that works like a server and translates to serverless, so should work with any client
  394. flow mathieui, I hope to continue working on smack's support for serverless
  395. Kev "Slimber"
  396. asterix has left
  397. SouL has left
  398. asterix has joined
  399. pulkomandy has left
  400. SouL has joined
  401. serge90 has left
  402. serge90 has joined
  403. pep. serverless messaging could very well use XTLS and even if XTLS itself still allows MITM, that could be initiated via a secure channel (normal XMPP connections)
  404. pep. Or E2EE indeed
  405. Zash Like why hasn't anyone just taken Tor and hooked it into a serverless-messaging thing?
  406. pep. who knows
  407. Zash Extra secure E2EE!!! P2P! All the buzzwords!
  408. pep. Maybe it's just another case of bad marketting
  409. Zash But no, everyone's just reinventing the full stack from scratch.
  410. SouL has left
  411. SouL has joined
  412. serge90 has left
  413. serge90 has joined
  414. pulkomandy has joined
  415. SouL has left
  416. tsk has joined
  417. SouL has joined
  418. serge90 has left
  419. serge90 has joined
  420. serge90 has left
  421. serge90 has joined
  422. tsk has left
  423. serge90 has left
  424. serge90 has joined
  425. serge90 has left
  426. serge90 has joined
  427. DebXWoody has left
  428. serge90 has left
  429. serge90 has joined
  430. serge90 has left
  431. serge90 has joined
  432. serge90 has left
  433. serge90 has joined
  434. Marc has left
  435. Marc has joined
  436. serge90 has left
  437. serge90 has joined
  438. asterix has left
  439. asterix has joined
  440. serge90 has left
  441. serge90 has joined
  442. serge90 has left
  443. serge90 has joined
  444. serge90 has left
  445. serge90 has joined
  446. serge90 has left
  447. serge90 has joined
  448. asterix has left
  449. asterix has joined
  450. asterix has left
  451. asterix has joined
  452. serge90 has left
  453. serge90 has joined
  454. serge90 has left
  455. serge90 has joined
  456. DebXWoody has joined
  457. DebXWoody has left
  458. serge90 has left
  459. serge90 has joined
  460. serge90 has left
  461. serge90 has joined
  462. dendang has left
  463. lovetox has left
  464. serge90 has left
  465. serge90 has joined
  466. serge90 has left
  467. serge90 has joined
  468. serge90 has left
  469. serge90 has joined
  470. serge90 has left
  471. moparisthebest has left
  472. alexis has joined
  473. moparisthebest has joined
  474. gav has left
  475. gav has joined
  476. asterix has left
  477. asterix has joined
  478. asterix has left
  479. pulkomandy has left
  480. pulkomandy has joined
  481. goffi has left
  482. goffi has joined
  483. goffi has left
  484. strar has left
  485. pulkomandy has left
  486. pulkomandy has joined
  487. strar has joined
  488. pulkomandy has left
  489. pulkomandy has joined
  490. pulkomandy has left
  491. pulkomandy has joined
  492. moparisthebest has left
  493. moparisthebest has joined
  494. strar has left
  495. strar has joined
  496. strar has left
  497. strar has joined
  498. Wojtek has left
  499. strar has left
  500. strar has joined
  501. moparisthebest has left
  502. moparisthebest has joined
  503. moparisthebest has left
  504. moparisthebest has joined
  505. moparisthebest has left
  506. moparisthebest has joined