-
jonasw
is a stream closed wtih a stream error by the client SM-resumable?
-
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
-
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
-
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
-
Zash
Dave Cridland: Cert poke.
-
Dave Cridland
Zash, Really? Oh.
-
Wiktor
n//nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn.n; ; :::///////b?b/N//n///n/nmmmm?/mM ,,.....................
-
Wiktor
.
-
Wiktor
.
-
MattJ
and so it begins
-
Wiktor
Yep, kid at the keyboard again, sorry 🙏
-
pep.
looks like some kind of sed, he's trying to send us a message
-
Wiktor
That may be the case, he can't speak yet, he's trying to communicate! Via sed!
-
Guus
I think I'm to stupid to understand XEP-0357. Can someone explain section 2.2 to me please?
-
Zash
-xep 357
-
Bunneh
Zash: Push Notifications (Standards Track, Experimental, 2017-08-24) See: https://xmpp.org/extensions/xep-0357.html
-
daniel
Guus: maybe the Readme in github.com/inputmice/p2 can help?
-
Guus
tx
-
daniel
Let me know if that was in fact helpful. Maybe there is something left that I can clarify
-
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.
-
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)?
-
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.
-
Guus
Thanks, that helped a lot
-
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
-
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
-
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.
-
Guus
got itj
-
Guus
got it*
-
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
-
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
-
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
-
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 :/
-
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.
-
Bunneh
Holger: Update XEP-0298 #8 https://github.com/xsf/xeps/pull/8
-
Holger
Bunneh, nah ...
-
Ge0rG
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
-
Ge0rG
Holger: you said you'd take over authorship to fix it, but then Kev was first.
-
Holger
Well those plans for 'fixing' the XEP were unrelated to the PubSub langauge. But whatever yes I'll try to find some time.
-
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.
-
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.
-
Holger
But yes I could live with both.
-
Holger
s/both/either/
-
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?
-
Holger
Yes, and follow-up with a ping IQ to make sure didn't just loose the connection to the app server!
-
Holger
*you didn't
-
Ge0rG
Great. Then next step will be to replace presence with messages as well.
-
Zash
https://datatracker.ietf.org/doc/html/draft-shafranovich-privacy-mailbox hmm
-
MattJ
Holger, and what are you saying? The iq result should reflect successful delivery to the client or to the app server?
-
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
-
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
-
Zash
As in, difference wrt iq
-
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.
-
Holger
But yes, in a hypothetical world with ubiquitous s2s-0198 and robust app servers the implicit success assumption would work just as well.