XSF Discussion - 2018-12-21

jonas’, as per MattJ suggestion, I merged both -docker projects of the observatory into the original project. With that, I think we can drop the docker-specific projects, unless you object.

wfm

you need to take care to setup the docker hub thing though

ehh... I'll try 🙂

I've also invited xnyphs, btw.

maybe create a corresponding xmpp-observatory account on docker hub?

Guus: thanks! How did you deal with the submodules?

MattJ what submodules?

(I did not)

Ge0rG, did Gajim not work?

Link Mauve: I don't know

Why did you recommend Pidgin over it then?

Link Mauve: I'm speaking of the listing at https://xmpp.org/software/clients.html which I wanted to be a list of *actively maintained* clients.

And out of all of the actively maintained clients, you picked Pidgin?

but then somebody submitted Pidgin, and because we are neutral, we can not resist its addition, despite everybody on our side knowing how harmful it is.

Link Mauve: no.

Oh, now I understand.

Sorry.

Guus: no worries, I'll figure something out in the Dockerfile I think

@mattj, i just finished setting up docker hub builds for both projects

do you have an account there? I'd like to add you.

Thanks!

mwild1

added: https://cloud.docker.com/u/xmppobservatory

Got it, thanks

I think that's about what I know what/how to do

I didn't remove the old -docker projects yet, but that can be done now, I think.

Don't yet

maybe I'd be good if you verify first that I didn't make to many obvious mistakes.

Pretty sure the new stuff will not build correctly yet

It was using submodules for pulling in some dependencies

unsure if the migration thingy I used merged those

I didn't notice hg submodules (nor did I check for them)

I'm not seeing a .gitmodules, so it probably didn't migrate.

I don't remember what they all are, but at least one of them we were going to drop, and probably any others should be too

Some were hg repos, so it would have needed to migrate those

Can I leave this in your capable hands?

Which wouldn't be ideal anyway, since they are separate projects I maintain in hg

Sure

Thanks. Do we need submodules, or can we use a shared artifact somehow perhaps?

If needed I'll just make the dockerfile clone the dependencies itself

for what its worth, that already seems to happen a lot

What's probably not ideal is that the dockerfile clones https://bitbucket.org/mattj/xmppoke 🙂 ✏

(I blindly merged the projects, didn't update any references)

Is the call for logo design published anywhere? I've had a logo designer asking me about redoing the yaxim logo some months ago, but I like my logo very much so I'd rather ask them to do something for the wider community

jonas’ should we move the xmppoke-queue project too?

Ge0rG I don't believe that there's an explicit call, no.

Ge0rG I suggest you coordinate with nyco, who had a designer of his own in mind.

Will there be one?

What would be the best non-ephemeral venue for that? issue on github/xmpp.org?

Board didn't discuss that, so I guess not? Is there a need for such an explicit call?

the mailing list, perhaps?

Guus: standards is obviously not the right place, members is for members only; there is no public ML suitable for that.

You are more precise than I am in these things 🙂

I don't think we need to send out such a call just yet

I'm going to first wait that nyco comes back with

ralphm: alright. I was just assuming that volunteers might have some time between the holidays

If people want to volunteer, they can, I just didn't think we needed to put out a call for it.

Also, I don't think we have minutes for this Board meeting yet. Someone volunteering to do those would be awesome.

MattJ I ran into those modules you referred to. I worked around them being gone in git by pulling them in through the docker file, as you suggested: https://github.com/xmpp-observatory/xmppoke/pull/1

when running things locally, I see that xmppoke is invoked when I start a test through the frontend, but it stops immediately.

Test

a-ok.

ralphm: Still in need for a minutes writer?

erkanfiles yes

erkanfiles: 👍

So I only have to scroll up in this MUC or where to find the content?

erkanfiles: the official log is at http://logs.xmpp.org/xsf/2018-12-20#14:28:50 - in case you don't have full history in your client

K

Where may I submit my results?

erkanfiles: they are typically sent to board@xmpp.org and members@xmpp.org (which are probably both members-only) and you can pastebin them in case you want a second opinion.

So I couldnt join because of not being member, right?

stupid question. someone recenctly send me this <message><foo:bar>hi</foo:bar></message/>. is this valid xmpp/xml?

daniel, if an xmlns:foo="something" has been defined on foo:bar or any of its ancestors. ✏

what if it is not?

Then it’s invalid XML.

because : is a reserved char that can not be used for element names even though xmpp doesn’t use that kind of namespace prefixes?

: in an element name means that what is before : is a prefix, that must have been bound to a namespace, and what is after is a local name to this namespace.

Link Mauve, only if you’re talikng XML 1.0 + Namespaces

in vanilla XML 1.0, you can use : without namespaces

jonas’, isn’t that what XMPP is using?

jonas’, uh, really? :|

I wasn’t aware that XML could be used without support for namespaces.

yes, XMPP uses XML 1.0 + namespaces

it can

but everybody luckily forgot about that

jonas’, so is this or is this not legal in xmpp?

Note: The Namespaces in XML Recommendation [XML Names] assigns a meaning to names containing colon characters. Therefore, authors should not use the colon in XML names except for namespace purposes, but XML processors must accept the colon as a name character.

daniel, it is not legal if there isn’t a namespace declaration on the <message/> for the foo prefix ✏

jonas’, or on the stream:stream, or on foo:bar.

Link Mauve, not on the stream:stream

Why?

XMPP

Namespaces declared in a stream header MUST apply only to that stream (e.g., the 'jabber:server:dialback' namespace used in Server Dialback [XEP-0220]). In particular, because XML stanzas intended for routing or delivery over streams with other entities will lose the namespace context declared in the header of the stream in which those stanzas originated, namespaces for extended content within such stanzas MUST NOT be declared in that stream header (see also Section 8.4).

https://tools.ietf.org/html/rfc6120#section-4.8.5

but yes, it can be on the foo:bar itself, I missed that

jonas’, ugh, that sucks.

I was very sad when I learnt that because I intended to declare all the things on the stream header :)

