XSF Discussion - 2019-04-06

pep., what is the fail?

Oh is that not a fail? Lifecycle on the right? If not then I'd say it's missing a bit of margin maybe

it’s not a fail, it needs a bit of padding, yes

pep., FWIW, the terms come right from XEP-0001, you’d have to take it up with XEP-0001 to change them :)

Yeah but I have no idea what to replace them with

I like "Living Standard" for Draft

now for the fun part

can someone tell me where https://xmpp.org/extensions/xmpp.css comes from? It is **not** in the attic container (<https://github.com/xsf/xep-attic/>)

cc @ Kev, MattJ

derp

Sorry, I don't know the answer and I'm currently on my phone

hm, so you probably also can’t help me with the fact that https://xmpp.org/extensions/xmpp.v2.css 404's

(despite being in the xeps docker image)

I pushed a hotfix against the presentational issue, I still need a permfix on the server level

(and the hotfix will take 2h or something to deploy)

jonas’, Ge0rG: just for my notes: why was https://github.com/xsf/xeps/pull/752 considered not a good idea?

flow, I edited to link minutes + logs

jonas’, thanks :)

We probably should make sure that the "Application Specific Errors for MUC" are going to get defined some day (all of them being optional as long as we don't want to bump the namespace)

announced via a separate disco#info feature, yes

> Georg proposes that Jonas writes a separate "Application Specific Errors for MUC" XEP, for having instigated this mess (with the original discussion.) 😁

jonas’, I am usually not against adding more disco#info features, but is there any advantage besides statistics in this case?

flow, not sure

it gives clients more information about what an absent application specific condition means

(undefined vs. server doesn’t support it)

alternatively, we could have a <undefined-muc-condition/> thing which is always sent on MUC errors if the XEP doesn’t override it

that’s nice because it’s zero-roundtrip

wouldn't you still need a feature to determine if the server is going to add <undefined-muc-condition/>? Also what if a condition becomes defined later on?

for the first question: no, you’ll find that out when you receive an error

Not sure if optimzing for zero-roundtrip is a worthwile goal here

for the second question: then it gets a new condition (and the <undefined-muc-condition/> vanishes of course), I don’t see a problem

I don't see a problem right now too, just wondering

ok

jonas’, the important question right now is: When will you write the XEP? ;)

I think "if" is the more interesting question ;)

Well if the answer is no, then I would consider taking a shot. Collaboration is welcome of course

oh, go ahead please

taking a shot and stealing your ideas, of course

I don’t have it high on my agenda at the moment

(I actually 99.999% forgot about it until you mentioned it ;))

hotfix landed

enjoy our new XEP CSS live

jonas’: The question above, is it urgent? I don't want to look at it right now, but will if things are broken.

Kev, for the attic, it’s not that urgent

Ta. Poke me Monday then, please.

the xmpp.v2.css 404 was urgent, but by now another docker build passed with a workaround from my side.

we can discuss it monday, too

Jonas, the "this document in another format" XML button directs me to a 404.

https://igniterealtime.org:443/httpfileupload/3877f403-13bf-4374-a2dc-ed5d05681b62/SuD4T4inSqWbvnDa2sAG2w.jpg

ha, it probably always did that

(I didn’t change it)

well, "always", since the server crash

Pdf does work

yeah

Yeah, I never tried that before. 😁

Maybe remove the button if fixing it is more effort?

fixing it should be easy if I can get hold of iteam

ITYM "HTML" ✏

I don’t think so

Should a html button be added? In case the document is copied somewhere, to have a reference to the original one? ✏

K.

I love the way this turned out. Thanks for putting in the effort!

:)

We should tweet about this

Anyone able to do so now? If not, I'll find a laptop.

I can’t, but good idea!

I can, but not from mobile

I'll find a laptop.

jonas’: what do you consider key improvements?

Hey jonas’, I see your changes are now live, I haven't been able to follow all this. Nobody mentioned anything about the blue color for headers or the blue background color for the code-example class?

Guus, left-hand TOC on large screens, modernised HTML and using an award-winning responsive CSS framework ✏

Seve, noone did indeed

It must be me then, the only one missing those :D

Looks really good, thank you very much jonas’ !

:)

Guus, while you’re at it, the newsletter hasn’t been tweeted yet either

uh, and it’s still using the old (unfixed) logo as avatar

sent out two tweets

Guus: you missed the link to the extensions 😉

I didn't

I'm guessing that top level links are better SEO wise, but unsure

It was a deliberate choose, in any case. 😉

Welcome guys

No body?

Hehe

Yes <body/>

Good day

pep., hey man

pep., you programmist?

I think this room for programmist

Seve, wow, new face

Seve, I am not talk english language

Seve, have jabber bot translate for me?

Translater*

I am from in russia

I am walk this room

Seve, hey man

I am look they

fire: this chat is not meant for casual "whats up man" chatting. It is intended for talks around the xmpp standard. In order to allow busy folks to follow the important conversations, please keep the non-standards talk to a miminum.

Don't sleep, don't sleep, don't sleep everybodu

Everybody*

fire, Этот чат не предназначен для случайных чатов. Он используется для обсуждения стандарта XMPP на техническом уровне. Пожалуйста, перестаньте говорить о вещах не по теме, чтобы занятые участники могли следить за важными вещами, которые написаны.

vanitasvitae, I am understand, can you help me go in casual chat?

no, but it would work similar to how you joined this chat

I can't search casual chat

fire: https://search.jabber.network/rooms/1

Mikaela-, yes, thank you man

Mikaela-, this cool

jonas’: I'm seeing that a bit late, but thanks for the new design, it's neat.

:)

thanks :)

Yep excellent work on that, I'll avoid the unnecessary highlight

thanks

xep-0166 v0.30 "Clarified that session-accept action accepts only the content definition(s) in the session-initiate." does anyone know why it was removed in next versions?

I'm pretty sure that version predated the content disposition attribute. So that behaviour was to handle what would now be early-session disposition contents

Current behaviour is session-accept only accepts content with disposition=session

content-add hs other disposition by default?

nope. default is always session

its all related to https://xmpp.org/extensions/xep-0269.html ✏

hm. well I'm just trying to decide what's better while I have peding incoming session and remote adds more content before I accepted the session. a) send content-accept and skip this content in session-accept later b) don't send content-accept and accept everything with session-accept

its a matter of user intent here. if the user hasn't accepted, then let it get included with the session-accept

you would do a content-accept before the user accepts the session only for this early-session stuff

If accept everything in session-accept it becomes possible an user may accidently accept undesired content

I didn't read early media xep before

early media is mainly for interop with telephony stuff

it's like remote music instead of beeps ?

yeah

but yeah, determining what is being accepted is a small pain. and would need to be handled higher up

like, don't enable accept button until after small delay from any content-accept

jonas’, btw, there's no way to not display the index? At least not without JS I assume?