XSF Discussion - 2018-08-26

hm?

> If that item is the first in the full set, then the index SHOULD be '0'

what’s wrong with that?

since most array/key-item pairs implementations start iterating from one I fail to get the logic in that

the only ones I know are lua and pascal

all other languages are sane (<https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html> ;-))

note that you possibly need to re-map anyways since filters might be involved

Urgh 🤦‍♂️ (infact guess the first language I ever learned... Pascal)

ha, me too

jonasw, honestly I think I won't touch RSM for another seven years or so now, I hated it back then and I hated it now since someone I won't name made me look into it again. ✏

I can understand that. If I worked in a language where I had to add 1 to an offset, I'd probably find it too difficult as well. :)

Kev, hehe. Lucky I'm stubborn enough that I get things done, first or laters (and laters may be years of course)

anyone ever catched a choppy client signaling Client State before negotiating SM?

isn’t that even how you’re supposed to do things?

I always get confused

jonasw, tbh if there's no resumption I'm a bit confused as well. For me it makes sense to negotiate SM first and then signal client state

but since there's no text about that I suppose it could be fine the other way around as well.

but in that case I'd have to catch that.

If the state is a property of the stream then that sorta makes some sense.

Didn't we agree that this was the case?

Zash, sorry do you mean negotiating SM first and then CSI or the other way around? Just to make sure.

Either way

hmm

Resource binding (and SM) attaches a full JID / session to a stream. Or something.

Guess I will catch the case perhaps instead of throwing an error SM wise, not much effort to do that and refresh the session's send reference anyways if there's a queue in the module handling CSI.

And flushing presences on stanzas when receiving IQs or Messages, may fix in order processing breakage but it fairly reduces effectiveness of presence deduplication in mucs. 🤷‍♂️

Depends on what you're trying to achieve. If it's about battery saving, from what I've learnt it's all about avoiding to wake the radio. So if you need to send traffic anyway, the additional traffic won't matter.

Holger, hmmm perhaps I suppose that you'll need to queue both messages and presences and not just presences in MUC scenario to be somehow effective in that department 🤔

Yeah but that would require knowledge on whether the user wants to be notified of (which) MUC messages of course.

... which atm adds some kind of complexity, which I don't exactly wanna add tbh 😁

We'd need some spec to have clients communicate notification settings to the server.

but the E2EE!!

Well you could still filter notifications based on 'from'.

doesn’t help with most MUC scenarios

or rather, the most interesting MUC scenario

Holger, maybe I found an elegant and simple solution to the dilemma... what if I just drop chat states/bodyless messages when client state is inactive?

That's what mostly overtriggers the queue flush in mucs anyways ✏

jonasw: You mean "notify on mention"? Yeah that's interesting for public rooms (which aren't encrypted anyway) but less so for private groupchat I think.

"public rooms (which aren't encrypted anyway)" you wish

Heh.

Maranda: In ejabberd I dedup chat states in a similar way to presence.

I.e. when becoming <active/> again, you receive (only) the most recent from a given full JID.

maybe reducing the chatstates can also help, instead of 5, we could have just 3, active, composing, inactive

Maranda: Same thing for PEP node notifications from a given full JID. Chat Markers would make sense as well I guess.

Holger, I guess I'll just drop completely, for now, at least or I'd have to rework the queue logics.

but will test a bit

Also bringing up the argument that blocked/dropped stanzas should be bounced with an error that has definite implications privacy wise. If it's a user blocking you're disclosin' an information to the other party that is not supposed to be given away.

I think the error is supposed to be the same as for nonexistant users

💡turned on just know

jonasw: for simple blocking command some "blocked error" really is used 🙄

For example

no wait, that was for mod_block_strangers

(in the xep that is)

(and that's wrong)

jonasw: nm that's for the user who blocked my bad

Something else to fix, yay