Andrew Nenakhov: if your company only employs jabber fans, this is an expected outcome. If you start with a bunch of people who never before did business chat, slack is much easier than any of the alternatives, especially xmpp
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
mikaelahas joined
jonasw
Andrew Nenakhov, to be frank, I don’t like how you seem to do decent development, but don’t discuss with the community whenever you make such choices.
jonasw
(re 0221 vs. 0066, but also MUC etc.)
jonasw
(although muc is kinda understandable given the state MIX is in)
kasper.dementhas joined
Tobiashas left
Tobiashas joined
jonaswhas left
anjanhas joined
Dave Cridlandhas left
Ge0rG
> Zulip is 100% open source software, built by a vibrant community of hundreds of developers from all around the world. With 120,000 words of developer documentation, a high quality code base, and a welcoming community, it’s easy to extend or tweak Zulip.
What did they do right that we did wrong?
SamWhited
They built a service, we build a protocol.
SamWhited
We need a service to champion the protocol.
Ge0rG
Yes, but where are we going to get the "vibrant community of hundreds of developers"?
SamWhited
Same thing, I think: By building a service. Their community is building on one client and one server. We have a fragmented ecosystem where lots of devs work on lots of clients and servers.
SamWhited
That's fine, but we need some bigger ones with commercial support too.
waqas
Ge0rG: It's fairly rare for the hundreds of developers to be doing much, it's probably a handful of core contributors
SamWhited
yah, that's probably true as well
kasper.dementhas joined
Steve Killehas left
Ge0rG
waqas: so where is the modern xmpp client with a handful of core contributors, then?
waqas
The vibrancy though, we need to learn to vibrate appropriately
Ge0rG
We could start out by making more of a buzz
labdsfhas left
rishiraj22has left
rishiraj22has joined
la|r|mahas joined
kasper.dementhas joined
Steve Killehas left
Seve/SouL
My phone can vibrate, if that counts.
kasper.dementhas joined
rishiraj22has left
rishiraj22has joined
rishiraj22has left
rishiraj22has joined
kasper.dementhas joined
goffi
Hi. Is there a way with OMEMO to specify xml:lang?
rishiraj22has left
rishiraj22has joined
rishiraj22has left
rishiraj22has joined
lnjhas joined
kasper.dementhas joined
waqashas left
rishiraj22has left
rishiraj22has joined
lnjhas left
lnjhas joined
ThibGhas left
ThibGhas joined
mimi89999has left
kasper.dementhas joined
Zashhas joined
Chobbeshas joined
Chobbeshas joined
jonasw
re vibration: https://www.youtube.com/watch?v=JWAAbmps_Zs
kasper.dementhas joined
Steve Killehas joined
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
Guushas left
Guushas joined
goffihas left
goffihas joined
anjanhas left
anjanhas joined
kasper.dementhas joined
anjanhas joined
anjanhas joined
rishiraj22has left
rishiraj22has joined
rishiraj22has left
Zashhas left
kasper.dementhas left
Dave Cridlandhas left
rishiraj22has joined
Ge0rGhas left
Andrew Nenakhov
jonasw, to me it seems that coding > discussing. No point to argue how to do something until we have a working prototype. If there are competing prototypes, community might stick to the one that is better, the other ones will die out by themselves.
As is the case with MIX, creating a protocol without implementation might be a perpetual affair.
goffihas left
Alexhas joined
MattJ
I think there is a balance to be struck between the two
MattJ
"Rough conensus and running code" is a decent mantra in that regard
rishiraj22has left
rishiraj22has joined
jonasw
Andrew Nenakhov, fair enough. this wasn’t necessarily meant as an accusation by the way, although I can see that it may read that way. I think this might also be a symptom of the issue that we have way too many ways to do the same thing.
MattJ
e.g. I looked at MUC Sub recently, and it definitely suffers from code-first problems, a number of things are not specified adequately, or at all
Andrew Nenakhov
> Same thing, I think: By building a service. Their community is building on one client and one server. We have a fragmented ecosystem where lots of devs work on lots of clients and servers.
Currently what we're trying to do is to build server AND clients for all major platforms, so they simultaneously support new features and do it so that all clients have a similar look and feel
jonasw
Andrew Nenakhov, for example, any reason why you’re not using XEP-0385, which seems like a more natural choice for transmitting that type of stuff?
danielhas left
Andrew Nenakhov
Because it has a way too big number and wit myriad of xeps it's hard to read up to that point.
danielhas joined
Andrew Nenakhov
And it looks kinda vague
rishiraj22has left
Andrew Nenakhov
:)
rishiraj22has joined
jonasw
uh, I haven’t read all XEPs up to that. I follow more of a mix&match approach ;-)
rishiraj22has left
rishiraj22has joined
Zashhas joined
rishiraj22has left
rishiraj22has joined
jonasw
what is appealing about 0385 to me is that it has a well-defined way to share multiple sources for the data (like XEP-0221) has, it is reasonably simple to implement, and it allows to provide metadata like file size, mime type and dimensions
Andrew Nenakhov
We slightly extended 0221 for exactly that.
jonasw
meh
Dave Cridlandhas left
jonasw
why not use something which already exists instead of modifying something else which ~nobody else uses?
Here are 4 files. All with sizes, dimensions, file types, etc
Dave Cridlandhas left
rishiraj22has left
rishiraj22has joined
kasper.dementhas joined
Andrew Nenakhov
jonasw, because no one generally uses xmpp at all. So being compatible with some obsolete clients that are a long time abandoned is futile.
jonasw
Andrew Nenakhov, there are actively developed clients outside of redsolution.
Andrew Nenakhov
We have a clear picture of the paying audience we plan to reach. They'll be happy to use our clients exclusively. If we succeed, our approach will be standard. If we fail, well, other clients approach will win.
rishiraj22has left
rishiraj22has joined
Dave Cridlandhas left
Ge0rG
Andrew Nenakhov: your approach will not be "standard", it will be a silo.
jonasw
I expect it more to end up like whatsapp with no compatibility to other clients at all, yet another XMPP fork.
Ge0rG
or slack.
Ge0rG
or any other cloud-based chat offering with a half life of five years.
labdsfhas joined
Andrew Nenakhov
Ge0rG,
> Andrew Nenakhov: your approach will not be "standard", it will be a silo.
X in XMPP stands for extensible. It seems to me that we understand
Extensibility differently. If our approach succeeds with users, we'll suggest updating the standard. And we do everything with providing compatibility, not breaking anything anyway.
Ge0rG
Andrew Nenakhov: what MattJ said. "rough consensus and working code". Without consensus from the community, your code will end up in a dead end
Ge0rG
Andrew Nenakhov: I can understand your position from a business point of view, but I'm not yet sure it will actually benefit the XMPP community
jonasw
Andrew Nenakhov, while you figure out your business model and acquire customers, the community is doing its own development. then we end up with two strains of XMPP, one of which in your company which isn’t written down in standards, and one used by the community actually written down in the XEPs.
jonasw
I doubt that modifications to the XEPs which replicate things the community already has figured out in a more consensual way would be accepted
MattJ
I think it's also not taking advantage of community expertise that exists
jonasw
that, too
Andrew Nenakhov
What exactly things do we replicate?
jonasw
Andrew Nenakhov, the use of XEP-0221 over XEP-0385 is a good example
jonasw
but also the multi-user-chat discussion.
Andrew Nenakhov
Why did community develop unnecessary standard instead of slightly updating 0221?
jonasw
because data forms are---to me at least, but I think others may agree---not primarily a way to share (meta-)data but for interactive things. '221 was written with captchas in mind. '385 was specifically written with file sharing in mind, and I think it achieves that much better. There’s no way to annotate individual URLs in a <body/> using '221. '385 re-uses references for taht.
Andrew Nenakhov
And with mix, I'm probably one of the few who mostly read it along with my dev team. It's broken by design.
And we already have a working group chat that works great, it's fast and reliable. Maybe 30% work left on server side.
jonasw
(but this is just waht I assume, '385 happenend before I was around here)
Ge0rG
Let's not talk about MIX
Andrew Nenakhov
Ok. )
tuxhas joined
jonasw
I understand your point about code-first, standards-second, but I don’t see how a quick "Hey, we’re going to do file sharing with metadata and plan to use '221 for that, any reasons we shouldn’t?" email would’ve hurt anyone.
jonasw
I think you would have gotten a clear response that building on '385 (I’m not saying that '385 is perfect, it can certainly use some love) would be preferrable.
Alexhas left
Alexhas joined
Andrew Nenakhov
You see. I respect you guys who do stuff . And I like the idea of federated messaging. I firmly believe humanity needs an independent protocol to exchange messages. That's why I'm using my time, money and attract investors to fund our efforts in this space.
However, xmpp is already older than one of my developers who joined the team yesterday. If in all these years doing things like it's done xmpp didn't reach even a fraction of WhatsApp success, did it occur to you that things should be done differently? At least, tried to be done differently?
jonasw
I see your point, however, going the same way WhatsApp (originally XMPP based, too) went by forking the protocol and ignoring the community won’t help here.
Andrew Nenakhov
jonasw, ok I'll write an email on 221 use. We actually considered 385 and rejected it, I'll explain why.
jonasw
that’d be great
jonasw
Looking forward to see why you came to the conclusion that modifying '221 was a better way forward than modifying '385.
Ge0rG
Andrew Nenakhov: we are building a protocol, not a product. You can't attract users with a protocol ;)
lnjhas left
Andrew Nenakhov
jonasw, we are not going the exact WhatsApp way. If we do stuff we'll publish protocol extensions and release open source products that support them.
jonasw
(especially given that '385 is Experimental and thus has a much lower barrier to modification than '221 has)
kasper.dementhas joined
Dave Cridlandhas left
Dave Cridlandhas left
Holgerhas left
ThibGhas left
ThibGhas joined
kasper.dementhas left
lskdjfhas joined
pep.has joined
rionhas left
Andrew Nenakhov
Btw I'm still not over how xhtml XEP was made deprecated.
kasper.dementhas joined
Seve/SouLsmiles.
jonasw
I’m still not certain on that one either.
jonasw
I’m swaying between "it’s not *that* hard to get it right, even if done by simply disallowing all CSS" and "ugh. XHTML brings us a horde of security issues"
Guushas left
Guushas joined
efrithas left
labdsfhas left
rishiraj22has left
la|r|mahas joined
rishiraj22has left
la|r|mahas joined
kasper.dementhas joined
Link Mauve
Disallowing all CSS isn’t even a good solution, the subset defined in 0071 is known to not have any vulnerability on current browsers.
jonasw
Link Mauve, sure, but it’s not trivial to properly sanitise CSS
jonasw
which is why a simple implementation may choose to ignore it altogether.
jonasw
also, you’d want to modify any colors used to blend in with your UI.
Link Mauve
Maybe I should split out xmpp-parsers’s XHTML handling into another crate, and provide bindings and compilation targets for a bunch of other languages.
Andrew Nenakhovhas joined
Link Mauve
jonasw, sure, and you can.
jonasw
yes, but it’s work
jonasw
work which can be gotten wrong
jonasw
and which can lead to interesting issues when gotten wrong
jonasw
although CSS will most likely only cause tracking since javascript URLs have been forbidden there. although I wouldn’t put my money on that one.
rishiraj22has left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Valerianhas left
kasper.dementhas joined
mimi89999has joined
muppethhas joined
anjanhas joined
la|r|mahas left
Dave Cridlandhas left
muppethhas joined
lnjhas joined
andrey.ghas left
labdsfhas joined
Dave Cridlandhas left
kasper.dementhas joined
mrdoctorwhohas joined
mrdoctorwhohas joined
mrdoctorwhohas joined
mrdoctorwhohas joined
lumihas joined
kasper.dementhas joined
mrdoctorwhohas left
mrdoctorwhohas joined
Ge0rG
> As the team chat market is overcrowded by copycats, Nayego is different.
Said yet another xmpp client developer.
Seve/SouL
Someone from the XMPP community was involved in it, is it?
Ge0rG
I'd say nyco
goffihas joined
Dave Cridland
Ge0rG, Team chat market isn't as crowded as it was yeterday, mind.
Ge0rG
Dave Cridland: it's crowded by the bodies of those who tried and zombies of those who don't want to realize that they failed.
Dave Cridland
Ge0rG, Yeah, I was making a nod toward Stride/Hipchat/Jitsi.
Ge0rG
Oh, I didn't know Jitsi was Atlassian as well. Is it also EOL now?
Dave Cridland
Jitsi was part of HipChat's business unit. The code was incorporated into Stride. Slack, OTOH, use a modified Janus SFU and things - I can't see they'd use much from it.
Ge0rG
Will they make use of the team?
Dave Cridland
I wouldn't know.
Dave Cridland
I've not examined the details of the transfer, but I believe it's a sale of customers basically.
Ge0rG
Except it's not providing customers with a clean migration path, except "install slack, kill your old chat".
Dave Cridland
Basically.
jubalhhas joined
Dave Cridland
And honouring contracts, of course, though they were priced more or less identically.
Ge0rG
I suppose this merger will make few people happy and many people sad, for a variety of reasons.
Alex, Indeed. Nothing on Jitsi, mind, but that's part of the same business unit.
marchas joined
Zashhas left
kasper.dementhas joined
Andrew Nenakhovhas left
Dave Cridlandhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas joined
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
andrey.ghas joined
kasper.dementhas joined
rishiraj22has left
lnjhas left
lnjhas joined
Valerianhas joined
Valerianhas left
Valerianhas joined
rishiraj22has left
xnyhpshas left
xnyhpshas joined
jerehas joined
Zashhas left
alacerhas left
alacerhas joined
Valerianhas left
Valerianhas joined
kasper.dementhas joined
rishiraj22has left
kasper.dementhas joined
Valerianhas left
lovetoxhas joined
blablahas left
alacerhas left
muppethhas left
muppethhas joined
winfriedhas joined
winfriedhas joined
lnjhas left
kasper.dementhas joined
tuxhas joined
kasper.dementhas joined
lnjhas joined
j.rhas joined
kasper.dementhas left
muppethhas joined
muppethhas joined
kasper.dementhas joined
winfriedhas joined
winfriedhas joined
rishiraj22has left
rishiraj22has left
muppethhas left
muppethhas joined
doshas joined
lnjhas left
rishiraj22has left
rishiraj22has left
lnjhas joined
rishiraj22has left
lnjhas left
rishiraj22has left
lnjhas joined
efrithas joined
rishiraj22has left
rishiraj22has left
efrithas left
efrithas joined
j.rhas joined
rishiraj22has left
jubalhhas joined
rishiraj22has left
tahas joined
efrithas left
efrithas joined
rishiraj22has left
danielhas left
danielhas joined
tuxhas left
blablahas left
blablahas left
lnjhas left
rishiraj22has left
blablahas joined
tahas left
rishiraj22has left
rishiraj22has left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
andrey.ghas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
rishiraj22has left
efrithas left
marchas left
andrey.ghas joined
rishiraj22has left
andyhas left
nycohas left
marchas joined
mimi89999has joined
kasper.dementhas joined
rishiraj22has left
kasper.dementhas joined
rishiraj22has left
jubalhhas joined
jubalhhas left
rishiraj22has left
pep.has left
rishiraj22has left
rishiraj22has left
lnjhas joined
muppethhas joined
mimi89999has joined
muppethhas joined
rishiraj22has left
kasper.dementhas joined
labdsfhas left
rishiraj22has left
rishiraj22has left
xnyhpshas joined
rishiraj22has left
jonasw
goffi, could you make a PR against '384 regarding the singleton implementation note?
Zash
There's a thing
jonasw
Zash, that thing? https://xmpp.org/extensions/xep-0060.html#impl-singleton
Zash
https://xmpp.org/extensions/xep-0060.html#impl-singleton
> When this pattern is desired, it is RECOMMENDED for the publisher to specify an ItemID of "current" to ensure that the publication of a new item will overwrite the existing item.
jonasw
that’s what I’m talking about
kasper.dementhas joined
Zash
jonasw: Yes. That thing.
goffi
jonasw: OK I can check that, will do it later this week-end.
jonasw
goffi, thx!
mimi89999has joined
xnyhpshas joined
la|r|mahas joined
la|r|mahas joined
rishiraj22has left
labdsfhas joined
lskdjfhas joined
kasper.dementhas joined
waqashas joined
rishiraj22has left
blablahas left
blablahas joined
kasper.dementhas joined
kasper.dementhas left
kasper.dementhas joined
waqashas left
jonaswhas left
goffihas left
rishiraj22has left
kasper.dementhas joined
rishiraj22has left
waqashas joined
doshas left
doshas joined
rishiraj22has left
rishiraj22has left
intosihas left
intosihas joined
intosihas left
Holgerhas left
kasper.dementhas joined
tahas joined
moparisthebesthas joined
Dave Cridlandhas left
peterhas joined
moparisthebesthas left
404.cityhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
kasper.dementhas joined
Andrew Nenakhovhas joined
la|r|mahas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
kasper.dementhas joined
Dave Cridlandhas left
404.cityhas joined
Dave Cridlandhas left
Dave Cridlandhas left
rishiraj22has left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Dave Cridlandhas left
Dave Cridlandhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
lskdjfhas left
rishiraj22has left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
xnyhpshas joined
labdsfhas left
labdsfhas joined
xnyhpshas joined
lskdjfhas left
lskdjfhas joined
Steve Killehas left
Steve Killehas left
Alexhas left
tahas joined
lskdjfhas joined
Steve Killehas joined
Dave Cridlandhas left
kasper.dementhas joined
Holgerhas left
goffihas joined
rishiraj22has left
kasper.dementhas joined
lumihas left
Steve Killehas left
Guushas joined
lskdjfhas joined
lskdjfhas left
Guus
With regards to CSI, does RFC6120#section-10.1 forbid the queuing of some stanzas, while letting other ones through?
karphas left
lskdjfhas left
karphas joined
kasper.dementhas joined
kasper.dementhas joined
Holger
I've been told it's fine to break RFC rules if the XEP allows it.
Guus
That's ... Surprising
Guus
And feels wrong
goffihas left
Holger
The rationale was that the rule breakage is negotiated and hence won't lead to trouble.
Holger
The problem I see is implementation-wise. If you encoded those rules in the lower layers, you must change those layers to implement an extension.
Guus
At best, I feel that that should be worded better in the XEP.
Guus
It now appears to describe that you should be compliant with section 10.1
Guus
MattJ, thoughs?
Guus
(penny for your)
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
MattJ
My thoughts are that the XEP does not give any mandate to break the RFC
kasper.dementhas joined
MattJ
In-order processing is relied upon in multiple edge cases
MattJ
The CSI XEP originally, very intentionally, avoided saying anything about what a server might do with its knowledge of the client state
Zash
And then some got annoyed because they couldn't be sure what the server would do.
goffihas joined
MattJ
Right, so community consensus seemed to be that it should at least provide a list of example behaviours
Guus
So you feel that you cannot withold say a status update from a client when you push it a message that was sent to it later?
MattJ
I don't, no
Holger
> The CSI XEP originally, very intentionally, avoided saying anything about what a server might do with its knowledge of the client state
The problem I see with that is that the client can't rely on anything once sending <inactive/>.
Guus
And would it be ok to withold from Alice a status update sent from Bob, when Bob later sends a message to Jacky?
muppethhas joined
kasper.dementhas joined
MattJ
Guus, I think it's a little safer between two distinct (bare?) JIDs
MattJ
Holger, I don't see a problem with that
Dave Cridlandhas left
Guus
Sure, but it either does or doesn't break spec.
Bunnehhas left
MattJ
Holger, the CSI XEP was never intended to have any observable effect to the client, at a high level
Bunnehhas joined
MattJ
Guus, CSI does not break the RFC
MattJ
CSI is a way for the client to say whether it is "active" or not, it's very simple
Guus
The withold bit in my example, I mean
MattJ
As far as I'm concerned, what servers do with this info is up to them
MattJ
and not standardised
MattJ
and neither should be, without very careful consideration
MattJ
As far as I'm concerned, if the server breaks the client by messing around with the stream, the server is broken
MattJ
Maybe someone feels like making a standard for this, possibly with an opt-in for the client, they are free to
karphas left
karphas joined
lumihas joined
Guus
So, as far as queuing goes, a CSI based optimization should not queue anything when sending something else to the same bare jid?
Holger
MattJ: Server implementors would have to anticipate all possible use cases to judge whether a given optimization is 'safe', i.e. "has no observable effect".
karphas left
karphas joined
rishiraj22has left
Yagizahas left
alacerhas joined
Holger
> So, as far as queuing goes, a CSI based optimization should not queue anything when sending something else to the same bare jid?
In ejabberd, if I send you a message, I send all queued traffic from the same sender first. (Not sure why I don't just flush the queue in that case, the radio is woken anyway.)
kasper.dementhas joined
Guus
From the same sender?
lnjhas left
Guus
I'd think you'd flush all data to the same recipient. Possibly all its full jids?
Valerianhas joined
Valerianhas left
Holger
Yeah, that's the part I'm not sure makes sense 🙂 (It's been a while and I recently thought about just flushing the queue whenever I send traffic.)
Zash
The thing I personally use has a single queue, that gets flushed when it's "full" or when there's something "important". The original order is preserved.
labdsfhas left
Holger
Guus: Right now if I send you a message from=alice, I only flush all stanzas that were sent from=alice.
Guus
Zash: I'm leaning towards something like that now too.
MattJ
Yes, I'm planning to include the single-queue one in the next Prosody release
Guus
Holger: that's weird to me, as a message from Bob that was sent to the same recipient might arrive out of order.
MattJ
The others are just too risky, but people can use them if they want (from prosody-modules) (and they do)
MattJ
Despite no tests as to how effective any of these methods are on real traffic
Holger
Apart from that I try to dedup "state" things (presence, chat states, PEP), i.e. you only receive the current state. Mainly to avoid frequent queue flushes due to the queue size limit being exceeded.
Zash
Guus: The Mobile Optimizations XEP (or whatsitcalled, by Dave Cridland) basically says that too, "send a lot while the radio is hot"
vanitasvitaehas left
Guus
Zash: makes sense
jjrhhas left
Dave Cridlandhas left
Holger
Guus: Yes queued traffic can go out of order that way. I.e. Alice sent presence before Bob, then Bob sent a message, so you receive Bob's presence before Alice's. This stuff can be hairy with MUC joins, for example. Just don't do this 🙂
Dave Cridlandhas left
Zash
Holger: As I've said before, the rules for things like that quickly grow complicated
Guus
I'm now wondering if I should stop CSI support with dropping chat state notifications and the like only...
Holger
Yes. But you might consider the complexity with it to avoid frequent queue flushes.
Valerianhas joined
Guus
And not have a queue at all
Holger
*worth it
MattJ
Dropping chat states -> never drop "active", never drop if there is any other payload in the message (that isn't recognised as safe to drop)
kasper.dementhas joined
MattJ
Is that the only required logic?
Guus
Why not 'active' if there's no other payload?
MattJ
Because then someone could be typing, and then stop typing while I was inactive
MattJ
and then they would be forever typing
MattJ
in my client
Guus
I now have "drop messages that have no other child elements that do define a namespace, other than chatstates"
Dave Cridlandhas left
MattJ
So you would have the perpetual typing issue?
Guus
Yeah, I didn't think of that
Zash
Isn't what Holger says to keep the last one?
Zash
That makes sense
Zash
Like that module that does that for presence already
Guus
But, really, only dropping chatstates, really doesn't make a dent in the traffic
Dave Cridlandhas left
Guus
Zash: yeah, but that'd involve queuing which I think either is flushed all the time (rendering CSI effectless) or break RFC mandated ordering
Zash
I do think trying to group stuff into batches is better than trying to drop things
Zash
If we bring back Compression-except-safe, then it should be possible to squeeze in all them chatstates without using much data
Valerianhas left
Valerianhas joined
doshas left
mrdoctorwhohas left
Guus
Meh, this all is a bit disappointing. I kinda hoped for a silver bullet.
Dave Cridlandhas left
MattJ
Don't we all? :)
MattJ
But when was the last time anyone measured XMPP client traffic or battery usage?
Guus
Sooooo.... Would things be more effective if we explicitly let the client tell the server for what kind of data it allows the server to break the delivery order requirement?
karphas left
karphas joined
lskdjfhas left
MattJ
I don't think that's a nice thing to do to client devs
Guus
"only send me the last non subscription presence update for each contact that changed state after I went inactive"
MattJ
Complex protocol for something where basically everyone will want the same rules
Guus
Well, without that, they don't get any benefit from CSI.
MattJ
Just the rules aren't easy to describe or discover
MattJ
Single queue has benefit
MattJ
In theory
Kev
I'm not reading up for all the context, but ...
Kev
Is there any way we can get rid of CSI and instead disconnect when in the background and then get our reconnects to a sensible speed?
moparisthebesthas joined
MattJ
I'm not sure how different that is in the end
MattJ
E.g. if the server optimizes the 198 queue with the same rules
kasper.dementhas joined
Kev
I don't know. I just can't shake the feeling that both CSI and 198 Resumption are trying to work around a fundamental problem rather than address it.
Guus
Well, without SM you'd not show as online
MattJ
What if they are addressing it?
karphas left
karphas joined
Guus
Sorry, "available"
Kev
The issue being that getting current state is slow unless you were online when it changed, so we're trying to avoid going offline, with 198 letting us resume, and CSI letting us cut down the cost of being online.
Kev
But if we could solve the fundamental "It's expensive to catch up" issue, neither would be needed.
blablahas left
Guus
Kev: there's truth in that. Unsure if it's sufficiently feasible.
Zash
I think there's value in staying connected
Yagizahas joined
Kev
If it's not feasible I think we end up with significant issues anyway, because at some point you're going to need to fire up a new client, or an old one will get disconnected beyond 198 periods, or whatever.
Kev
It feels to me like we should look at what we really want to do on login (rather than what current protocol dictates we do), and see how close to that we can get.