XMPP Council - 2024-06-18

  1. larma

    if it's unique to the user, if a user has multiple clients, both clients should use the same string, otherwise they will look like different users, no?

  2. singpolyma

    Only the user's only client uses this string. You never generate an id for anyone but yourself

  3. singpolyma

    Oh I see what you're saying. Hmm

  4. singpolyma

    Maybe you're right. I wonder that they haven't thought of this for the main spec but I guess it's because they only have one implementor on their protocol. Ok, I will think more about this and probably add a line to spec this. Thanks for your patience in explaining

  5. larma

    I guess they just put the users email address. I actually think they once had that in the spec to put the email address there (which is why it's called selfAddr)

  6. singpolyma

    yes, it used to say to put the email address, and then when I came in they changed it to what it says now, but I think they also were considering to do some kind of per-widget id for anonimity (though this seems not needed since the widgets can only communicate with other people who already know your id anyway...)

  7. moparisthebest

    Not in a muc?

  8. singpolyma

    moparisthebest: in a muc the others still know your in-muc id

  9. singpolyma

    anyway I've talked to them about it and despite the wording they are indeed still just using email address. I'll add a section about this

  10. moparisthebest

    Ah yes, different jid though

  11. daniel

    It's time

  12. daniel

    1) roll call

  13. dan.caseley


  14. moparisthebest


  15. larma


  16. daniel

    1) Roll call

  17. daniel

    It’s time

  18. daniel


  19. daniel

    singpolyma, larma?

  20. daniel

    disregard the two roll calls. my dino got disconnected and resend those after a restart

  21. daniel

    2) Agenda bashing

  22. daniel

    any changes to the agenda?

  23. daniel

    I assume not

  24. daniel

    3) Editors update

  25. daniel

    * Proposed XMPP Extension: Chat notification settings (https://xmpp.org/extensions/inbox/notification-filter.html) note that this has already been updated to 0.0.2 after list feedback * Proposed XMPP Extension: WebXDC (https://xmpp.org/extensions/inbox/webxdc.html)

  26. daniel

    4) Items for voting

  27. daniel

    a) Proposed XMPP Extension: Chat notification settings (https://xmpp.org/extensions/inbox/notification-filter.html)

  28. daniel


  29. larma


  30. dan.caseley


  31. moparisthebest

    Concerns me a bit the MUST NOT seems likely to be deleted by existing things that don't yet implement this... But +1

  32. daniel

    b) Proposed XMPP Extension: WebXDC (https://xmpp.org/extensions/inbox/webxdc.html)

  33. daniel


  34. dan.caseley

    There's definitely missing stuff too. I don't know how a client or server could complete a full implementation from this XEP, but it's certainly interesting enough to proceed.

  35. daniel

    moparisthebest, it's in the extensions block and extensions should be kept, no?

  36. larma


  37. moparisthebest

    +1 though I'd like security considerations to link specific things, ideally maintained on webxdc, but otherwise we can enumerate them, the awful 9999 webrtc hack comes to mind

  38. larma

    For notify settings, I wonder if in the end we might want to have an iptables-like rule system, because now it's unclear to me how different rule elements and advanced elements interact, and what happens if they're conflicting

  39. moparisthebest

    > moparisthebest, it's in the extensions block and extensions should be kept, no? I guess... The "such as extensions" is pretty vague :/

  40. daniel

    dan.caseley, do you want to cast your vote now? or are you on list?

  41. singpolyma


  42. dan.caseley

    +1 I don't like WebXDC as a concept. Something icky in the 'executable through chat'. But I don't think my taste is a reasonable objection :)

  43. singpolyma

    I'm a bit concerned that https://xmpp.org/extensions/inbox/notification-filter.html has no implementation attempts yet and contains things which don't directly apply to obvious cases (such as 1:1) chats

  44. daniel

    yeah i don’t like it either. but better to have it standardized for clients that do want to use it

  45. daniel

    c) XEP-0045: Add punctuation to improve readability (https://github.com/xsf/xeps/pull/1344)

  46. larma

    Yeah, security considerations of webxdc spec definitely needs some updating before it can move forward, but good enough for now

  47. daniel

    i think this is editorial but I wanted to run this by you anyway

  48. daniel


  49. singpolyma

    WebXDC: +1 from me obviously :)

  50. moparisthebest

    The no implementations I'm not a fan of either but not blockable for me

  51. dan.caseley

    +1 for Guus' weeks of hard labour

  52. singpolyma

    0045 punctuation: +1

  53. larma

    +1 on c)

  54. moparisthebest

    +1 on c)

  55. daniel

    d) XEP-0153: Add missing EMAIL/USERID element in example (https://github.com/xsf/xeps/pull/1348)

  56. daniel

    on list

  57. singpolyma

    d) +1

  58. dan.caseley


  59. moparisthebest

    Hmm yea on-list, wonder what implementations do...

  60. Kev

    It's an example in 153, not in 54, FWIW.

  61. Kev

    The examples in 54 are correct, AFAICS.

  62. larma

    d) +1

  63. larma

    what Kev said πŸ™‚

  64. Kev

    So it's 153 giving an example of 54 protocol and getting it wrong. This feels safe to me :)

  65. daniel

    yes I’m +1 too. used the last 3 minutes to verify that :-)

  66. daniel

    5) Pending votes

  67. daniel


  68. daniel

    6) Date of Next

  69. daniel

    +1w wfm

  70. singpolyma

    +1w wfm

  71. dan.caseley

    +1w wfm

  72. moparisthebest

    I'll trust you all I'm +1 on d) then too :)

  73. moparisthebest

    +1w wfm

  74. daniel

    7) AOB

  75. moparisthebest

    None here

  76. dan.caseley


  77. daniel

    8) Close

  78. daniel

    Thank you all. See you next week

  79. moparisthebest

    Thanks daniel and all!

  80. dan.caseley

    Thanks all πŸ‘‹