XSF Discussion - 2017-09-29

moparisthebest, there’s always git commit --allow-empty

Guus, merge the new favicon? :)

jonasw: wilco

was giving others some time to react

\o/

hm, firefox doesn’t show a favicon anymore

ah, now it does

you can see the difference on the favicon ? :D

sure

my tabs have dark background

the new favicon has transparent background

instead of white

:)

indeed

Yeah, the missing white square is quite visible

(as is the alignment change)

Supposedly, this now looks good if you drag/drop the address as a tile in your favorite brand of touchscreen device.

(but I didn't check for that)

I get 404 on https://xmpp.org/favicon-16x16.png and https://xmpp.org/favicon-32x32.png

but https://xmpp.org/favicon.ico seems to exist

ah, those are likely missing redirects

we keep those in https://xmpp.org/icons/favicon-16x16.png etc

(unsure why)

that's odd. It appears to be a pelican-based redirect?

Simply fixing the template to have the correct paths seems more sensible to me.

https://github.com/xsf/xmpp.org/pull/371 should fix it

anyone want to have a quick look?

hmmm, I might've jumped the gun there

I don’t think that’ll work with pelican

you need to declare static directories

and declaring content as static won’t work/blow up everything

now all we need to do is to find out why the XEP list is incomplete

jonasw: Yeah, i found that myself. I've revoked that PR, and created (and merged) another

I'll need to leave in 25 minutes, with many things to do until then.

I'm afraid you're on your own for the XEP list for today

I see

meh, I was hoping it would magically work

that XEP list still frightens me

I can imagine

I do not understand how that is run in docker at all. the docker build never invokes buildCompleteWebsite.sh

jonasw: I'm finding that the extensions root points to a temp dir

where the initial crash recovery took place

want me to remove that real quick?

dooont

I bet that file isn’t built

that’d explain what I’m (not) seeing in the xmpp.org repository

the build script is not invoked at all, if you remove that we won’t have any list ✏

(now at least it makes sense that I don’t find the invocation of the build script, thanks for taking a look)

I’ll then figure out a cheap way to generate the XEP table with the docker things

ok. it's line 83-85 in the xmpp.org nginx config file on eos. Any iteamer should be able to help you

thanks

I'll be offline during the weekend

okay

have fun

well, on mobile

tx

Tobias: ping about https://github.com/xsf/xeps/pull/508#issuecomment-331070510

Ge0rG: How is "Battery saving (CSI) and push have different rules again" a problem?

Flow: it's a matter of consistency

Flow: also, nobody quite knows which rules to apply for push and csi

What would be better if they had consisten rules? Besides CSI deliberately specifies no strict rules at all (which is a good thing IMHO)

Glad someone agrees with me :)

I mean it's not an easy thing to answer. It's one of the fields where experience from running code really matters

And something we eventually don't have to solve together with all the other more important and relevant issues you mention

Agreed. It's also not an easy thing to specify, and unclear what the interop failure by not doing so might be.

ie, it's a QoI issue. Some servers might be "better" (or at least more suitable for the client application), but everything should work one way or another eventually.

Flow: https://prosody.im/issues/issue/973 and check mod_csi_battery_saver source code for the many exceptions

Ge0rG: I fully aggree that it's important that we research working rules for CSI and Push. I just wanted to say that I don't think that those rules are necessarly the same, and that it's not an issue we should focus on right now

Ge0rG, a couple of notes on that: it's still experimental code, and that report from you is good and healthy so we can improve the rules

Flow: I never claimed I have the solutions

The alternative would have been encoding all these rules into the XEP without prior experience

Ge0rG: I would never insinuate you to have solutions ;)

and once encoded, never being able to iterate on them and innovate

I do wonder if Session 2.0 and Bind2/SASL2 are two distinct steps into the right direction

(but maybe I should read the slides to the end)

Flow: I'm pretty sure that CSI and push have the same underlying principles

Maybe, maybe not

Hrm, Message Routing 2.0 sounds a lot like XMPP 2.0

Flow: we decided to rename XMPP 2 into MR 2 to show it's not a complete reinvention of everything

Probably a good idea

dwd: "everything should work one way or another eventually." is something I'd rather like to avoid, because then we'll end up with even more hairy corner cases.

Ge0rG: What happens in MR 2.0 with messages send to a full JID which is unavailable?

And is MR 2.0 also signled on s2s links?

*signaled

Flow: MR2 should be also signalled on s2s, yeah. And messages are errored back

s2s MR2 will just follow the same semantics, and convert to MR1 clients

Ge0rG, CSI explicitly is not allowed to change the semantics of the stream, only introduce delay.

dwd: I'm not sure what you are talking of

dwd: BTW I've published a new version of compare-and-publish and send a mail to standards@, not sure if you saw it yet. As always, your feedback is appreciated.

MattJ: I'm okay with the rules being worded as MAY everywhere, as long as they are comprehensive according to current state of the art, and not the mess we have in 0280 now

I don't think the CSI and Carbons situation is comparable

Flow: I'm talking about bad wording.

Flow: and yeah, session2 and bind2 are distinct steps