XSF Discussion - 2018-06-13

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

I’d say no.

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

even though that might help with debugging

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.

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

good

... and log things locally for debugging.

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

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

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

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

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

breaking layers too much

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

Dave Cridland: Cert poke.

Zash, Really? Oh.

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

.

.

and so it begins

Yep, kid at the keyboard again, sorry 🙏

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

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

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

-xep 357

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

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

tx

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

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

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

gotta put my kids in bed now though, afk.

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)?

Yes

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

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

Thanks, that helped a lot

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

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

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

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

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

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

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

doesn't that defeat the purpose?

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

ah, right.

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

got itj

got it*

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

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

How is that different from how it works now

Besides IQ vs messages

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

Than pretending the app server is a pubsub service

But now I'm sounding like Ge0rG

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

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

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

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.

Fair enough :/

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: Update XEP-0298 #8 https://github.com/xsf/xeps/pull/8

Bunneh, nah ...

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

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

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

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

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

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

Holger, messages can have error responses too...

Receipts!

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

Otherwise we should just do all messaging over iq

MattJ: Hush, don't give them ideas

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

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.

But yes I could live with both.

s/both/either/

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

We could replace all IQs with messages :-)

NACK or ACK by default?

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

*you didn't

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

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

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

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

Right

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

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

if those other layers support it

Does it make sense to return >1 error responses?

Or what would the difference be?

Your message doubly failed to send

As in, difference wrt iq

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.

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