XSF Discussion - 2018-06-01


  1. Steve Kille

    I sent an email reply to the list.

  2. Steve Kille

    Agree that option 3 is the worst choice.

  3. Steve Kille

    Jonas has convinced me that we should stick with option1.

  4. edhelas

    Dave Cridland hi :)

  5. Ge0rG

    It looks like the #1 reason for CSI/push waking up my iFruit device is IQs from different contacts

  6. daniel

    Oh yeah. Answering boring IQ or holding them back is something csi is currently really missing out on

  7. daniel

    That's like the number one reason my phone wakes up as well

  8. jonasw

    which IQs are those typically?

  9. Zash

    And can we cache them on the server?

  10. daniel

    Disco probably

  11. Zash

    Disco can definitively be cached

  12. Ge0rG

    Jun 01 14:16:17 c2s56530a2a26a0 debug #queue = 40 Jun 01 14:16:17 c2s56530a2a26a0 debug hibernating, stanza queued Jun 01 14:16:17 c2s56530a2a26a0 debug Invoking cloud handle_notify_request() for smacks queued stanza Jun 01 14:16:17 yax.im:cloud_notify debug Sending push notification for georg@yax.im to push.monal.im (7D87E8CC-0C18-4579-A69C-6C513BF921FB)

  13. Ge0rG

    Hm. No idea what that was

  14. jonasw

    Kev, so, in variant 2, when sending a message to an occupant (<channel>@<service>/<user id>), that would not be carbon-copied or archived under XMPP 2.0 rules, right?(

  15. jonasw

    because the recipient is a full JID

  16. jonasw

    this is a super-messy complex design space

  17. Ge0rG

    It's also great how prosody marks CSI as active when a session gets hibernated.

  18. Ge0rG

    So immediately _after_ hibernation, the CSI queue is flushed and the device is woken up via push

  19. MattJ

    Ge0rG, it hurts when you say "Prosody"

  20. MattJ

    It's a community module not maintained by us, fork it

  21. Ge0rG

    MattJ: It's also sad how prosody doesn't support any of the features needed for a battery-friendly not-message-losing mobile experience.

  22. Ge0rG

    Does that sound better now?

  23. MattJ

    That one I'll take on the chin

  24. Ge0rG

    MattJ: I can understand that you don't want to feel responsible to the messy code that just happens to be hosted on your infrastructure, but from a server admin point of view, that distinction doesn't make much sense.

  25. Ge0rG

    Even mod_firewall is merely a community module.

  26. Zash

    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, etc

  27. moparisthebest

    BUT USERS WILL COMPLAIN

  28. jonasw

    that’s software vendors "HATERS WILL HATE"?

  29. jonasw

    that’s software vendors’ "HATERS WILL HATE"?

  30. Zash

    Humans gonna human

  31. Ge0rG

    Okay, being in a dozen of MUCs and having a hundred of contacts actually means: 182 wake-ups per hour due to <r/> requests 130 wake-ups per hour due to <iq> 65 wake-ups per hour due to messages 13 "wake-ups" per hour due to responding to <r/> from the client

  32. Zash

    I have zero wake-ups per hour due to <r/>

  33. Ge0rG

    Not using smacks? :P

  34. Zash

    Nope

  35. Zash

    CSI + MAM

  36. MattJ

    Ge0rG, FWIW prosody-modules was originally intentionally not hosted on our infrastructure

  37. MattJ

    However Google Code shut down

  38. Ge0rG

    MattJ: yes, it was a huge hit to many OSS projects.

  39. Ge0rG

    Oh, yes. It looks like most of the IQ traffic is disco#info indeed.

  40. jonasw

    Ge0rG, you might wanna try that thing Link Mauve did

  41. Ge0rG

    jonasw: ah, that thing Link Mauve did. Right.

  42. Ge0rG

    What are you talking about? 🤔

  43. jonasw

    which answers on behalf of the client

  44. Zash

    The Thing™

  45. jonasw

    for disco#info if they publish caps

  46. Zash

    jonasw: disco#info cache?

  47. Ge0rG

    MattJ: my intention really isn't to assign blame to anyone, all I wish for is to have a better server so that my father-in-law can finally receive my messages.

  48. Link Mauve

    Oh, I also want that, for all of my users.

  49. Ge0rG

    Link Mauve: for your users to receive your messages? Thought about writing a blog? :P

  50. Ge0rG

    Link Mauve: where can I find The Thing™?

  51. Link Mauve

    Ge0rG, https://modules.prosody.im/ and search for "caps".

  52. Ge0rG

    Link Mauve: https://modules.prosody.im/mod_cache_c2s_caps.html ?

  53. MattJ

    Ge0rG: that's my intention also, believe me

  54. Link Mauve

    And this one to actually do something: https://modules.prosody.im/mod_auto_answer_disco_info.html

  55. Ge0rG

    Link Mauve: how beta is that combo? will it work on 0.10?

  56. Link Mauve

    I only tested it on trunk, and haven’t deployed it to any big service.

  57. Link Mauve

    I only tested it on trunk, and haven’t deployed it to any big service yet.

  58. Link Mauve

    So very beta.

  59. Ge0rG crosses fingers.

  60. Ge0rG

    Link Mauve: it doesn't look like it's doing anything.

  61. Ge0rG

    Or does it require the client to re-login first?

  62. Link Mauve

    Hmm, it shouldn’t.

  63. Link Mauve

    Oh.

  64. Link Mauve

    Yes, the cache thing needs it to publish its caps.

  65. Ge0rG

    And now my re-logged-in client returns empty disco#info

  66. Ge0rG

    Whoops, why did it change the resource?!

  67. Ge0rG

    Jun 01 15:01:45 yax.im:auto_answer_disco_info debug Answering disco#info on the behalf of georg@yax.im/Monal-iOS.79

  68. Ge0rG

    it looks like it's working.

  69. Ge0rG

    Link Mauve: could you please change the module:log into session.log everywhere?

  70. Link Mauve

    Sure, is that the new preferred way to log things?

  71. Ge0rG

    Also, is the cache per-JID or is it global per-node?

  72. Ge0rG

    oh, it's a per-full-JID one-item cache, right?

  73. Link Mauve

    Per-JID, because of issues with 0115.

  74. Ge0rG

    Link Mauve: good job

  75. Link Mauve

    Correct, only the last one.

  76. Link Mauve

    I tried to implement that quite defensively.

  77. Ge0rG

    So I've loaded it now on yax.im. Will complain loudly (as I always do) if it fails.

  78. Ge0rG

    Also seems to work, except for the module:logging instead of session logging.

  79. Kev

    > Kev, so, in variant 2, when sending a message to an occupant (<channel>@<service>/<user id>), that would not be carbon-copied or archived under XMPP 2.0 rules, right? That's about the address it's too, not from. It's to the user's bare JID, so it gets archived (and carbons aren't a thing any more under the new rules)

  80. Kev

    And yes, it's a complex space.

  81. jonasw

    Kev, I mean on the sender side. I send a 1:1 message to an occupant in a MIX, so to <channel>@<service>/<user id>. This is to a full JID (even though in MIX context, it has the semantics of a bare JID), so it would not get carbon-copied or archived on my side

  82. Kev

    In variant 2 that's a problem, yes. I don't think it's a problem with variant 4.

  83. Ge0rG

    In XEP-0357, does a client need to enable push notification on its server once or once per login?

  84. Zash

    per login IIRC

  85. Zash

    It's per client/session, and there's no client tracking in servers (yet?)

  86. Ge0rG

    How is the client supposed to be woken up if it's not connected?

  87. Zash

    It .. persists?

  88. Ge0rG

    So the push remains even after the session is dead?

  89. Zash

    Yes

  90. daniel

    Technically you wouldn't have to register on every login. You just do so the server can map a push target to a session

  91. daniel

    And *not* notify an active session

  92. Ge0rG

    How does prosody^W that community thing handle it?

  93. MattJ

    afaik it expects the client to register every login

  94. Ge0rG

    what happens after the session got hibernated and then destroyed?

  95. MattJ

    https://hg.prosody.im/prosody-modules/file/6abee021d9db/mod_cloud_notify/business_rules.markdown

  96. Ge0rG

    that document essentially writes that as soon as the session is hibernated, it's woken up by push.

  97. Ge0rG

    but not what happens on destruction

  98. Ge0rG

    oh, the b) part.

  99. Ge0rG

    But I don't see that in my logs.

  100. Zash

    Is this where I dig up something you said about mod_pinger to use as proof that you want the client woken up all the time? ;)

  101. pep.

    >Ge0rG> my intention really isn't to assign blame to anyone, all I wish for is to have a better server so that my father-in-law can finally receive my messages. That one thing we all wish for on an IM protocol, for users to receive our messages :)

  102. Ge0rG

    Zash: > I could well live with mod_pinger completely ignoring 0198 sessions (as outlined in the first comment to this issue).

  103. Ge0rG

    https://upload.yax.im/upload/ry1sb7gR9MLW98BL/Screenshot_20180601-200703.png - exactly what I imagined with PARS.

  104. Zash

    Ge0rG: Didn't you have pretty much that but for yaxim? And doesn't daniel have pretty much that for Conversations?

  105. Ge0rG

    Zash: except ours is interoperable with other clients and platforms

  106. Zash

    but but the lock-in!!