XSF Discussion - 2018-06-13

  1. jonasw

    is a stream closed wtih a stream error by the client SM-resumable?

  2. Link Mauve

    I’d say no.

  3. jonasw

    that’d mean that sending <connection-timeout/> on streams which one believes to be dead is a bad idea.

  4. jonasw

    even though that might help with debugging

  5. Holger

    I'd say 'no' as well. Stream errors are unrecoverable. But formally speaking you could probably go into the definition of 'stream' vs. 'session' or how XEPs may override RFCs, while then again 0198 doesn't go into this.

  6. Holger

    jonasw: Yes I think that's a bad idea. Just close the TCP session.

  7. jonasw


  8. Holger

    ... and log things locally for debugging.

  9. jonasw

    mmm, I might even be sending </stream:stream> on timeouts in some cases, I need to look into that

  10. jonasw

    (or have been sending, anyways, I reworked the whole timeout business and I think it’s much better now in any respect)

  11. Holger

    jonasw: Or if you think it would be good/important to support this, it should explicitly go into 0198, IMO.

  12. jonasw

    which would namespace-bump '198. thanks, but no thanks.

  13. jonasw

    (or maybe stream-feature it, but eh, I don’t want to handle that with a conditional thing)

  14. jonasw

    breaking layers too much

  15. Ge0rG

    jonasw [13:49]: > that’d mean that sending <connection-timeout/> on streams which one believes to be dead is a bad idea. Bad idea indeed

  16. Zash

    Dave Cridland: Cert poke.

  17. Dave Cridland

    Zash, Really? Oh.

  18. Wiktor

    n//nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn.n; ; :::///////b?b/N//n///n/nmmmm?/mM ,,.....................

  19. Wiktor


  20. Wiktor


  21. MattJ

    and so it begins

  22. Wiktor

    Yep, kid at the keyboard again, sorry 🙏

  23. pep.

    looks like some kind of sed, he's trying to send us a message

  24. Wiktor

    That may be the case, he can't speak yet, he's trying to communicate! Via sed!

  25. Guus

    I think I'm to stupid to understand XEP-0357. Can someone explain section 2.2 to me please?

  26. Zash

    -xep 357

  27. Bunneh

    Zash: Push Notifications (Standards Track, Experimental, 2017-08-24) See: https://xmpp.org/extensions/xep-0357.html

  28. daniel

    Guus: maybe the Readme in github.com/inputmice/p2 can help?

  29. Guus


  30. daniel

    Let me know if that was in fact helpful. Maybe there is something left that I can clarify

  31. Guus

    daniel, I'm half way through it, and had two ah-hah! moment already.

  32. Guus

    (not to be confused with a-ha moments: https://www.youtube.com/watch?v=djV11Xbc914 )

  33. Guus

    gotta put my kids in bed now though, afk.

  34. Guus

    daniel, so if I understand things correctly, then somewhere there's at least one of your P2 instances running that services the standard Conversations clients that are out there? (I can run my own, but that's only of interest if I build my own Conversations client?). Regular Conversations clients will perform "Account Owner Service Discovery" on the local XMPP domain, and, if available, this will eventually cause Conversations to ask the local XMPP domain to enable notifications (in that request a reference to the JID of your P2 instance is included)?

  35. daniel


  36. daniel

    And the jid of the P2 is hard-coded into Conversations. And if you compile that yourself you'd have to change that

  37. Guus

    Yeah, I'm not interested in doing that - I'm just checking if I understood the concept better now.

  38. Guus

    Thanks, that helped a lot

  39. Guus

    In a follow-up question to Push notifications: is there a list somewhere of good event candidates that warrant a push notification?

  40. daniel

    If there is a hibernating or unresponsive session push on every stanza that is being send down stream (not held back by csi)

  41. daniel

    Otherwise push on everything that would land in the archive / offline message

  42. daniel

    The thing you need to that is not described in the P2 Readme is that you should create a mapping between your push targets (app server jid - node ID tuple) and the current session

  43. daniel

    So you'll know whether a specific push target is currently connected or not

  44. daniel

    Clients will send the enable in every session you know which session belongs to which push target

  45. Guus

    did you just tell me to not send push notifications to an inactive (CSI) client?

  46. Guus

    doesn't that defeat the purpose?

  47. Holger

    Guus: Just not for those stanzas held back by CSI.

  48. Guus

    ah, right.

  49. Holger

    Guus: The idea is that you'd usually want the same filtering rules for disconnected push clients as for inactive TCP-connected clients.

  50. Guus

    got itj

  51. Guus

    got it*

  52. MattJ

    What if push was just the client registering a JID with it's server?

  53. MattJ

    And the server sent a simple <message> to that JID when it wanted to push something

  54. daniel

    How is that different from how it works now

  55. daniel

    Besides IQ vs messages

  56. MattJ

    I guess it isn't, it's just a lot simpler

  57. MattJ

    Than pretending the app server is a pubsub service

  58. MattJ

    But now I'm sounding like Ge0rG

  59. daniel

    Not worth changing at this point IMHO. One could consider rewriting the entire xep to make it easier to understand while keeping the Syntax

  60. MattJ

    I would probably drop all the stuff about the communication between the app server and the client

  61. MattJ

    I think people can figure that part out for themselves, and in reality it will be different in every case

  62. Holger

    MattJ: I think there's value in using an IQ to get an ACK or error back. Yes the PubSub syntax is useless and confusing, and even more so all that nonsense-talk around PubSub in the XEP. But now that we have it I'd go for just simplifying the language as daniel said.

  63. MattJ

    Fair enough :/

  64. Holger

    You want the IQ errors to let the app server notify you of dead push devices. The XEP also specifies an affiliation change <message/> in section #8 but that seems meh to me. I'd ditch that.

  65. Bunneh

    Holger: Update XEP-0298 #8 https://github.com/xsf/xeps/pull/8

  66. Holger

    Bunneh, nah ...

  67. Ge0rG

    Holger: you wanted to write a PR against push to remove the nonsense.

  68. Ge0rG

    Really, that xep is actively harmful. I don't know if just removing the misdirections while keeping the wire format will save it, but it's worth a try

  69. Holger

    Ge0rG: I wanted to do that or you wanted me to want to do it? :-)

  70. Holger

    > I would probably drop all the stuff about the communication between the app server and the client +1

  71. Ge0rG

    Holger: you said you'd take over authorship to fix it, but then Kev was first.

  72. Holger

    Well those plans for 'fixing' the XEP were unrelated to the PubSub langauge. But whatever yes I'll try to find some time.

  73. MattJ

    Holger, messages can have error responses too...

  74. Zash


  75. MattJ

    I see the attraction of iq, but I don't think it's a given requirement

  76. MattJ

    Otherwise we should just do all messaging over iq

  77. Zash

    MattJ: Hush, don't give them ideas

  78. Holger

    MattJ: In practice the ACK seems quite useful to me as well.

  79. Holger

    MattJ: There's many hops in getting a push notification to the client, and when that fails you can be sure the problem is with one of the hops beyond the XMPP server.

  80. Holger

    But yes I could live with both.

  81. Holger


  82. Ge0rG

    With messages you could just send back error responses. Should be enough to find out which client is broken, right?

  83. Holger

    We could replace all IQs with messages :-)

  84. Zash

    NACK or ACK by default?

  85. Holger

    Yes, and follow-up with a ping IQ to make sure didn't just loose the connection to the app server!

  86. Holger

    *you didn't

  87. Ge0rG

    Great. Then next step will be to replace presence with messages as well.

  88. Zash

    https://datatracker.ietf.org/doc/html/draft-shafranovich-privacy-mailbox hmm

  89. MattJ

    Holger, and what are you saying? The iq result should reflect successful delivery to the client or to the app server?

  90. Holger

    MattJ: Just the app server, there's usually no (easy) way for the app server to acknowledge delivery to the client of course.

  91. MattJ


  92. MattJ

    So to the app server, that can be solved with 198 already, though I don't think message loss on s2s is a common problem

  93. MattJ

    Using message /would/ allow an app server to generate errors from other layers

  94. MattJ

    if those other layers support it

  95. Zash

    Does it make sense to return >1 error responses?

  96. Zash

    Or what would the difference be?

  97. MattJ

    Your message doubly failed to send

  98. Zash

    As in, difference wrt iq

  99. Holger

    There's other error cases than s2s connection loss, and debugging them can be a PITA as multiple parties are involved with the delivery. Therefore I prefer an explicit ACK in the logs over an implicit success assumption based on missing error messages while debugging issues in practice.

  100. Holger

    But yes, in a hypothetical world with ubiquitous s2s-0198 and robust app servers the implicit success assumption would work just as well.