I didn’t know that.

mhhh ok

daniel, in any case, your server sent you somewhat malformed XML

jonas’, can you disable namespace support in most XML libraries?

Link Mauve, most come with it disabled

i mean you are all confirming what i assumed was the case. but in any case it makes this https://github.com/siacs/Conversations/issues/3315 weird

expat and libxml at least

you have to enable it

and/or very annoying to debug

jonas’, oO

TIL.

> Ge0rG> Guus: standards is obviously not the right place, members is for members only; there is no public ML suitable for that. I would also like to have such a place tbh. I've been wanting it for some time.

Link Mauve, in expat you have to set a flag IIRC

I don’t remember having to do that from Python, but maybe.

daniel, ejabberd bug

Link Mauve, the high-level python stuff does it for you

jonas’, a known one?

the xml.sax doesn’t

i'd be rather surprised tbh

daniel, not as far as I know, but I’m not surprised ✏

I’m not

the namespace support has been sketchy since ever

in ejabberd

daniel, “<{null}jabber:x:oob>” sounds like their serialiser did something clearly wrong.

I remember a similar bug being present in Prosody 0.5.1, fixed in 0.5.2.

oh you mean that new compress thing?

(What a blast from the past!)

Link Mauve, not clearly, I wouldn’t dare to interpret the output of that XML parser logs

it might be some clark notation gone wro... no wait

that’s weird

but s till

without seeing the raw bytes, I wouldn’t blame the serialiser that much for now

jonas': Namespace handling has been rewritten a while ago, but of course there may still be (new) bugs.

yeah it's not easy to get raw bytes from my parser

sigh

*although* the error message indeed sounds like a huge messup

Maybe on the other end, it’s easier to get Ejabberd to dump what it’s going to send?

it looks as if <jabber:x:oob/> was generated

Yeah.

yeah that's why i was asking for <foo:bar/> initially

which is wrong, and that ejabberd lets it through to you is also a bug

i don’t think that the {null} is on the wire

Holger, mhm

back then™ when I broke ejabberd’s namespace stuff it was still on that other bugtracker

Heh, there's probably no line remaining of the code you broke :-)

that’s probably good

I recall the breakage to be terrifying

ah yes, it swallowed IQs https://support.process-one.net/browse/EJAB-1661

good ol’ times

this one was also fun: https://github.com/processone/ejabberd/issues/814#issuecomment-153015288

jonas’, that last one is valid though.

It should be parsed to the exact same thing by a namespace-aware parser.

I am aware

otherwise I wouldn’t have complained :)

Are you a parser?

Are you?

I might be, but I'm not fully namespace-aware

