XSF Discussion - 2019-01-13

  1. jonas’

    Kev, https://github.com/xsf/xeps/pull/718 ping again :)

  2. jonas’

    MattJ, I’m going to need context on this one: https://github.com/xsf/xeps/pull/696 These are non-editorial changes to a XEP which isn’t originally yours, which may well be fine, but I lack context which makes it obvious that it’s fine. Nobody has tried to ping the author either. And it has the [question] label. It is a very confusing thing.

  3. jonas’

    (Not to mention that I disagree with it on the technical level)

  4. MattJ

    Let's start with - what do you disagree with?

  5. MattJ

    btw, "nobody has tried to ping the author" -> actually I discussed it with Sam before I did the work and made the PR

  6. jonas’

    but Sam isn’t the author

  7. MattJ

    He isn't?

  8. jonas’


  9. jonas’

    I only saw the <author/> block, I missed the &sam;

  10. jonas’

    right, that works then

  11. jonas’

    (he also added a LGTM)

  12. MattJ


  13. jonas’

    I disagree with the requirement of <stanza-id/>. Where is it even written down that a MUC adds one, barring MAM support from the MUC (which may be disabled for lots of reasons)? Why not use @id and require the #stable_id feature (nowadays at least)?

  14. jonas’

    but that’s not a blocker for the merge anyways

  15. MattJ

    stable_id doesn't help anything in this case

  16. jonas’

    what am I missing?

  17. MattJ

    because two occupants can still legally use the same id

  18. jonas’

    I see

  19. Zash

    unique (full jid, id)

  20. jonas’

    MattJ, add a sender attribute to the <attach-to/> thing? I feel we discussed this at some point already…

  21. MattJ

    Zash, except you don't always see the real JID, and occupants can change nicks, and all the issues we always have with referring unambiguously to messages in MUCs

  22. jonas’

    occupants changing nicknames is irrelevant

  23. Zash

    MattJ: nyeh

  24. jonas’

    ah, no it’s not

  25. jonas’


  26. MattJ

    jonas’, yes, there were multiple options we discussed, this one came out as the (unclear) winner

  27. jonas’

    MattJ, then I’d still see the need for a feature on the MUC to discover that it will add a <stanza-id/>

  28. jonas’

    hm, no

  29. MattJ

    Client devs I polled preferred this one, because they are storing the stanza-id anyway

  30. jonas’

    because message attaching happens afterwards

  31. jonas’

    so it’s probably ok

  32. MattJ

    and it's a lot easier than implementing any other sender-matching logic

  33. jonas’


  34. MattJ

    so I'm totally open to other approaches, but we didn't find any that everyone liked

  35. MattJ

    Except this one, which seemed the least worst

  36. jonas’

    the missing not is still not fixed though

  37. MattJ

    Yes, I/someone can fix that, and also clarify that obviously the MUC will need to add stanza-id for this to work (if that's not already in there)

  38. jonas’

    I’m in the process of merging a few PRs, so if you fix that missing 'not' now I can hit the merge button on that one

  39. MattJ

    I don't think I can right now

  40. jonas’

    ah, meh

  41. MattJ

    Give me a few to try and placate this toddler

  42. MattJ

    and maybe I can

  43. jonas’

    I’ll add it and you can review

  44. jonas’

    MattJ, https://github.com/xsf/xeps/pull/696/files/eb87a3b0bc4aed4d1a80aa23354902a2c0001ee2..0edd42a89f5effa01434c69bbe84fa616477e1e7

  45. MattJ

    Looks good, thanks

  46. jonas’


  47. Ge0rG

    Using stanza id from the MAM also means you can't attach to a message of your own if it's not round trip reflected yet.

  48. jonas’

    Ge0rG, is that a problem?

  49. jonas’

    in practice.

  50. Ge0rG

    jonas’: yes. A good client should allow writing messages while offline, and deliver those once reconnected.

  51. Ge0rG

    So now I need to remember the local reference, have a queue of messages waiting for an event, and not mess it up if 0198 happens in the middle

  52. pep.

    Aren't you already doing that for LMC?

  53. Ge0rG

    pep.: no, LMC is based on @id, which I generate when sending

  54. Ge0rG

    I'm not saying it's the right thing™, but it works independently of the server.

  55. jonas’

    Ge0rG, I don’t see a better solution though, given that you cannot rely on @id at all here...

  56. jonas’

    although I think it was also argued that we might not have to care at all

  57. MattJ

    and attaching to your own messages wasn't really the intention of the XEP, if that matters

  58. Ge0rG

    I think the topic of unambiguous message references is something that warrants a session at Summit, and it's a huge pity that I won't be able to attend.

  59. MattJ

    oh no :(

  60. jonas’

    Ge0rG, not even remotely?

  61. jonas’

    (pun not intended)

  62. Ge0rG

    I *might* dial into the webex, but no promises yet.

  63. jonas’

    I should see if I use one or two days off to attend remotely

  64. Ge0rG

    MattJ: I think we need to solve message referencing in the same way for all protocols, if possible.

  65. MattJ


  66. Ge0rG

    And IMVHO it is a viable thing to demand that modern clients create strongly unique ids, and to degrade service quality for clients that violate that.

  67. jonas’

    Ge0rG, I agree

  68. Ge0rG

    Which is why I'm insisting on using @id for those purposes

  69. jonas’

    but we need to figure out a way to do that which is safe against malicious clients

  70. Ge0rG

    And which is why I oppose origin-id.

  71. jonas’

    it’s "meh" when an attacker can duplicate your @id and then nobody can react or attach to your message anymore

  72. Ge0rG

    jonas’: the only solution I see for that is for a server to become the authority on message ids... Except what if there is a malicious server?

  73. Ge0rG

    A MUC could reject a message without @id, or with a duplicate @id, or even assign a new @id to that message for all but the sending participant.

  74. jonas’

    Ge0rG, then the sending participant won’t be able to match attachments correctly

  75. jonas’

    which is fine for malicious entities obviously

  76. Ge0rG

    jonas’: and for clients that don't support attaching.

  77. jonas’

    a malicious MUC server is obviously an issue, but that’s a given

  78. jonas’

    Ge0rG, also true. But this requires a bunch of memory or CPU resoures on the MUC server to keep track of used IDs.

  79. Ge0rG

    jonas’: yes, and some kind of agreement about the history size...

  80. jonas’

    which brings me back to my suggestion of using cryptographic counters for messages and sync them on MUC join

  81. jonas’

    which is of course massively overengineered

  82. Ge0rG

    This is a bottomless pit, right? Can we please have a pragmatic solution?

  83. Zash

    Blockchain? :P

  84. jonas’

    the pragmatic solution is to use <stanza-id/> in group chats.

  85. Ge0rG

    Also one where the complexity is in the server, not in the client?

  86. jonas’

    which simply means you cannot react-to your unsent message

  87. jonas’

    that’s a minor issue methinks

  88. Ge0rG

    Did I mention that I hate stanza-id? :D

  89. jonas’


  90. Maranda


  91. Maranda