jdev - 2023-03-19


  1. pep.

    singpolyma, poking here as you're not in movim@, I'm curious what's the use for 0033 in Movim.

  2. pep.

    Or this isn't MUC-related at all?

  3. pep.

    Just some unspecced-group thing?

  4. singpolyma

    It could be used in MUC, though it's more common to just put the jid in presence and make the client look it up that way. We do use it outside of MUC context as well yes

  5. singpolyma

    For the email and MMS bridges (MMS is just email anyway so these are similar)

  6. nicoco

    Is this correct? (not a quizz, just want to make sure I get it right ^^) > I am a pubsub server; I should keep track of which event I've sent to which entity. When an entity comes online, I should only send them events that I haven't sent them previously. Related question: how bad is it if I send all my pubsub events everytime an entity comes online, not keeping track of whether I've already sent them the same event? (in practice, this is about PEP avatars (metadata) and nicknames)

  7. MattJ

    Only send the last published item

  8. MattJ

    https://xmpp.org/extensions/xep-0163.html#notify-when

  9. MattJ

    See those two sections

  10. nicoco

    the last item, no matter if I've already sent it before? xxx@xxx/dinoYY comes online 50 times in a row, I sent the pep nickname 50 times, that's OK? I guess this makes sense because I have no guarantee that dinoYY is actually the same client, and also it may have cleared its local cache between two "getting online" events.

  11. nicoco

    the last item, no matter if I've already sent it before? xxx@xxx/dinoYY comes online 50 times in a row, I sens the pep nickname 50 times, that's OK? I guess this makes sense because I have no guarantee that dinoYY is actually the same client, and also it may have cleared its local cache between two "getting online" events.

  12. MattJ

    Yes, you send it anyway

  13. MattJ

    https://xmpp.org/extensions/xep-0312.html is an optimization for that, but nobody uses it

  14. nicoco

    Thanks MattJ, I think this the section I needed to read indeed. XEP-0312 is the type of optimisation I feared was part of pubsub or pep. Cool! Less keeping track of stuff, and easier to comply to the spec than I feared :)

  15. MattJ

    :)

  16. pep.

    singpolyma, could be used in MUC but server/component-side, no?

  17. singpolyma

    You mean it would need component support? Yes

  18. pep.

    I mean the benefits of 0033 to me are the possibility to send one instead of multiple payloads

  19. pep.

    Movim doesn't need to be exposed to 033 at all

  20. singpolyma

    0033 always has a server and a client component

  21. singpolyma

    The client sees who the other recipients of the message are and what the ofrom/replyto/replyroom etc addresses are

  22. singpolyma

    Very similar to SMTP, which is why it maps so well for SMTP and MMS gateways

  23. pep.

    hmm ok that's not what I had in mind for MUC usage. I would have had the component put 0033 for users on the same server and have the server split it

  24. pep.

    Which is why I was confused

  25. singpolyma

    Yes, sure, that is the server part

  26. pep.

    Well this doesn't require client support

  27. singpolyma

    But the client still gets the context of who the stanza was delivered to

  28. pep.

    Which client

  29. Zash

    ones understanding '33

  30. singpolyma

    It doesn't require it if your client UX doesn't care about any of the other addresses sure

  31. pep.

    singpolyma, well in MUC "it knows" already

  32. singpolyma

    Sure, in MUC mostly the client would only care about ofrom or replyto stuff likely

  33. singpolyma

    But this is down to the UX of the client dev

  34. pep.

    Yes. Actually disclosing who else on their server is receiving the message is probably some kind of leak

  35. singpolyma

    You mean if you used 0033 for groupchat from semianon? Yeah, that wouldn't work

  36. pep.

    Well yes it would, for the use-case I said. Just that the component needs to ensure server support

  37. pep.

    The client never needs to know 0033 was used

  38. singpolyma

    It would not because it would leak, as you say

  39. pep.

    I also said the server would split it

  40. singpolyma

    Unless you write an extension to 0033 to tell the server not to pass the 0033 payload along

  41. pep.

    Send one message from the MUC to serverX, deliver 10 messages to serverX users

  42. pep.

    Yes this

  43. singpolyma

    Sure, that's something new then

  44. pep.

    You may have said it in what you just said, but I still don't understand the other use-cases

  45. pep.

    SMS/MMS ok but that's because there's no protocol support so it's just informational I guess

  46. singpolyma

    So, for example, the one I have in my movim PR is just ofrom. That is to say, "this is the jid that really sent this message, I'm just a relay"

  47. pep.

    The original JID being.. +0123456789@gateway?

  48. singpolyma

    For an MMS case, yes. Or for SMTP email\40server@gateway

  49. pep.

    Actually my use-case for optimizing MUC traffic is already specified, with @type='bcc'

  50. singpolyma

    Or in a MUC case the true jid of the sender. Etc etc

  51. singpolyma

    pep.: oh right, I forgot BCC was speccd

  52. pep.

    Why would one leak their own JID voluntarily in a MUC

  53. singpolyma

    It would be a non-anon MUC obviously

  54. pep.

    So duplicating info given by MUC?

  55. singpolyma

    Or, probably. I mean, I always want my JID attached. I would leak in semi anon if it was a option

  56. Zash

    small private group chat without a MUC component

  57. singpolyma

    The info would be given by the MUC I would assume. It's just not the timeline we ended up in and we use presence for that instead of 0033

  58. pep.

    Zash, yeah, but that's not MUC

  59. pep.

    And yeah that's a use-case

  60. singpolyma

    Zash: sure, that's a possible use case but needs more than ofrom

  61. pep.

    Does prosody support 0033 cc?

  62. pep.

    Does prosody support 0033 bcc?

  63. singpolyma

    There's a community mod iirc

  64. Zash

    https://modules.prosody.im/xeps.html#xep0033

  65. pep.

    Ok

  66. pep.

    https://hg.prosody.im/prosody-modules/file/f66a08f208ad/mod_addressing/mod_addressing.lua "-- IQ stanzas makes no sense" why?

  67. pep.

    You can still split the stanza at the server level

  68. pep.

    You've gained multiple stanza over one stream (component->server)

  69. Zash

    No, does not make sense

  70. Zash

    Multiple child tags of iq are illegal. Only one request and one response is allowed.

  71. pep.

    hmm

  72. pep.

    That's meh

  73. Zash

    '33 violates symmetry enough as it is

  74. singpolyma

    0033 for iq I'm not sure how replies would work. All with the same I'd?

  75. singpolyma

    0033 for iq I'm not sure how replies would work. All with the same ID?

  76. pep.

    singpolyma, 0033 would have been stripped so the recipient would just sent to the original sender, the MUC

  77. pep.

    But yeah I forgot the one-child constraint of iq

  78. pep.

    send*

  79. Zash

    singpolyma, how do *errors* work with 33?

  80. singpolyma

    Zash: from the client you mean?

  81. pep.

    I'm not sure what's so complicated. 0033 is just an optimisation over one or multiple streams no? :/

  82. Zash

    one of the CC's bounce. ????

  83. singpolyma

    > one of the CC's bounce. ???? Would be the same as a normal non 33 . message

  84. singpolyma

    from is the sender not the relay

  85. singpolyma

    Send error back to them directly

  86. Zash

    wait are you talking about using 33 to optimize 45?

  87. singpolyma

    pep. is

  88. Zash

    missed that