XSF Discussion - 2021-08-09

  1. goffi

    singpolyma's solution for disco feature attachment is far better than my proposal. I plan to update my proposal if it's fine with council members which have already voter in favor of it.

  2. goffi

    (not now cause I'm at work)

  3. goffi


  4. flow

    goffi, do you have a link to singpolyma's solution?

  5. goffi

    flow: last email on standard@

  6. flow

    ha, was in my spam folder :/

  7. goffi

    it's using disco extensions, and that is already included in caps, so I don't see any downside

  8. goffi

    I'll reply later on standard@, I'm at work and will be in meeting soon.

  9. Kev

    I’m not 100% convinced it *is* a better solution.

  10. flow

    Kev, feel free to share why :)

  11. goffi

    Kev: why? Could you elaborate (maybe on standard@ would be better)

  12. flow

    goffi, same goes for you: why do you think this solution than your proposed one?

  13. goffi

    I'll share on standard@, I'm in a meeting now.

  14. flow


  15. goffi

    probably write something tonight, after work.

  16. goffi


  17. flow

    I am myself torn between those two, as they both have their ups and downs

  18. Kev

    I might be completely misunderstanding the problem domain, but these are basically just traditional Disco features as far as I can see, and I’m not sure why the existing mechanism of just checking for the presence of a feature in the list doesn’t work here. Whereas the new proposal involves all consumers having to then do two-level map lookups for no benefit that is immediately obvious to me (although I might be missing it).

  19. flow

    nothing a good API can't hide from the user

  20. Kev

    It seems to me that a consumer wants to know “Can I RSM with Disco” and that the normal approach of looking up the “RSM with Disco” feature works fine, and having to do “First I’ll lookup RSM, and if that’s present I’ll look up the RSM map in the attachments data form and see if that contains Disco” isn’t providing anything but additional complexity.

  21. Kev

    Although as a whole, I’m not entirely convinced this is a standards track XEP, rather than just a suggestion for how other XEPs could do their naming for optional features.

  22. jonas’

    I share singpolymas concern about the opaqueness of the strings though

  23. Kev

    Ah, but these *are* opaque strings.

  24. Kev

    You’re not constructing these things arbitrarily.

  25. Kev

    If ‘pubsub and rsm’ is a valid combination of things, that’s going to be defined in pubsub, rsm, or a pubsub+rsm spec that will be defining the feature.

  26. jonas’

    if they were still opaque, we wouldn't need a XEP to write down how to construct the product of RSM + Disco

  27. Kev

    Which is why I think this should really be little more than a suggestion of how you can name such a feature when you define it.

  28. jonas’

    then it'd be informational I guess

  29. Kev

    And that is unecessary, because they’re opaque.

  30. Kev

    Yes, I agree with that ‘we wouldn’t need’ - I don’t think this is really needed.

  31. jonas’

    unless people really care about the genericity, in which case singpolyma's approach is saner in the sense that it doesn't violate the opacity

  32. Kev

    It feels to me like this is an rsm-specific sticky plaster over rsm being MTI for some specs, but not widely deployed and wanting to advertise after-the-fact who advertises it. But for that, it’d be better to be explicit in the source XEPs.

  33. jonas’

    well, RSM is not MTI for '30

  34. jonas’

    and there's no way to retrofit a feature for RSM into '30

  35. jonas’

    you could add it to RSM itself, sure

  36. emus

    other topic: Any member working at Isode to review and confirm: https://github.com/xsf/xmpp.org/pull/885

  37. flow

    emus: you mean #950, right?

  38. emus

    ups, yes

  39. emus


  40. Kev

    jonas’: right, for disco it’d be in RSM, or in RSM+Disco.

  41. Kev

    I think this is really just a somewhat-bug in 59 that it says ‘just advertise rsm’, and fixing that to say “Individual protocols need to advertise RSM support themselves, unless MTI."

  42. flow

    I am not sure why the discussion about "feature attachments" seems to only revolves around RSM, we have that problem in a few other areas too, notably E2EE

  43. flow

    I am not sure why the discussion about "feature attachments" seems to only revolve around RSM now, we have that problem in a few other areas too, notably E2EE

  44. jonas’


  45. Kev

    What’s the equivalent need in E2EE, flow?

  46. flow

    example: if you announce support for omemo, does that mean that you can also process encrypted chatstates

  47. jonas’

    flow, that would be handled by SCE, not?

  48. flow

    jonas’, I don't think so, no

  49. jonas’

    why not?

  50. flow

    unless you want to imply that implementing omemo means implementing a lot of other additinal protocols

  51. jonas’

    OMEMO does not specify encrypted chat states at all.

  52. flow

    and even then: what about future extensions?

  53. jonas’

    only encrypted body.

  54. jonas’

    so I don't see how a mere OMEMO feature would be related to encrypting non-body content at all.

  55. jonas’

    for anything beyond that, there's stanza content encryption, and that has its own feature, I guess.

  56. flow

    I am not sure if you are guessing right

  57. flow

    due the modularity of XMPP, at the point where you can combine one protocol with another, e.g. MAM+PubSub, or OMEMO+ChatStates, you need a way to announce those as distinct features

  58. goffi

    Kev: flow: you are right with the added complexity, I just find singpolyma cleaner, easier to read, and taking profite of XML. I don't think this can be informal though, as we need to know if the dfa is implemented to know if a missing 'http://jabber.org/protocol/rsm@http://jabber.org/protocol/pubsub' means that the RSM is not implemented for pubsub, or just that dfa is not implemented.

  59. goffi

    also it's useful for other XEPs, order-by for instance.

  60. goffi

    Ok my meeting is resuming.

  61. Kev

    I didn’t say informal, I said it needs to be specified in the respective XEPs.

  62. MattJ

    I'm inclined to agree

  63. MattJ

    Otherwise you could advertise interesting combinations of features without it being clearly specified what that means

  64. Kev


  65. MattJ

    If you say you support RSM for MUC, how does that function exactly?

  66. Kev

    Poorly :D

  67. MattJ

    313 has semantics around the use of RSM, such as saying the RSM IDs match the archive IDs

  68. MattJ

    And I think this will apply to most things

  69. Kev

    313 also has (or rather, used to have and is split off) semantics around 313 with 60.

  70. Kev

    You also couldn’t just advertise omemo+csn and expect it to work usefully without arbitrary element OMEMO being defined.

  71. MattJ


  72. MattJ

    So I agree that either RSM support is declared mandatory by the source XEP (if you advertise MAM support, you *must* support RSM), or you need to document it somewhere else if it's optional

  73. Kev

    Or not somewhere else, even if it’s optional.

  74. Kev

    Which I *think* is what you meant.

  75. MattJ

    You can't just combine arbitrary features and expect everyone to understand what that means

  76. jonas’

    all very reasonable

  77. Kev


  78. MattJ

    Er, sure, it can be optional in a protocol indeed

  79. goffi

    sure nothing prevent to explain it directly in concerned XEPs, I did it in last version of https://xmpp.org/extensions/xep-0413.html#disco . But that means that you have to repeat each time how to produce the disco feature string, instead of just linking to a XEP, and also that we have to update all concerned XEPs, and for some of them we can't bump version, so how do we know if the feature is implemented or not? With dfa, you can just say "this feature can be attached as of XEP-xxx (dfa)", and if necessary explain what that means.

  80. jonas’


  81. jonas’

    there is no way to produce an opaque string

  82. flow

    I think everyone aggrees that the combination of two protocol extensions need to be declared and specified somewhere (even if it is trivial)

  83. flow

    I think everyone agrees that the combination of two protocol extensions need to be declared and specified somewhere (even if it is trivial)

  84. Kev

    > there is no way to produce an opaque string Right.