XSF Discussion - 2018-06-01

I sent an email reply to the list.

Agree that option 3 is the worst choice.

Jonas has convinced me that we should stick with option1.

Dave Cridland hi :)

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

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

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

which IQs are those typically?

And can we cache them on the server?

Disco probably

Disco can definitively be cached

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)

Hm. No idea what that was

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

because the recipient is a full JID

this is a super-messy complex design space

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

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

Ge0rG, it hurts when you say "Prosody"

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

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

Does that sound better now?

That one I'll take on the chin

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.

Even mod_firewall is merely a community module.

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

BUT USERS WILL COMPLAIN

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

Humans gonna human

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

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

Not using smacks? :P

Nope

CSI + MAM

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

However Google Code shut down

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

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

Ge0rG, you might wanna try that thing Link Mauve did

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

What are you talking about? 🤔

which answers on behalf of the client

The Thing™

for disco#info if they publish caps

jonasw: disco#info cache?

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.

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

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

Link Mauve: where can I find The Thing™?

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

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

Ge0rG: that's my intention also, believe me

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

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

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

So very beta.

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

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

Hmm, it shouldn’t.

Oh.

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

Whoops, why did it change the resource?! ✏

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

it looks like it's working.

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

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

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

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

Per-JID, because of issues with 0115.

Link Mauve: good job

Correct, only the last one.

I tried to implement that quite defensively.

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

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

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

And yes, it's a complex space.

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

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

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

per login IIRC

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

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

It .. persists?

So the push remains even after the session is dead?

Yes

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

And *not* notify an active session

How does prosody^W that community thing handle it?

afaik it expects the client to register every login

what happens after the session got hibernated and then destroyed?

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

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

but not what happens on destruction

oh, the b) part.

But I don't see that in my logs.

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

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

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

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

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

Zash: except ours is interoperable with other clients and platforms

but but the lock-in!!