XMPP Council - 2023-02-22

  1. larma

    👋

  2. Ge0rG

    😜

  3. jonas’

    o/

  4. daniel

    Hi

  5. daniel

    1) Roll call

  6. jonas’

  7. moparisthebest

    Hello

  8. daniel

    I don’t think we have anything to talk about. the editor isn’t active currently

  9. daniel

    so instead of running through an empty agenda I’m just going to jump to AOB

  10. daniel

    does anyone have any AOB?

  11. jonas’

    I do not

  12. Ge0rG

    none here

  13. moparisthebest

    Nope

  14. larma

    No

  15. daniel

    ok. that was uneventful again

  16. daniel

    see you all next week

  17. moparisthebest

    See you then, thanks

  18. jonas’

    see ya

  19. larma

    Just noticed during the discussion about XEP-0359 (stanza-id): XEP-0313 (MAM) was advanced to stable but depends on XEP-0359 which is still experimental/deferred. This shouldn't be possible. Maybe we should soon issue a last call for XEP-0359 (even though there are discussions about it right now) to fix that situation?

  20. Ge0rG

    Am I going to be hated by everyone if I veto until <origin-id/> is burned out with napalm?

  21. larma

    I'd be fine to get rid of origin-id, but it still has it's usecase (reflection detection in MUCs that don't do the non-RFC-compliant stable-id thing)

  22. Zash

    This is the XSF. You can do anything at the XSF! The the only limit is XEP-0001.

  23. Ge0rG

    larma: how many of those MUCs are still in place [and don't also strip any XML payload besides of <body>, I'm looking at you, biboumi]

  24. larma

    probably not a lot

  25. larma

    that's why I say I'm fine with getting rid of it 😉

  26. tmolitor

    didn't we have some informal consensus / business rule that said that an origin-id and a is on the stanza having the same value (and proper by attribute) means that the client uses something sufficiently random like uuids to generate the id?

  27. tmolitor

    that said, a disco feature indicating that the ids are sufficiently random (128bit of entropy, uuid, whatever) would be a better solution, imho...

  28. larma

    tmolitor, not strictly "sufficiently random" (because that's only recommended by 0359), but it requires them to be a) unique at the sender and b) not predictable - which is hard to achieve without actually using sufficient randomness :)

  29. tmolitor

    yeah...that one :)

  30. tmolitor

    was that written down anywhere?

  31. Zash

    disco is dead, MAM killed it :(

  32. larma

    technically a client could generate a salt at start and then for every outgoing stanza hash that salt together with the nanoseconds since start of the client. That wouldn't be a lot of entropy, but for all practical purposes, this would be as good as a random uuid.

  33. Zash

    There exists a perfect way to generate unique stanza ids

  34. Zash

    (stream-id, counter++)

  35. Zash

    (pass trough hash or HMAC or something)

  36. larma

    tmolitor, well origin-id as per 0359 requires: > the IDs defined in this extension MUST be unique and stable within the scope of the generating XMPP entity. > The values of the 'id' attribute SHOULD be unpredictable. Thus if a client generates an origin-id and puts the same id into the message's id-attribute, you know it's sufficiently random.

  37. tmolitor

    larma: depends on the entropy of the salt ;)

  38. Ge0rG

    All the good clients already use that in stanza IDs, and if you rely on a third party client doing it for your database access or anything, you are in for a tough ride.

  39. larma

    We can also just define a new XEP to define the <good-id /> element that declares that the generation of the message's id-attribute followed certain rules.

  40. Ge0rG

    Which problem does that solve, again?

  41. larma

    some legacy clients generating id's be generating 16 bit of randomness at start and then counting up from that with every stanza and therefor likely running into collisions without bad intent ✎

  42. larma

    some legacy clients generating ids by generating 16 bit of randomness at start and then counting up from that with every stanza and therefor likely running into collisions without bad intent ✏

  43. Ge0rG

    Collisions of what exactly?

  44. daniel

    Anything that references that id

  45. daniel

    Edits. Replies

  46. daniel

    Reactions

  47. larma

    In direct chats only, of course

  48. daniel

    Yes

  49. daniel

    And edits in muc

  50. Ge0rG

    Which only affects the user of the broken client when also using a modern client

  51. Ge0rG

    But the broken client won't generate an adequate ID for referencing anyway

  52. larma

    Yes, and thus the replying/reacting client should not allow the user to send replies/reactions to such message with broken id

  53. Ge0rG

    You need to send a message from pidgin, then edit it from a modern client

  54. Ge0rG

    Disabling a feature because of an opaque thing the user has no visibility of sounds like a bad idea

  55. tmolitor

    +1 for the <good-id/> element

  56. daniel

    > Yes, and thus the replying/reacting client should not allow the user to send replies/reactions to such message with broken id Yes and origin ID is an OK detection for whether or not the other client is same ✎

  57. daniel

    > Yes, and thus the replying/reacting client should not allow the user to send replies/reactions to such message with broken id Yes and origin ID is an OK detection for whether or not the other client is sane ✏

  58. daniel

    Origin ID is essentially good-id

  59. tmolitor

    yes, but with an additional id value that we could get rid of...

  60. daniel

    Why come up with a new element that does the same thing minus muc reflection

  61. daniel

    Then mandate message id==origin id

  62. daniel

    For the sender

  63. Ge0rG

    Are you actually disabling sophisticated features on messages without origin-id?

  64. Ge0rG

    daniel [20:37]: > Then mandate message id==origin id I've been asking for that since day 1

  65. daniel

    Me too

  66. tmolitor

    > Then mandate message id==origin id that would be ideal, what is blocking that?

  67. Ge0rG

    yaxim will generate sufficiently random IDs but not set origin-id

  68. Ge0rG

    tmolitor: the author

  69. tmolitor

    on what basis?

  70. Ge0rG

    It's not technically required

  71. larma

    When I write that "best practices on using IDs" XEP (with how to reference messages depending on context), I'll definitely add that origin-id should be same as message id 🙂

  72. larma

    Not technically requires, but definitely a best practice. ✎

  73. larma

    Not technically required, but definitely a best practice. ✏

  74. larma

    Ge0rG, well, clients already have to limit some features for some messages. Because there exist messages without any id, makign it very hard to reference them 😉

  75. daniel

    I'm gonna block stanza id unless this must is in stanza id

  76. tmolitor

    > I'm gonna block stanza id unless this must is in stanza id wait, what? what id are you referring to exactly?

  77. daniel

    The xep

  78. daniel

    I think the only reason it's not in the xep is that it's slightly complicated to do in smack

  79. larma

    you mean "If the <origin-id /> element is present, the origin sender MUST set the message's id-attribute to the same value as the id-attribute of the <origin-id /> element." should be in XEP-0359? Rather than kicking origin-id out entirely?

  80. Ge0rG

    Can't you just accept any ID with more than four characters and be done?

  81. daniel

    > you mean "If the <origin-id /> element is present, the origin sender MUST set the message's id-attribute to the same value as the id-attribute of the <origin-id /> element." should be in XEP-0359? Rather than kicking origin-id out entirely? If that wording is in 359 it becomes functionally equivalent to <good-id/>

  82. daniel

    We could just remove origin id entirely. But it seems fairly well established for a good-id replacement

  83. Zash

    <good-id/> meaning that <message id=good> ?

  84. Ge0rG

    And you have an excuse to block out perfectly working clients from modern features

  85. daniel

    > <good-id/> meaning that <message id=good> ? Yes

  86. Zash

    Sure would help against my feeling that modern XMPP is full of redundant duplicated IDs and timestamps and also redundancy

  87. Ge0rG

    Zash: also duplicate information

  88. tmolitor

    > I'm gonna block stanza id unless this must is in stanza id +1 for this MUST