XSF Discussion - 2018-10-14

dedekin, that is not (yet) a statistic evaluation, just a single shot. I'm also not sure how meaningful the numbers regarding compression are, as I wonder if compression achieves very good results in the initial connection phase as the user's XMPP domain occurs very often

flow, does this take into account the requirement to flush the compression state on each stanza?

jonas’, not on each stanza but on each channel change, and the with compression above is using sync flush after each stanza

with compression full flush and with tls recv: 9827 send: 6360 recv-aft-filter: 21594 send-bef-filter: 5677

those are the numbers with full flush after a channel change

sure, channel change is harder to implement, so I’d like to see the "worst case" numbers here :)

but that is still pretty good

Those are important inputs for the deprecation discussion in Council

flow, which server implementation is this against?

ejabberd 17.03

aged, but neat

jonas’, ^. But I'm curious, do you expect a behavior change depending on the server?

zlib being zlib for ages

flow, I was just curious, because prosody e.g. does not implement per-stanza/channel flush

jonas’, well I doubt that ejabberd does this. so the full flush is probably only performed by smack

oh

that makes the recv number entirely irrelevant

(which is what I was looking at)

and the send number isn’t that impressive anymore

that is why I champion that we make that feature negotiable in xep138

which feature?

full flush on stanza/channel change

I am massively against making that negotiable

it’s a requirement to implement compression securely

well only if you use tls

there are use case for xmpp w/o tls

are there still?

also it will likely be negoiatable in the end anyways

because the current "zlib" mechanism does not specify this behavior

indeed

it might be indirectly negotiable by a namespace bump

so you either add a flag to xep138 or the specific compression mechanism xep, or register a new mech like zlib-full-flush

I think all mechanisms need that type of thing, so bumping the NS of xep138 entirely to require this seems more reasonable to me

I wouldn't require it, just as there are use cases for xmpp w/o tls, there are use cases for compression using only sync flush

I'm not sure there are still use cases without TLS in 2018

http://neverssl.com

TIL https://xmpp.org/extensions/inbox/calendaring.html; Any idea what happened to it?

Apparently https://mail.jabber.org/pipermail/council/2009-April/002540.html says: Consensus to delay until after discussion with calendaring people - Dave to instigate.

https://mail.jabber.org/pipermail/council/2009-April/002546.html has some followup

It'd be great to have all this feedback somewhere easily discoverable

pep.: Shush, you'll wake up the people who want to switch to discourse.

at this point, it's far too late for that, caldav won

xmpp doesn't have to do *everything*

Zash, I'm not sure discourse is really better

moparisthebest: I think you'll find that Google Calendar won. Even I haven't ever used CalDAV.

doesn't google calendar talk caldav?

I do use CalDAV fwiw

Not that I've been in large enough organizations to need a dedicated calendaring system on that scale

I've used nextcloud on server and davdroid on phones since 2013 when I abandoned google

pep.: Seen IETFs thing? https://mailarchive.ietf.org/arch/search/?q=draft-ietf-kitten-pkinit-alg-agility

What are you trying to highlight? Is that related to Calendaring, or discourse, or?

pep.: Email archive/search thing

I see. Well it's not just about emails, we have lots of different channels

email, github, XEPs, XMPP, ???

github is not supposed to have discussion

Maybe not discussion, but changes

I think ideally I'd like to have that displayed somewhere alongside the XEP on xmpp.org

I was more thinking of the why/why-not of the changes

I have a vauge memory of someone working on something like that

https://xmpp.org/extensions/xep-0099.html anybody ever used this?

CRUD over Iqs

Or this, https://xmpp.org/extensions/xep-0101.html, I wonder how much overlaps with 0070

It seems to be the other way around? Instead of having the http server ping the xmpp server (that will ping your xmpp client), you go get a token from your xmpp client, that you then give to the website?

> Ge0rG> Those are important inputs for the deprecation discussion in Council

I doubt that those provide a solid foundation for such a discussion

SamWhited, there are 70 occurences of "meta-data" in the whole repo, I can sed them all :-°

it'/its was a bit more work

pep. even better! I just noticed those two and figured we might as well keep future diffs small since you were already editing those lines anyways, but might as well grab all of them I guess :)

Good job on the its/it's

I haven't touched inbox/ btw, not sure how that works in there, also not sure if XEPs I would have been edited are already accepted or not

err, I missed one

muclumbus/jabber muc search now lives at https://search.jabber.network/ :-)

SamWhited, that sed was a bad idea..

"meta-data" is used in normative parts as well :(

ah, too bad. I wouldn't worry about it then; might as well just fix the two that were in lines you were touching anyways and then if we want to dig through later and find the rest we can