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