is a stream closed wtih a stream error by the client SM-resumable?
marmistrzhas left
rtq3has joined
Valerianhas joined
Valerianhas left
Valerianhas joined
pep.has left
rishiraj22has left
rainslidehas joined
rishiraj22has left
rishiraj22has left
Kevhas left
rishiraj22has left
rishiraj22has left
Link Mauve
I’d say no.
jonasw
that’d mean that sending <connection-timeout/> on streams which one believes to be dead is a bad idea.
jonasw
even though that might help with debugging
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.
Holger
jonasw: Yes I think that's a bad idea. Just close the TCP session.
jonasw
good
Holger
... and log things locally for debugging.
jonasw
mmm, I might even be sending </stream:stream> on timeouts in some cases, I need to look into that
j.rhas joined
jonasw
(or have been sending, anyways, I reworked the whole timeout business and I think it’s much better now in any respect)
Holger
jonasw: Or if you think it would be good/important to support this, it should explicitly go into 0198, IMO.
jonasw
which would namespace-bump '198. thanks, but no thanks.
jonasw
(or maybe stream-feature it, but eh, I don’t want to handle that with a conditional thing)
jonasw
breaking layers too much
lnjhas left
rishiraj22has left
rishiraj22has left
rishiraj22has left
rishiraj22has left
rishiraj22has left
rainslidehas left
Kevhas left
rishiraj22has left
rishiraj22has left
doshas joined
ThibGhas joined
ThibGhas joined
rishiraj22has left
rishiraj22has left
rishiraj22has joined
rishiraj22has left
rishiraj22has joined
winfriedhas left
ralphmhas joined
efrithas left
rishiraj22has left
rishiraj22has joined
rishiraj22has left
rishiraj22has joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
jerehas joined
Neustradamushas left
Neustradamushas joined
Kevhas joined
Guushas left
Guushas left
j.rhas joined
j.rhas joined
Guushas left
Guushas left
Guushas joined
mrdoctorwhohas joined
Alexhas joined
vanitasvitaehas left
rainslidehas joined
alexishas joined
lumihas joined
rishiraj22has left
rishiraj22has joined
rainslidehas left
j.rhas joined
mimi89999has left
j.rhas joined
rishiraj22has left
rishiraj22has joined
mrdoctorwhohas joined
mrdoctorwhohas joined
nycohas left
nycohas joined
rishiraj22has left
nycohas left
danielhas left
nycohas joined
rishiraj22has joined
rishiraj22has left
jerehas joined
lorddavidiiihas left
rishiraj22has left
rishiraj22has left
rishiraj22has left
jerehas joined
rishiraj22has left
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
Guus: maybe the Readme in github.com/inputmice/p2 can help?
Guus
tx
vanitasvitaehas left
Valerianhas left
Valerianhas joined
Neustradamushas joined
Valerianhas left
Valerianhas joined
Valerianhas left
karphas left
daniel
Let me know if that was in fact helpful. Maybe there is something left that I can clarify
j.rhas joined
Guus
daniel, I'm half way through it, and had two ah-hah! moment already.
Guus
(not to be confused with a-ha moments: https://www.youtube.com/watch?v=djV11Xbc914 )
Guus
gotta put my kids in bed now though, afk.
alexishas joined
j.rhas left
j.rhas joined
rainslidehas joined
j.rhas joined
alacerhas left
alacerhas joined
rishiraj22has left
lskdjfhas joined
rishiraj22has left
labdsfhas left
rainslidehas left
rishiraj22has left
Dave Cridlandhas left
rishiraj22has left
rtq3has left
rtq3has joined
jubalhhas joined
rtq3has left
rtq3has joined
alexishas left
Valerianhas joined
alexishas joined
lskdjfhas joined
j.rhas joined
j.rhas joined
lskdjfhas left
lskdjfhas joined
lskdjfhas left
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)?
lskdjfhas joined
lskdjfhas joined
marmistrzhas left
lskdjfhas left
daniel
Yes
daniel
And the jid of the P2 is hard-coded into Conversations. And if you compile that yourself you'd have to change that
Guus
Yeah, I'm not interested in doing that - I'm just checking if I understood the concept better now.
lumihas joined
Guus
Thanks, that helped a lot
lskdjfhas left
alexishas joined
SamWhitedhas left
labdsfhas left
Ge0rGhas left
Dave Cridlandhas left
lskdjfhas left
karphas left
karphas joined
muppethhas joined
jubalhhas joined
lskdjfhas left
lskdjfhas left
lskdjfhas left
jubalhhas left
lskdjfhas left
danielhas left
Guus
In a follow-up question to Push notifications: is there a list somewhere of good event candidates that warrant a push notification?
daniel
If there is a hibernating or unresponsive session push on every stanza that is being send down stream (not held back by csi)
daniel
Otherwise push on everything that would land in the archive / offline message
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
lskdjfhas left
daniel
So you'll know whether a specific push target is currently connected or not
daniel
Clients will send the enable in every session you know which session belongs to which push target
Dave Cridlandhas left
rishiraj22has left
Guus
did you just tell me to not send push notifications to an inactive (CSI) client?
Guus
doesn't that defeat the purpose?
Holger
Guus: Just not for those stanzas held back by CSI.
Guus
ah, right.
Holger
Guus: The idea is that you'd usually want the same filtering rules for disconnected push clients as for inactive TCP-connected clients.
labdsfhas left
Guus
got itj
Guus
got it*
tahas left
Andrew Nenakhovhas joined
labdsfhas left
Andrew Nenakhovhas joined
j.rhas joined
Marandahas joined
j.rhas joined
alexishas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Alexhas left
Alexhas joined
Valerianhas left
labdsfhas left
lskdjfhas left
danielhas left
la|r|mahas joined
lskdjfhas joined
rishiraj22has left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
muppethhas joined
rishiraj22has left
marmistrzhas left
Andrew Nenakhovhas left
muppethhas joined
Andrew Nenakhovhas joined
rishiraj22has left
rishiraj22has joined
MattJ
What if push was just the client registering a JID with it's server?
MattJ
And the server sent a simple <message> to that JID when it wanted to push something
daniel
How is that different from how it works now
daniel
Besides IQ vs messages
alexishas joined
jubalhhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
karphas left
karphas joined
jubalhhas left
jubalhhas joined
jubalhhas left
labdsfhas left
jubalhhas joined
tahas left
jubalhhas joined
jubalhhas joined
jubalhhas joined
kasper.dementhas joined
tahas left
jubalhhas joined
jubalhhas left
MattJ
I guess it isn't, it's just a lot simpler
MattJ
Than pretending the app server is a pubsub service
MattJ
But now I'm sounding like Ge0rG
labdsfhas left
jubalhhas joined
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
anjanhas left
MattJ
I would probably drop all the stuff about the communication between the app server and the client
MattJ
I think people can figure that part out for themselves, and in reality it will be different in every case
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.
MattJ
Fair enough :/
zakhas joined
Zashhas left
SaltyBoneshas left
tahas left
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.
Holger: you wanted to write a PR against push to remove the nonsense.
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
Holger
Ge0rG: I wanted to do that or you wanted me to want to do it? :-)
Holger
> I would probably drop all the stuff about the communication between the app server and the client
+1
Kevhas left
lorddavidiiihas left
Ge0rG
Holger: you said you'd take over authorship to fix it, but then Kev was first.
lskdjfhas left
Holger
Well those plans for 'fixing' the XEP were unrelated to the PubSub langauge. But whatever yes I'll try to find some time.
rionhas left
MattJ
Holger, messages can have error responses too...
Zash
Receipts!
MattJ
I see the attraction of iq, but I don't think it's a given requirement
MattJ
Otherwise we should just do all messaging over iq
Zash
MattJ: Hush, don't give them ideas
Holger
MattJ: In practice the ACK seems quite useful to me as well.
lskdjfhas left
Yagizahas left
lskdjfhas joined
foxtunehas joined
Zashhas left
Zashhas left
Wiktorhas left
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.
lskdjfhas left
Holger
But yes I could live with both.
Zashhas left
Holger
s/both/either/
muppethhas joined
lskdjfhas left
lskdjfhas left
Zashhas left
lskdjfhas left
remkohas left
doshas joined
labdsfhas left
la|r|mahas left
marmistrzhas left
Marandahas joined
lskdjfhas joined
Wiktorhas left
Wiktorhas joined
alexishas left
muppethhas left
muppethhas joined
alexishas joined
Ge0rGhas joined
Ge0rG
With messages you could just send back error responses. Should be enough to find out which client is broken, right?
Holger
We could replace all IQs with messages :-)
Zash
NACK or ACK by default?
andyhas joined
marmistrzhas left
Zashhas left
Holger
Yes, and follow-up with a ping IQ to make sure didn't just loose the connection to the app server!
rishiraj22has left
rishiraj22has joined
Holger
*you didn't
j.rhas joined
nycohas left
lskdjfhas joined
lskdjfhas joined
la|r|mahas joined
Neustradamushas left
labdsfhas left
tuxhas left
Ge0rG
Great. Then next step will be to replace presence with messages as well.
Holger, and what are you saying? The iq result should reflect successful delivery to the client or to the app server?
nycohas joined
Holger
MattJ: Just the app server, there's usually no (easy) way for the app server to acknowledge delivery to the client of course.
MattJ
Right
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
alexishas joined
doshas joined
MattJ
Using message /would/ allow an app server to generate errors from other layers
MattJ
if those other layers support it
Zash
Does it make sense to return >1 error responses?
Zash
Or what would the difference be?
MattJ
Your message doubly failed to send
Guushas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
lskdjfhas left
rishiraj22has left
rishiraj22has joined
Andrew Nenakhovhas joined
Guushas left
Zash
As in, difference wrt iq
lskdjfhas left
jjrhhas left
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.
lskdjfhas joined
Holger
But yes, in a hypothetical world with ubiquitous s2s-0198 and robust app servers the implicit success assumption would work just as well.