XSF Discussion - 2021-01-30


  1. flow

    why don't we have 'archived' notifications, or do we?

  2. MattJ

    flow, what do you mean?

  3. flow

    MattJ, I send you a message, your user MAM archives the message AND sends me a notification that it did

  4. MattJ

    Ah, no

  5. flow

    I wonder if that's a bad or good thing, or sometimes good and sometimes bad

  6. flow

    OTOH I can query your features and assume that the message will probably be archives

  7. MattJ

    Server-sent receipts would be nice

  8. MattJ

    So all a client would need to do is ack with 198, and the server would automatically generate a receipt (instead of potentially multiple devices each sending their own)

  9. mathieui

    flow, that would probably be a bit wasteful in terms of resources, wound’nt it? ("ack-ing" every archived message)

  10. flow

    mathieui, not sure about that

  11. flow

    the sending entities connection is probably still "hot"

  12. mathieui

    True.

  13. mathieui

    But since mam preferences are user-wide, would it not make more sense to advertise it, instead of "every message", have a notification when it’s enabled/disabled for remote entities you are chatting with (probably restricted to roster for privacy reasons)

  14. flow

    mathieui, that would be an option, yes. but then you don't know for sure that the message was archived, and more importantly, that the recipient is able to read it (if using a MAM-enabled client)

  15. flow

    I am also not sure that you can or should announce the mam preferences, plus there could be mam configuration that says "archive all message, but not from user x"

  16. mathieui

    indeed

  17. MattJ

    Well the cheaper option is not to ack every message, but bounce errors in any case where an archivable stanza won't be archived (or immediately delivered)

  18. emus

    Good morning, again the question for volunteers to tweet the translation posts. The tweets are prepared already

  19. mathieui

    I have a question regarding MUC invitations; for private rooms, I assume it makes sense to not rely on XEP-0249 but use mediated instead, so that the room can add people in the member list?

  20. MattJ

    Correct

  21. lovetox

    except mathieui the user you send this invite to has enabled "Ignore all messages from contacts not in my roster"

  22. mathieui

    soo… send the two anyway?

  23. lovetox

    its unsolved

  24. lovetox

    there is no perfect way

  25. lovetox

    but yeah i would go with mediated

  26. lovetox

    sending both could work

  27. lovetox

    yeah why not

  28. lovetox

    but sending direct is only useful if you are admin and can add the user beforhand

  29. lovetox

    actually mediated is the only way that makes sense

  30. lovetox

    what the server should do probably is disco the domain once he sees an invite

  31. lovetox

    find out that its a muc

  32. lovetox

    then proceed to deliver the invite also to people that ignore stuff which is not in their contact list

  33. lovetox

    oh wait, thats not even a server setting

  34. lovetox

    clients implement this on their own

  35. lovetox

    nah i think those people just cant get invites 🤷‍♀️️

  36. jonas’

    also that would open the gate to invite spam which would normally be blocked by ignoring invites from non-contacts :)

  37. mathieui

    yes, although that raises the bar as spammers usually get normal accounts on open IBR servers instead of domains

  38. lovetox

    but clients could do a disco on receiving a invite

  39. lovetox

    and show the user anyway

  40. lovetox

    so yeah use mediated, and clients that implement such options should make it work for mucs

  41. mathieui

    jonas’, though, mediated invites include the JID of the sender, so an additional filter can be used here (only accept if it is from someone in your roster)

  42. mathieui

    at this point bypassing it means it is a very targeted attack

  43. jonas’

    mathieui, which can be forged by a mailicous MUC

  44. mathieui

    yes, but they have to know your roster

  45. mathieui

    though sure, they can say it’s from Link Mauve

  46. jonas’

    for example, yes

  47. Link Mauve

    Why me?! :D

  48. theTedd

    Link Mauve: guilty!

  49. theTedd

    can I get a quick (non-binding) show of intent from everyone for posting tales/talks?

  50. MattJ

    Are we at recorded videos now?

  51. theTedd

    I assumed people could record and post them for group watching on thu-fri

  52. theTedd

    I'm just wondering how are considering doing so

  53. theTedd

    how many

  54. SamWhited

    theTedd: I love the idea, but I'm afraid a week really isn't enough time to prepare a talk even if it is only a 15 minute lightning round. Maybe this weekend if I finish the tasks I need to get done quicker than expected, but this is basically the only time I'll have and we only learned about it yesterday

  55. SamWhited

    I may do a quick summary post of a paragraph or two of what's happened in my various XMPP projects over the last year, that part I'm sure I can find an hour or two to do

  56. theTedd

    I'm aware it was late notice, nothing else seemed to be going on for Summit, so it was more a random idea; I have no problem with moving it to a later date

  57. Zash

    I could, at most, maybe, do a short writeup of stuff I've done. Minimal and outdated experience in video production and giving talks, no chance of refreshing that in a week...

  58. SamWhited

    I'm not sure how long it takes others to prepare something, but for me personally it was definitely short notice. Although I'm not sure anything in my work this past year is talk worthy anyways. Maybe the message Styling stuff, I dunno.

  59. theTedd

    how would 20-21 February suit everyone?

  60. goffi

    theTedd: Hi, same opinion has SamWhited and 20/21 would suit better for me. Is the event supposed to be only for XSF members/XMPP devs, or is it supposed to be open to more general audience? Just to know which audience the talk should target.

  61. theTedd

    I don't see why it should be limited only to members, but I wouldn't assume an entirely novice crowd

  62. theTedd

    some kind of "look what XMPP has to offer" event wouldn't be bad for marketing, but it would have to be a different arrangement to this

  63. SamWhited

    I guess I could do my "Intro to XMPP" talk that I do for lunch-and-learn type things at work sometimes. I haven't given it in a while, and it would probably be completely useless for this crowd, but in a selfish way I might get better feedback on it from this group.

  64. theTedd

    as long as you open with "I know you all know this, I'm looking for feedback (please hurt me)" you should be good

  65. theTedd

    you could take the chance to promote Mellium and the amazing benefits of Go

  66. MattJ

    20-21 sounds good to me. I'm more likely to be able to participate with a bit more notice

  67. MattJ

    I just spent a bunch of time recording my FOSDEM talk this week, it wasn't much fun and I'm not inclined to jump back to recording again right now if I can help it :)

  68. theTedd

    that's understandable

  69. mathieui

    Anyone knows what is the point in having MIX channels in the user’s roster, with no difference at all from other roster items? Since they are only sent to MIX-capable clients, the MIX-PAM part could already do some magic and forward the presence from them without needing roster items, I believe?

  70. mathieui

    (also forces to disco every item because otherwise the roster will be a mess)

  71. Andrzej

    mathieui, it is useful for automatic joining and syncing joined channels between clients

  72. mathieui

    That makes sense, but I wish the items were annotated somehow

  73. Andrzej

    thanks to the roster extensions, client can discover joined channels, users participant id within the channel and us it

  74. Andrzej

    but they are

  75. Andrzej

    but only for MIX capable (or MIX-PAM capable) clients

  76. mathieui

    Hm, that is true in MIX-PAM indeed, I guess I should open a bug report against tigase then

  77. Andrzej

    why? what do you think is incorrect?

  78. mathieui

    Andrzej, my xmpp.cloud test account is not returning any annotations for mix rooms

  79. Andrzej

    do you sent roster query with MIX-PAM annotation?

  80. Andrzej

    do you send roster query with MIX-PAM annotation?

  81. mathieui

    SEND: <iq id="fbb620f617ca4e44a2a146e3d66d8f9c" type="get"><query xmlns="jabber:iq:roster" ver="" /></iq> RECV: …<query xmlns="jabber:iq:roster" ver="6ca9196f751b5c21eafb3c0423bd3e9e">< item name="………" subscription="both" jid="……@mix.xmpp.cloud" /></query>

  82. mathieui

    no, I do not

  83. Andrzej

    then it is correct

  84. Andrzej

    https://xmpp.org/extensions/xep-0405.html#mix-roster-capability-sharing

  85. Andrzej

    > A MIX client MAY request that the server returns this additional information that annotates roster elements with MIX capability. The server MUST return the additional information. The request is made by extending the standard roster get request by adding a child element <annotate/> to the <query/> element. The <annotate/> element is qualified by the ‘urn:xmpp:mix:roster:0' namespace.

  86. mathieui

    That is true, but it seems a bit cumbersome to me, as you cannot simply use your roster query result, but must filter out things with an additional request

  87. mathieui

    I don’t get why it is done like this (as this only concerns MIX-PAM aware clients, no need to care about breaking compatibility by introducing elements in the normal roster query)

  88. Andrzej

    if you ask for a roster with annotations, then you get full roster with annotated items and you can just filter them out

  89. mathieui

    Yes, I’ll do that, thanks