XSF Discussion - 2024-03-11


  1. nicoco

    Hi all! `<received/>` is deprecated "to not replicate functionality". What XEP should we use for "receipts" in MUCs then? My understand was that `<received />` was the 0184 of MUCs?

  2. flow

    I'd rather we fix the specification than pretending that parts of it didn't exist ;)

  3. nicoco

    flow: I must be missing context because I don't get your remark :)

  4. nicoco

    Let me phrase my question differently: what is the way for clients to notify that they have effectively received a message in a MUC? AFAIK Monal and Beagle do send xep-0333's `<received />`, and for a few networks where it makes senses, slidge does bridge `<received />` markers in MUCs too (both ways). Do we consider that we don't want this mecanism anymore, or did I miss the XEP that replicates this functionality?

  5. Daniel

    nicoco: what's the argument against 184 in muc?

  6. flow

    nicoco, oh, sorry if this confused you. it was a response to an comment from yesterday evening,

  7. nicoco

    Daniel: https://xmpp.org/extensions/xep-0184.html#when-groupchat > It is NOT RECOMMENDED to request a receipt when sending a content message of type "groupchat" in a Multi-User Chat (XEP-0045)

  8. nicoco

    I guess NOT RECOMMENDED means "do it if you think it's good for you" :)

  9. nicoco

    flow: haha, ok I'm not losing my mind then xD

  10. flow

    but I feel like we are about to enter a situation where my comment also applies

  11. flow

    nicoco, let me know if you need a spare one anyways :)

  12. nicoco

    The reason I'm asking is because I'd like to keep slidge as compliant as possible, so I guess I need to ditch those received markers and instead request and send XEP-0184 receipts in MUCs too when the bridged network has an equivalent feature?

  13. Daniel

    nicoco: I guess I agree with that sentiment in that delivery receipts can create a lot of (arguably) unnecessary traffic in group chats. But that goes for both 333 and 184. If you think it's necessary to do them (maybe in small groups) I guess you can ignore that and use 184

  14. Daniel

    > The reason I'm asking is because I'd like to keep slidge as compliant as possible, so I guess I need to ditch those received markers and instead request and send XEP-0184 receipts in MUCs too when the bridged network has an equivalent feature? nicoco: out of curiosity did you use the 'up to' feature of 333 or did you use them on a per message basis (the same way you would use 184 but different syntax)

  15. Daniel

    Because what I found is that the implementations that use 333 receipts use them exactly as they would use 184

  16. Daniel

    Meaning not with up to

  17. nicoco

    FWIW it seems most walled gardens solved the unnecessary traffic issue by emitting received/displayed markers directly to the sender, which means in practice you can only tell if *your* messages have been received and/or displayed.

  18. Zash

    It would be interesting to do some kind of thing in the MUC side that broadcasts receipts and then sends a single receipt back to the original sender

  19. Daniel

    Oh interesting. I think for 'displayed' that actually bad / a missing feature

  20. Daniel

    For received I guess maybe...

  21. Zash

    It would be interesting to do some kind of thing in the MUC side that broadcasts receipt *requests* and then sends a single receipt back to the original sender

  22. nicoco

    > did you use them on a per message basis If the bridged network official clients work on a per message basis, slidge acts as close as possible, meaning slidge does keep a list of unread message IDs so that when the XMPP client says "I've read up to X" slidge sends "legacy markers" for all the stored message IDs before this one.

  23. nicoco

    For legacy to XMPP, if the legacy network sends markers for each message, slidge bridge them all to XMPP too. Taking advantage of the "up to" functionality certainly is a possible optimisation in this case, and I hope slidge gets big enough so that this optimisation actually does something tangible - we're far from this point. :D

  24. Daniel

    I see. Yes as argued in the design considerations of the disaplyed marker xep I think that for reliability tracking (and that's what receipts are) I think per message is the right choice. And that's fully covered by 184

  25. nicoco

    > Oh interesting. I think for 'displayed' that actually bad / a missing feature Agreed! XMPP rules ;)

  26. nicoco

    Daniel: I understand, it does make sense, thanks for the details

  27. Daniel

    how often is https://xmpp.org/extensions/ being updated? can I trigger that somehow?

  28. jonas’

    back then it needed a rebuild of the website

  29. edhelas

    Stop spamming my inbox wih all those XEPs changes !

  30. edhelas

    (just kidding, thanks for the work :) ! )

  31. Daniel

    I'm currently holding back a few Last Calls because I don't want to overwhelme people. My plan is to schedule them at a rate of two per week

  32. cal0pteryx

    > how often is https://xmpp.org/extensions/ being updated? can I trigger that somehow? Build is broken at the moment. I'm fixing it this afternoon

  33. cal0pteryx

    Build happens every hour if it works as intended ;)

  34. Squeaky Latex Folf

    https://ieeexplore.ieee.org/abstract/document/9824745/ Is anyone here aware of this publication?

  35. Squeaky Latex Folf

    What is this? Why is it paywalled? How is this not on libgen yet?

  36. Squeaky Latex Folf

    I've never seen a paywalled XEP yet

  37. Squeaky Latex Folf

    I was just looking if XMPP PubSub can do implicit multicast routing where the server sends message stanza to other server without specifying specific users inside the stanza, but the remote server is able to figure out who to send the stanza to on its own, considering that it knows who's subscribed to the pubsub node

  38. Squeaky Latex Folf

    This IEEE publication seems like it might address this, however it's fricking paywalled???

  39. Squeaky Latex Folf

    Like whaaaat?

  40. jonas’

    can't stop people from publishing paywalled stuff unfortunately

  41. Squeaky Latex Folf

    Anyone know if what I'm looking already exists and is a free extension?

  42. Squeaky Latex Folf

    Anyone know if what I'm looking for already exists and is a free extension?

  43. jonas’

    I haven't yet fully understood the requirements I think

  44. jonas’

    but I question that a server "knows" who's subscribed to a remote(!) pubsub node

  45. jonas’

    that would require inspecting outgoing IQ stanzas to a rather deep level, which is generally not done

  46. Squeaky Latex Folf

    Servers don't know?

  47. Squeaky Latex Folf

    I thought they did

  48. jonas’

    they don't need that information generally

  49. Squeaky Latex Folf

    Well if they do know it, it could save a LOT of traffic

  50. jonas’

    [citation needed]

  51. jonas’

    (how much traffic? with which usage patterns?)

  52. Squeaky Latex Folf

    Multiple unicast vs multicast

  53. jonas’

    right, but how often does it actually occur that multiple users from the same server are subscribed to the same remote pubsub node?

  54. jonas’

    if subscribers aren't on the same server, there's nothing to gain.

  55. Squeaky Latex Folf

    Hmm fair

  56. Squeaky Latex Folf

    https://xmpp.org/extensions/xep-0253.html

  57. Squeaky Latex Folf

    Just found this

  58. jonas’

    ah, I was looking for that but too dumb to filter correctly on xmpp.org

  59. singpolyma

    multiple unicast is also a privacy nightmare, unless the pubsub node is fully public with every item being public and the same for all subscribers, your server will be capable of accidentally exposing to someone at least in case of a bug

  60. singpolyma

    vs not where your server is a dumb pipe and the permissions live with the pubsub node

  61. singpolyma

    vs nwt where your server is a dumb pipe and the permissions live with the pubsub node

  62. singpolyma

    vs now where your server is a dumb pipe and the permissions live with the pubsub node

  63. Squeaky Latex Folf

    I'm not really sure what you mean

  64. singpolyma

    If my server "knows" who is subscribed to a node, and distributes locally based on that knowledge, then if my server is ever wrong it could send someone content they are not allowed to see

  65. Squeaky Latex Folf

    Then you meant s/multiple unicast/multicast/ you dingus :P

  66. singpolyma

    apologies. I just got out of bed

  67. MattJ

    Squeaky Latex Folf, without the name calling please

  68. Squeaky Latex Folf

    Sorry, is dingus an offensive word?

  69. Squeaky Latex Folf

    I thought it was more playful

  70. Squeaky Latex Folf

    I thought it was more playful and silly

  71. singpolyma

    Squeaky Latex Folf: I did not take offense, but this is a multilingual chatroom with people from many cultures and backgrounds, so someone easily could. Best to be careful

  72. MattJ

    It depends on the context, if it's someone you are friendly with then of course playful/silly can be okay, but it's generally not a good idea to extend that kind of communication to others outside of immediate social relationships

  73. cal0pteryx

    > how often is https://xmpp.org/extensions/ being updated? can I trigger that somehow? Daniel, should be up to date now

  74. cal0pteryx

    Last website build is now printed in the footer as well

  75. Daniel

    cal0pteryx, looks like it. thank you