XSF Discussion - 2018-09-13

  1. peter

    beautiful :(

  2. peter


  3. edhelas

    is there people going to the 35c3 this year ?

  4. Link Mauve


  5. edhelas

    nice :) would it be possible to get early tickets by the XSF folks ?

  6. Yagiza


  7. Seve/SouL

    Haven't checked when is it (and also never been there)

  8. Yagiza

    First test release of eyeCU with my Jingle RTP Sessions implementation is out.

  9. Yagiza

    Windows build only so far. No installer - just a ZIP archive. Anyone wish to test it?

  10. Link Mauve

    Yagiza, does it run in Wine?

  11. Yagiza

    Link Mauve, I don't know. It uses Qt5 for MSVC12 and FFMpeg libraries for Windows.

  12. Yagiza

    Link Mauve, never tried to run it with Wine.

  13. Link Mauve

    I didn’t manage to finish to build it the other day btw, I couldn’t find any mention of qputil or qpdns.

  14. Link Mauve

    Where does it come from?

  15. Yagiza

    Link Mauve, those libraries are from QtPurple framework.

  16. Yagiza

    Here's the link for those, who want to test: http://eyecu.ru/download/eyecu2-test.zip

  17. Yagiza

    It shoul run on Windows'XP and newer.

  18. Yagiza

    If my implementation of XEP-0166, XEP-0167, XEP-0176, XEP-0177 and XEP-0266 is wrong or incorrect, please, let me know.

  19. Link Mauve

    Yagiza, have you done any interoperability testing with other clients, such as Gajim (0.16, not 1.0), Pidgin or Psi?

  20. Link Mauve

    Or Empathy.

  21. Yagiza

    Link Mauve, not yet. It was just released and I didn't even tested connectivity outside of my own flat.

  22. Link Mauve

    Ok. :)

  23. Yagiza

    Link Mauve, so, I'm looking for testers.

  24. Link Mauve

    Yagiza, is https://github.com/gatlin/QPurple the most up to date QPurple project? There hasn’t been a single commit in five years. :/

  25. Yagiza

    Link Mauve, I guess, no. QtPurple is a different project from Purple Soft.

  26. pep.

    edhelas: it would be nice to get early tickets indeed. I think mathieui did it last year? Just send an email asking for it?

  27. MattJ

    daniel, does Conversations do XEP-0333 in MUC? And does it just sync all messages even if I'm offline for 2 months?

  28. MattJ

    Seems many clients are struggling with long MAM sync times, especially in busy MUCs after being offline for some time

  29. MattJ

    With no way to know which messages you want or don't want from that history

  30. daniel

    MattJ: I'm adding a jid attribute to the response

  31. Ge0rG

    MattJ: do you have principal suggestions on how to solve the offline-for-some-time problem?

  32. MattJ

    Ge0rG, once I do, I'll let you know

  33. MattJ

    I'm in research mode right now

  34. daniel

    No. Max catchup is a week or so

  35. daniel

    I don't have anything clever to fill the gaps

  36. daniel

    > MattJ: I'm adding a jid attribute to the response Which I have been meaning to write down

  37. MattJ

    daniel, to which response?

  38. daniel

    It's `<displayed id='123' jid='room@service/MattJ' />`

  39. daniel

    Might be `by` instead of jid

  40. daniel

    But the idea is the same

  41. MattJ

    and you send that to the bare JID of the MUC?

  42. daniel


  43. MattJ

    That's very helpful, thanks

  44. daniel

    I mean it's unique since only the time of writing counts right

  45. daniel

    So you don't have to worry about changing nicks

  46. daniel

    Lol locking at my code it's actually called 'sender'

  47. daniel

    MattJ: but that's essentially what I was trying to tell you at the developers Meetup. That's how you can solve the attachment / references problem as well

  48. MattJ

    Well, MattJ could leave the room, someone takes his nick and then sends another message with id='123'

  49. daniel

    oh. that’s true. i hadn’t considered yet.

  50. MattJ

    Also I'm pondering rewriting ids in MUCs anyway (yes, yes, I know...)

  51. MattJ

    The sender's id would still be reflected back to them, as XEP-0045 now requires

  52. MattJ

    But I guess this would break XEP-0333 from the perspective of everyone else in the room

  53. MattJ

    Unless the MUC also mapped those... ick

  54. daniel

    MattJ: well not with my fancy client id fall back

  55. MattJ

    I'm quite behind "id attribute and origin-id should be set the same"

  56. MattJ

    It makes it clear that origin-id can always be used as a fallback in these kinds of cases

  57. Ge0rG

    daniel: "my fancy client id fall back" is exactly what I'd like to avoid all client developers having to get right

  58. MattJ

    The problem for MUC is that the id attribute is the only way to track delivery errors to occupants

  59. Ge0rG

    daniel: I remember you being strongly opposed to the "fancy client-side self-ping" solution not too long ago.

  60. MattJ

    so if it can't guarantee that those ids are unique, it can't handle delivery failures properly

  61. daniel

    Ge0rG: yeah but because of the resources. Not because it's complicated

  62. Ge0rG

    MattJ: you could reject incoming messages with duplicate IDs :P

  63. daniel

    Origin ID doesn't consume resources

  64. Zash

    So what we should do is to have the MUC produce its own IDs!!!

  65. MattJ

    Zash, that's what I was thinking, of course :)

  66. MattJ

    Also, on another MUC-related note...

  67. MattJ

    I'm considering sending <presence type="unavailable"/> from unavailable affiliated occupants when you join

  68. Ge0rG

    MattJ: what problem do you want to solve? additional IQs to obtain affiliation/admin lists?

  69. MattJ

    It seems a more natural way to do it than the iq method, yes

  70. MattJ

    and although the XEP allows fetching the member list, it doesn't allow fetching admins/owners

  71. MattJ

    Which would leak JIDs in semi-anon rooms anyway

  72. MattJ

    the presence would always work

  73. daniel

    But what do you put as nick then?

  74. Ge0rG

    except you'd need clients to rely on the presence push to not query affiliation

  75. daniel

    =resource. You know what I mean

  76. Ge0rG

    Just leave it empty. It worked well enough for avatars 😁

  77. MattJ

    daniel, Prosody is now storing nicks with affiliations

  78. daniel

    Ge0rG: yeah but if the room is anon then it's essentially no information at all

  79. daniel

    If you have an empty presence w/o jid in the x and resource

  80. Ge0rG

    Use the room JID and let the client figure out all the <x> stuffed in there ;)

  81. MattJ

    No, this would come from the occupant JID, on the assumption that Prosody knows the nick associated with the affiliation

  82. MattJ

    This is already in XEP-0045, and there is already a config option in the XEP for toggling whether to include these presence stanzas

  83. daniel

    What option?

  84. MattJ

    daniel, I take it back, it's not a config option, it's a status code

  85. MattJ

    <statuscode> <number>102</number> <stanza>message</stanza> <context>Configuration change</context> <purpose> Inform occupants that room now shows unavailable members </purpose> </statuscode>

  86. MattJ

    I thought there was a corresponding option, but I can't see it right now with Ctrl+F at least

  87. daniel

    45 is full of surprises

  88. MattJ

    Yes, this was a fun find

  89. Ge0rG

    The most surprising things of 45 are the ones *not* written in the XEP.

  90. nyco


  91. MattJ


  92. MattJ

    ralphm, Guus

  93. Guus

    MattJ, I'm unavailable as announced

  94. Guus

    Can maybe lurk at best

  95. MattJ

    Oh, sorry

  96. Guus


  97. MattJ

    I propose we skip then

  98. MattJ

    Has anyone heard from ralphm?

  99. nyco

    ah right, thx for the reminder, so no quorum...

  100. nyco


  101. MattJ


  102. Guus

    MattJ: not me

  103. nyco

    not me

  104. nyco


  105. ralphm

    I am still alive

  106. ralphm

    But overloaded with work meetings

  107. MattJ

    ralphm, ok, glad you're ok :)

  108. nyco


  109. nyco

    so let's overload him even more!

  110. ralphm

    Next week should be better. 🤞

  111. Guus

    Famous last words