jonas’: Hah, so it was your issue that triggered the initial rewrite I was referring to.

the IQ one I didn’t open

I just came across it

I meant the second one.

the Simple Buttons discussion made me realize that we don't have Data Forms in the suite.

ralphm: I could provide that current minute on wednesday. Is that in time or is it too late?

We meet on Thursdays, so that'd be fine!

Really happy about someone volunteering

Guus, I *think* you said the same thing I said in my email to. Where was I unclear?

I tried my best to pick words which don’t make Board seem like the booman here, and which don’t put words in Boards collective unison mouth.

jonas’: I think you left one part of the reasoning out. Anyway, I wanted to stress that I don't believe you were trying to push people.

ok

I can live with that :)

right, I only brought the second part up in a side note ("[…] and to the community for the extra noise and possible temporary confusion and misguidance due to the published compliance suites you had to endure.")

Ah right. I read that slightly differently. Oh well.

overcommunicating is never bad

jonas’: I think I prepared for all changes needed to move over to the new observatory repo

uh

I’d like to postpone this until after the holidays to be honest

we’re going to be on the rails tomorrow and there’s some preparations to be made

HOLIDAY SPRINT

Care to review the PRs?

Ah ok, fair enough 🙂

aand it will hvae scrolled out of my inbox by that time, so pinging me about that in a week or so would be wise

👍

Just noticed my emails... so Buttons is accepted?

or are there still outstanding votes?

U want <button xmlns="urn:xmpp:tmp:buttons"> <onclick> <json xmlns="urn:xmpp:json:0">{"payload":"100MT-nuke","target":"earth"}</json> </onclick> <label xml:lang="en">Big Red Button</label> <label xml:lang="sv">Stor Röd Knapp</label> </button>

?

No?

Are you being sarcastic or why is this so hard? :)

The whole point is that the buttons are shortcuts for pieces of text

Which also makes the points about i18n rather dubious (as I wrote to standards@)

yeah i agree the i18n argument is a bit overboard, i never saw bodys with different langs

lets be honest, almost no one makes use of that lang feature

Right. Last I checked was quite some time ago, and it was not handled very well in clients

which allows many fun things :)

i get its nice to have it defined with the base xmpp spec, so if there is a usecase someone does not have to invent his own stuff, but not every XEP will be able to fully be i18n compatible, and seeing that one of the most important xeps like dataforms is not useable with i18n, lets me think, can this even be done?

Is there a XEP on how to handle i18n?

lovetox, in most cases dataforms are actually usable with i18n, because you transmit the xml:lang in every stanza you send the responder is able to setup the translation domain correctly.

For buttons it can’t be done that way, because the main point of using it is through a MUC.

So there is no sender/responder.

The main point?

You still get presence from everyone, so you can do ... something

Zash, didn’t you define it so it would work in a MUC?

Zash, well, not really, say half of the people here advertise an @xml:lang of en, then some fr, some de, some ru, some sv, etc.

also a MUC has in most cases one language

there is no need for translation

Link Mauve: I tried to make it like it works elsewhere in XMPP wrt i18n, which allows multiple <body xml:lang=*> and such.

lovetox, yet in many cases it allows more than one.

Zash, yeah, that’s fine.

also from where should the sender have the translation?

yeah for Yes and No, its likely he has it

Is that in scope for a protocol?

but the moment you let the user choose the labels himself, there is no chance he has a translation ready

I imagined this would be from bots mostly

Eg Memberbot

point is, you can make it super i18n compatible, in reality for the MUC vote case, and thats probably what this is beeing used for, there will be no translations

Allowing for translations doesn't prevent use when there are none

yeah and Memberbot wants to ask a new question, and then you make a git repo and ask people to translate your memberbot questions into 10 languages or what?

lovetox, yeah, that’s how it’s done in most software.

You have a list of supported languages, translators do the translation work, you often pull them back in your software, and then users can use it in any language they want.

thats the point, its not part of the software

the bot allows to ask all possible questions at any point in time

it would be better to use google translate api

Haha.

That’s just one of your usecases, you don’t need to limit the protocol for other usecases.

i dont want to limit it, but it should also not stand in the way

Is it currently standing in the way, in the current proposal?

i hope not, i didnt follow the discussion until the end :)

for me this is fine, translate the buttons if you want

but translating the value seems wrong