jdev - 2020-04-01


  1. Martin

    Is XEP-0333: Chat Markers the XEP currently used when you want to sync the state of your read position between devices?

  2. lovetox

    yes Martin

  3. Martin

    thanks

  4. 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?

  5. Ge0rG

    I suppose it's related to 86548b87bb

  6. pep.

    Martin: see also 0430-Inbox

  7. pep.

    (which is probably gonna use 333 to some extent)

  8. 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.

  9. 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

  10. Ge0rG

    flow: do you have integration tests for handling multiple IQs in sequence?

  11. Ge0rG

    the issue description in https://discourse.igniterealtime.org/t/issue-reporting-concerning-smack-312-and-rosterentry-setname/71838 is very accurate

  12. flow

    Ge0rG, I am sorry, but I do not understand the "multiple IQs in sequence" part of the question

  13. 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

  14. Ge0rG

    thus one outgoing roster change IQ plus response, one incoming roster push IQ

  15. flow

    so? As far as I understand the issue, an integration test would invoke setName() and check that the exepcted callback is invoked

  16. Ge0rG

    flow: yes, but that integration test would require a mock server to send a push after the roster change

  17. flow

    Ge0rG, integration tests run against real servers

  18. flow

    but unrelated, this probably can be also done as unit test as smack has test fixtures to simulte the responses from a server

  19. Ge0rG

    flow: I haven't checked for the presence of either kind of tests for this specific issue

  20. flow

    unrelated: this probably can be also done as unit test as smack has test fixtures to simulate the responses from a server

  21. Ge0rG

    testChangeNameToUnfiledEntry() looks like it *might* be doing this kind of test

  22. Ge0rG

    but maybe roster.reload() in the middle actually breaks it?

  23. flow

    potentially. I had a quick look at the code, could be that simply removing item.setName(name) in RsoterEntry.setName() does the trick

  24. 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

  25. Ge0rG

    I suppose the cleaner solution would be to have a different method than setName() that would also trigger the callback

  26. flow

    yeah, i somehow feel that's the reason the item.setName() is there in the first place

  27. Martin

    pep.: > Martin: see also 0430-Inbox Thanks 😃

  28. flow

    ahh hmm, right, RosterEntry.setName() could invoke the callback itself

  29. Ge0rG

    flow: looks like it is only ever called from RosterItem.setName() so that sounds valid

  30. lovetox

    Ge0rG, i dont get your reply on list regarding muc versioning

  31. lovetox

    why would you need to query the member list?

  32. lovetox

    ah because of offline members

  33. lovetox

    but the XEP says you get a presence for those aswell

  34. Ge0rG

    exacttly

  35. lovetox

    so why?

  36. Ge0rG

    lovetox: it doesn't say that.

  37. lovetox

    hm

  38. Ge0rG

    lovetox: it suggests that as an optional optimization

  39. lovetox

    but would that not be preferable instead of redesigning member querying

  40. lovetox

    this would make impl much more easy for clients

  41. lovetox

    and not try to mach infos from different querys into one

  42. Ge0rG

    lovetox: yes, it would be great.

  43. lovetox

    the problem is it breaks clients

  44. Ge0rG

    does it?

  45. lovetox

    because the server cannot know if a client supports the XEP, so it cant just send unavailable presences on join

  46. Ge0rG

    MattJ said it shouldn't, as it is also used to inform clients about live membership changes

  47. lovetox

    which is not in the spec

  48. lovetox

    ah ok

  49. lovetox

    if thats so, then im in favor of just adding this to that xep

  50. Ge0rG

    and GC1 clients already were exposed to presence-unavailable for occupants they didn't ever see

  51. lovetox

    this is definitly strong contender for XEP of the year

  52. lovetox

    this is an insane performance boost when joining mucs

  53. lovetox

    i want to implement it right now

  54. MattJ

    :)

  55. Ge0rG

    lovetox: maybe you should wait for the Council to accept it ;)

  56. 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.

  57. lovetox

    what im missing in the XEP is, does the server summary of presence stanzas?

  58. lovetox

    like if since my last join a user 200times changed his nickname

  59. lovetox

    do i get all those changes?

  60. MattJ

    You don't

  61. Ge0rG

    MattJ: that should be mentioned more explicitly

  62. MattJ

    +1

  63. MattJ

    On the other hand...

  64. Ge0rG

    MattJ: also the note regarding @ver being opaque

  65. MattJ

    It don't make much difference to the client, does it? (apart from performance)

  66. Ge0rG

    MattJ: in theory, you should send all changes to occupation and messages interleaved.

  67. lovetox

    yeah with nickchanges it gets tricky

  68. Zash

    Presence in MAM?

  69. lovetox

    hmm

  70. lovetox

    no really the nick changes are a problem or not?

  71. 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)

  72. Ge0rG

    MattJ: I was quoting from XEP-0237

  73. MattJ

    lovetox, at a minimum you would see the old nick leave and the new one join

  74. lovetox

    MattJ the problem is if that nick sent messages in between

  75. MattJ

    I guess the nick change status code /should/ be included, but if we can avoid mandating that I'd like to...

  76. Ge0rG

    what if somebody else joined under that nick inbetween?

  77. MattJ

    Yeah, though this problem exists without presence versioning

  78. Ge0rG

    and wrote nasty messages.

  79. MattJ

    Leave room, nick change, message, nick change, rejoin the room

  80. Zash

    Tie it into Occupant ID?

  81. lovetox

    yeah true, if i get this message via MAM i cant say who wrote it

  82. 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

  83. lovetox

    i guess this is the point of an anonymous muc anyway

  84. lovetox

    but yeah occupant id would solve that

  85. lovetox

    although no idea how i should display such thing UI wise to the user :D

  86. lovetox

    probably add the occupant-id into the color hash

  87. Ge0rG

    lovetox: maybe you should only care about this problem in private closed-group MUCs

  88. Ge0rG

    and in non-anon MUCs MAM will append the real-jid, or something?

  89. lovetox

    hm yeah

  90. lovetox

    though UI wise i could simply display real jids in a tooltip

  91. lovetox

    so at least there is a way for the user to discover that

  92. lovetox

    and no in non-anon room the color hash is of the real jid anyway

  93. lovetox

    so in theory the user is more than equiped to notice that

  94. Ge0rG

    color hash ❤

  95. lovetox

    or whatever it is called

  96. lovetox

    the thing that generates the user color

  97. Ge0rG

    I just love the feature

  98. lovetox

    its great though i get sometimes very similiar colors

  99. lovetox

    but added with avatars it should be ok

  100. pep.

    Is anybody actually having perf issues with current MUC btw? And from what amount of users?

  101. pep.

    That is noticeable to other users*

  102. Ge0rG

    joining the Matrix HQ takes a minute or two. Some client implementations will use that to time-out the join

  103. MattJ

    The conversation that sparked this XEP involved a MUC with 5-10k users

  104. pep.

    Right, so not a typical XMPP channel

  105. Ge0rG

    Are there actual MUCs with this many people?

  106. MattJ

    (it's not clear that this spec alone is going to suffice for solving that)

  107. MattJ

    Ge0rG, yes, though obviously in custom deployments

  108. Zash

    Might wanna limit presence to those recetly active?

  109. Ge0rG

    Also... if most of these users are joining and leaving at typical rates, the delta will be longer than the absolute list ;)

  110. MattJ

    Things like "dump all employees into a single MUC" (if you've used Slack, something like their default #general channel)

  111. MattJ

    Ge0rG, yes, as in roster versioning the server should be free to just send the current list

  112. Ge0rG

    MattJ: see my marker token response on the ML

  113. Ge0rG

    flow: do you have the setName() thing on your agenda or are you anticipating a PR?

  114. 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?).

  115. 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

  116. lovetox

    hm so i get the ver attribute only on my self presence

  117. Ge0rG

    it needs to be on every presence

  118. lovetox

    this means i receive X presences and dont know if this is a catchup or not

  119. Ge0rG

    and yes, the reset token must come first, before any presence

  120. lovetox

    was there ever an update to Serverless Messaging

  121. lovetox

    maybe some xep that defines some transport encryption

  122. lovetox

    Even most E2E is hard, because we have no PEP to share keys and stuff

  123. jonas’

    OTR would work just fine

  124. jonas’

    :>

  125. lovetox

    legacy PGP works also

  126. jonas’

    see, all the good stuff is just fine

  127. lovetox

    Link Mauve, tells me often he like that feature on conferences

  128. lovetox

    but not so sure if people really like it to send messages plain over open wlan networks

  129. flow

    I am not sure if transport encryption is feasible with serverless messaging

  130. jonas’

    it is, anonymous TLS is (was?) a thing

  131. jonas’

    it’s only useful against passive attackers though

  132. Zash

    jonas’: Is it still?

  133. jonas’

    if it isn’t, you can still generate a self-signed certificate for your hostname

  134. jonas’

    could even do TOFU key pinning

  135. Zash

    Tie it into the E2EE thing of your choice

  136. Zash

    or into a overlay network like Tor

  137. Zash

    There's an RFC about using OpenPGP keys in TLS

  138. flow

    ahh right, that would be worth an experiment

  139. Zash

    Anon TLS and then use some E2EE or similar magic to authenticate the connection, like how SCRAM-PLUS works

  140. mathieui

    is there any client other than gajim that does serveless messaging though?

  141. Zash

    Pidgin

  142. Zash

    There's a thing in the Swift tree too

  143. Zash

    and Telepathy I think?

  144. Zash

    > thing in Swift thing that works like a server and translates to serverless, so should work with any client

  145. flow

    mathieui, I hope to continue working on smack's support for serverless

  146. Kev

    "Slimber"

  147. 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)

  148. pep.

    Or E2EE indeed

  149. Zash

    Like why hasn't anyone just taken Tor and hooked it into a serverless-messaging thing?

  150. pep.

    who knows

  151. Zash

    Extra secure E2EE!!! P2P! All the buzzwords!

  152. pep.

    Maybe it's just another case of bad marketting

  153. Zash

    But no, everyone's just reinventing the full stack from scratch.