XSF Discussion - 2017-02-21

intosi: we are in need of your magic powers once more!

The website is missing two resources, but it is in /extensions/ which is outside of my range of influence

https://xmpp.org/extensions/xep.ent should serve the file in https://github.com/xsf/xeps/blob/master/xep.ent https://xmpp.org/extensions/xep.xsl should serve the file in https://github.com/xsf/xeps/blob/master/xep.xsl

(I will "pretty please" if it helps)

Consider it done if you put sugar on top.

pretty please with sugar on top

I'll undo the fix if you dare ;)

0;-)

Does anyone know what this issue is about? https://github.com/xsf/xmpp.org/issues/43 ralphm?

intosi: now it complains about a missing xep.dtd, which can be found in the same place. Could you do that one too, please?

(relates to https://github.com/xsf/xmpp.org/issues/196)

Sure

right, now it shows somethign

intosi: two new 404's: pretty.css and pretty.js - these shouldgo in xmpp,org/ (root) though, not in xmpp.org/extensions/

Guus, or we change the XEP html to have them in extensions? instead of requiring tons of URL rewrites in the server

Or that.

Tobias: I am fine with any improvement, but currently, I'm pushing for the easy fix, which is something that we can do *now*.

pretty.js? Don't you mean prettify.js?

prettify, indeed

both css as well as js

And where are these referenced from?

You'll notice the 404's whenever you open a url like this one: https://xmpp.org/extensions/xep-0300.xml

the xml is loading the xsl, which in turn references the dtd, css and js, I suppose.

Guus: I don't, in fact. I see 200 responses there.

Guus: even though we do have a page at that URL now, the original tech pages were more detailed: http://web.archive.org/web/20150313010246/http://xmpp.org/about-xmpp/technology-overview

Because they load /extensions/prettify.js

;)

wuh? it works for me now

Guus: I get "undefined entity" &LEGALNOTICE;

weird caching issue, I think

Yeah, after I added redirects.

ah, ok

But I'd rather fix the stylesheets in the longer run.

jonasw: feel free to suggest improvements :)

intosi: agreed: but at least now, we have a non-empty page

Right. Back to $DAYJOB

likewise

thanks for the help

np

yw

Guus: I’m not sure what the cause is. According to debugging tools, all resources are fetched freshly, but then again, it doesn’t even try to load xep.{dtd,ent}. I blame Firefox’ XML/XSL support.

force-clearing the cache doesn’t help either

jonasw: tried another browser?

on my way

works with chromium

If you ever figure out what makes it work on firefox, please open an issue on github

I’ve never used the XML versions, so I’m not sure if that’s a new issue

it likely is not new. Does not mean we shouldn't improve if we can :)

It never worked in Firefox for me.

FWIW

is it sensible to have a version of the XEPs around which don’t work in a major browser?

Does in Safari and Chrome now.

Prettify.js throws an exception on line 31: Uncaught DOMException: Failed to set the 'innerHTML' property on 'Element': The provided markup is invalid XML, and therefore cannot be inserted into an XML document.

(although I’m not sure if firefox is still a major browser…)

not sure if that's related

Guus: firefox doesn’t even get to the point where JS or anything is loaded

it fails XML parsing

jonasw: that might be presentation only. Did you try to look at the source of that page?

Due to missing entity references. Doesn't try to load the ent file.

intosi: or the DTD for that matter

Or that.

Chromium warns about wrong mime-types too. the xsl is transferred as application/octet-stream

anyways: day job.

There's a feature request open for Firefox but right now it doesn't support loading external resources in an XML file.

XML resource redirection is an old vulnerability vector

We are down to a one-page issue list for the website :)

(no, this is not intended as a challenge to get it longer again)

Feel free to resolve another few though

Guus: You don't want any further issues reported eh?

No. The website is perfect and flawless as is.

People that report issues are spreading fake news

sad.

Oh wow. Our lower house has just voted to legalize growing of cannabis.

Contrary to popular believe, that was illegal here. You could legally sell it, but not grow or buy it in bulk (nice, no?)

s/was/is/

As in, the non-industrial kind?

the industrial kind.

(coffee shops in Amsterdam got to get their produce from somewhere, right?)

There has been a weird non-enforcement policy. The violent crime related to cannabis cultivation is pretty high here.

(and by industrial I mean the kind with less psychoactive stuff, grown in some places at an industrial scale for the fibers)

ah, no, I was referring to commercially growns stuff (vs home-grown) for recreational purposes.

Given all of the discussion about bind2 and preserving client info for debugging, should we revisit and advance https://xmpp.org/extensions/xep-0232.html ?

> <identity category='client' name='Exodus' type='pc'/>

Lance: What they want is a persistent identifier for the device itself, not more verbose client description (As I understand it)

client or device

I'm wondering about adding an attribute on the opening stream header for easier tracing

Then it can be visible even before you auth/bind

Zash: what kind of attribute?

Ge0rG: <stream:stream [...] xmlns:trace="urn:example:xmpp:trace" trace:id="yaxim-xxxxxx">

Zash: +1

And get rid of client assigned resources (even in parts) once and for all

+1

If we get rid of client-assigned resources, I'll do my best to prevent Ge0rG from ever seeing another UUID

I see no need in changing the current spec however

Zash: current as in regular bind?

daniel, btw, just to confirm I saw your post about 313 and MUC <x> elements - going to have a look at that tomorrow. I remember we chatted about it a while back

Yes regular bind can stay

daniel: aren't you the one with the broken client-generated resource implementation? :D

Ge0rG: I believe you can do the above Right Now if you wanted, pretty sure it shows up in debug logs. No idea about servers other than Prosody however.

Ge0rG: And it would work earlier.

As in, before bind/auth

Zash: I want that trace:id to be in all log lines affecting that client please. even MUC debug messages on the MUC service.

daniel: I mean the rules (client can suggest something, server picks something). I'm sure bind2 can improve the protocol and make things better.

Ge0rG: i belive Conversations is one of the few clients that show the disco name when it comes to resource selection (for jingle or otr)

Zash: I don't see the benefit in a client suggesting something

daniel: Don't suggest something then.

daniel: how is that an answer to my question? And how does it work with multiple instances of the same client?

daniel: you can just admit it and pretend to be ashamed, and I'll leave for the night ☺️

Outside of client developers, how many have multiple instances of the same client?

Suppose you can show timestamp of last stanza received from each resource.

And other presence details

Well I guess the ultimate goal is to never show that resource selection at all

And instead use message initiation for jingle