XSF Discussion - 2019-08-01

hm about MUC exiting a room

say im sending a join presence to the room, and before the room sends me the roster i send a unavailable presence

should the server still send the roster?

can i leave a room when im not fully joined?

is probably the question

lovetox: You can of course send the unavailable presence before being "fully joined", but must expect traffic from the room until you got the unavailable response back.

yeah i know that the server probably queues the presences before he receives my unavailable and can not remove presences from the queue in time

but does ejabberd even try?

i think about this, because when entering a room with a captcha

server sends no roster until captcha is solved

If I understand you correctly then the answer is no. ejabberd just receives requests and responds to them. You want it to double check whether there's another request before responding to the first one? That would seem wrong to me.

so it should respect my unavailable if i cancel the captcha challenge ✏

Ahh, so the story is kinda different.

ejabberd does not respect unavailable within a captcha flow, also not captcha canel message

instead it has a 1 minute timer

that sneds a presence error when the captcha is not solved in that time

but i wonder if i should care ..

i dont think it causes any problems ..

lovetox: Shouldn't the client abort the CAPTCHA thing as per XEP-0158, in that case?

> The sender's client MUST respond with a <not-acceptable/> error in any of the following cases: [...] if the sender declines the challenge

i do this, but as i said above, it does not have any effect on ejabberd

Ah "also not captcha cancel message", overlooked that.

what i would expect is, after cancel to get a presence error type=auth or something

Yeah that sounds wrong to me.

Yup.

Who does room CAPTCHAs anyway ;-)

yeah so now i get the presence error 40 seconds later because it runs into the timeout

But yes maybe post an issue if you're motivated ...

i dont see any problem getting it later though

i dont see how that delayed error would cause any problem

its basically a nitpick at this point :)

Yup but I guess you're right.

First I was thinking about the ugly workaround where you send a presence-unavailable _right before_ you join the MUC, to make the server realize that you acutally are joining it and not just updating your existing presence.

XMPP at its best.

Holger, that’s been fixed, but some servers still don’t implement MUC 1.29. :(

Damn, two years ago already.

no servers implement Carbons 0.13

Well, in fact XEP-0045 was always written that way.

Life is sad.

Just that 1.29 made it clearer.

Ge0rG: I have a server implementation, including the extra namespace.

Kev: is it public?

No, it'll appear in a future M-Link release, it's not released yet.

Ge0rG: Oh I missed that. I'll add that to ejabberd.

Kev: will that release be running on jabber.org? :D

Not unless Peter changes his mind :)

Holger: would you come with pitchforks and torches if I also mandate forwarding of message errors?

BTW, I'd like to make message errors non-ephemeral in general, so that they end up in MAM and in Carbons.

are server developers going to kill me for that?

Right, I was going to mention that the rules for MAM + Carbons should be in sync for such things, otherwise I wouldn't quite see the point.

Holger: I've been asking that for years now

Other than that I tend to be on the "store everything" side of the fence, so I for one won't kill you. Plus you live too far away now anyway.

Ge0rG: I know. It's not like I objected ;-)

> it is of type "error" and it was sent in response to a <message/> that was eligible for carbons delivery (Note that as this would require message tracking and correlation on the server, it is unlikely to be generally appropriate for most implementations).

Holger: this part of the new 0280 rules was heavily objected

Ge0rG: I mean for some things there are probably better solutions than cluttering the DB. But cluttering is better than what we have now.

It's generally not forbidden to CC _every_ message error, and I'm not even sure it would be harmful

CCing message errors from a MUC might be interesting, though.

Indeed.

I'm on the road, but will try to follow the board meeting

o/

Hi MattJ

Guus?

here!

Does someone else want to chair? I'd like to unvolunteer myself this week if that's ok

Seve, you want to have a go?

is @nyco not here?

Apparently not

Seve?

Sorry :)

I'm fully back now

please act as our chair if you want to. 🙂

Let's go

Welcome

<3 Seve

I guess it's three of us, MattJ, Guus and me

with Ralph on the backburner.

Do you have something to add to the agenda?

I don't have anything to add ot the agenda.

1. Minute taker Any volunteers? :)

Nothing here (not sure if Peter's financials email is a worthy topic?)

I can minute

That's awesome, thanks MattJ !

Nothing to discuss from me on that topic at least

I don't have anything to discuss on Peters email, other than "thank you Peter for the update."

Indeed

I'd be happy to discuss it if others feel there's soemthign to be discussed.

I sense that's not the case though? 🙂

Doesn't look like. If not, we can always take it again or via email

2. Commitments

"Follow-up on feedback & create poll for Compliance Suite Badges"

Being Nyco away, I guess we can skip this one for now

wfm

"Review of Roadmap page" Ralph mentioned he would send an e-mail to Council, but since he is also half/half, we will have to skip this one as well, as there are no any other news on this

as far as I know

(Did you skip the 'topics for decisions' lane on purpose?)

Yes, since they were both away :)

Now let's move onto

3. Topics for decisions

ah ok 🙂

"Vote on https://github.com/xsf/xmpp.org/pull/588" The pull request was resolved, but we wanted to discuss about the "underlaying" issue, is that right, Guus? :)

right

There were some things to clarify, if I remember correctly. Or at least MattJ and me had some doubts about what were we going to vote on.

Right :)

Do we want to clarify this and vote on the next meeting with the rest of the Board?

I'd prefer to do it now.

we have quorum, and we're not being very effective as-is.

the question was, who should be responsible for evaluating non-maintainer updates to the lists

Board or Editors.

I think we phrased that as "Should non-maintainers be allowed to ask for a project listing renewal?"

Guus: this is a misleading question. Everyone can ask something.

Ge0rG - I thnk you're asking a different question.

Guus: the relevant question is what process happens if a non-maintainer asks.

No, I think Ge0rG is asking a very slightly different but actually strongly-linked question which is the most relevant one here

I'd like to avoid having different processes, based on who authored the PR.

I'm fine with that, it doesn't necessarily mean there have to be two processes

Guus: in that case, the relevant question is, how is the process supposed to work if *anybody* asks for renewal

the status quo is: editors reject if a non-maintainer asks, accept if a maintainer asks.

that's not the status quo

or maybe: editors escalate to Board if a non-maintainer asks, accept if a maintainer asks.

Guus: that was the status quo I tried to establish, I obviously can't know how it is lived by the Editors.

I'm not an editor, yet do much (most?) of the website PR merging.

what is the right term then?

There's a lack of a specific role, other than "who-ever has been granted the power to merge" by a process that, as far as I know, non-existing.

"web team"?

If it is a matter of checking the projects being renewed or introduced, I don't mind volunteering for that.

I don't know if we're entirely clear on what "checking" means, are we?

which is part of the problem

The github team that appears to have that power is 'web', so 'web-team' works for me - although the term implies that this is a XSF workgroup, which I don't think it is

MattJ, exactly

I strongly feel that we're making to much of this.

I want to steer away of all of this complexity.

I think we have three options: 1) accept all requests 2) accept requests based on some objective criteria we can assess 3) just decide on a case-by-case basis

and I think everyone currently has different notions of what the ideal and the status quo are from this list

Agreed.

also: the definition of what is ideal is not something we'll agree upon, without much more discussion, I fear.

we == Board, or we == community (Ge0rG)? :)

I would go for option 3, that gives us a way to keep understanding what to do :)

The more, the merrier 😃

In option 3, who does the deciding?

Cisco jabber = XMPP? Or were there changes ?

Well, it's currently us, it seems

I would say Board until something is cleared out

(basically, the 'web-team' now does that, which effectively has the outcome of option 1)

I'm getting a bugreport from a user using Cisco Jabber server. And wonder whether the server could actually be the reason

Do we have a well-defined purpose of the list (I'm just opening the page to see if we have something on top, but its taking forever for the server to respond)?

Ah, timed out with "504 Gateway Time-out"

jubalh mind postponing that until after the board meeting?

oh so sorry

jubalh, we are currently in a meeting which will end soon - maybe ask in jdev@conference.jabber.org or wait for a bit :)

I'll wait

thanks

waqas, I think we pretty much all agree that the old list was terrible by all metrics

I'm for 2) with the objective criterion being "the PR author claims to be a maintainer of the project"

So the goal we can all agree on was weeding out unmaintained software from the list

I'd not be to happy with board to have to decide on every change / renewal request.

What if we allow everybody to ask for renewal, and I contact maintainers of each project to ask for confirmation? If this helps us moving on :)

I'm not seeing with what the 'maintainer' requirement does for the quality of the list - other than prevent others from changing (mostly improving) it.

Although I would love maintainers care of it enough to appear on the list instead

I'd love to just move to Link Mauve's magic DOAP project in the near future, when it's ready

Which is something to consider - even manual validation may only be a short-term thing

Guus: others "improving" the list leads to sub-par clients becoming visible

Ge0rG yes. Overall, it'd still be an improved list though.

Guus: we've had pidgin, astrachat and empathy on that list

Guus: not improved in comparison to the process that web-team isn't adhering to

"improved enough" for me though.

All other overhead is frankly not worth it, in my opinion.

I propose the following: web team auto-accepts if maintainership can be verified, defers to Board if it can't

Guus: Seve just volunteered to take over the overhead. I'd do so too.

I think we've sufficiently exchanged the same arguments for two weeks now though 🙂

and long term, we replace it with an automatic solution

Speaking of overhead: it _is_ a significant overhead for a user to install a sub-par client, and to only later realize that it's not working. Or even worse: not to realize it at all and blaming XMPP instead.

As much as I'd like to trust in people being sensible, it only takes one person to submit a list from Wikipedia which includes obsolete clients such as Exodus and Coccinella

If we accept everything without question, it's not really curating the list in the way that we need to keep it clean

Exactly my thoughts

The list will, eventually, curate itself mostly.

As nice and simple as that would be

My feeling is that the majority of requests will come from obvious maintainers and take no effort to verify and merge

and occasionally we'll have problematic requests that warrant a little bit of discussion (but not the amount of discussion we're dedicating to this)

I wouldn't have wanted to turn away the recent PR we had, which clearly had quite a bit of effort put into it, even though it was non-maintainer

But I also don't want to automatically accept everything just because someone submitted a PR

PR doesn't automatically equal improvement

let's vote on this already

On what exactly?

we're continuing to exchange the same arguments

We need a question to vote on first :) Which I'm not sure how to define yet

> I propose the following: web team auto-accepts if maintainership can be verified, defers to Board if it can't

How is this for starters?

Do you agree voting on that, Guus?

I'm fine with it

'verified' might be a bit ambiguous.

but I don't have an immediate alternative wording.

as I said, in my eyes it's sufficient to ask the PR author in the PR whether they are a project maintainer.

but I'm fine with the gist of it.

If the web team struggles with implementing this policy, we can talk - I doubt they will :)

Chair, call the vote!

Why did I volunteer to minute this gnarly discussion?

Let's vote

"Web team will auto-accept client renewal requests if maintainership can be verified. Otherwise, the request will be redirected to Board."

+1

+1

-1

:eyeroll:

🍿

"a vote of the majority of the Directors present at a meeting in which a quorum is present shall be the act of the Board of Directors."

That's a green light then. Vote passes.

I read that as 'motion passed"

Yes

excellent. Let's move on. 🙂

Amen

Hah :)

Since we have used more time than usually, do you want to stop here? I may not have more time today, unfortunately.

If you're leaving, we loose quorum anyways

so, sure.

sgtm

Ok then

4. AOB?

None here

nope

5. Date of Next

Next week, same time? :)

wfm

+1

6. Close

Thanks!

Thank you guys for this meeting

Thanks Seve, you're a star :)

Great to see we have come to a solution on that one

Yes, indeed.

I'd love for us to find a way to have much of these discussions outside of the scope of the meetings though

as they're eating up much of the meeting time.

which I think hurts our productivity further.

I'm unsure what would be an improvement. More adhoc discussions over XMPP in preparation of the meeting? More mailinglist discussions?

Yes, been thinking about that for a long time, I would like to use meetings for making things official, rather than actually knowing what do you guys think.

I agree that would be ideal

The meeting however is a good way to allocate time and focus on specific issues, ensuring we are all present for a productive discussion

So I'm not sure it is easily replaced by simple votes

allocate a second slot for discussion, on Mondays

jonas’: mind testing muclumbus on conference.igniterealtime.org ?

can’t

aioxmpp.errors.XMPPCancelError: {urn:ietf:params:xml:ns:xmpp-stanzas}remote-server-not-found ('Server-to-server connection failed: Connecting failed: dh key too small')

(I could’ve sworn that igniterealtime was once indexed, so that’s why it dropped off the index)

Guus, ^

Hmm

What's the minimum requirement?

2048 presumably

https://xmpp.net/result.php?domain=conference.igniterealtime.org&type=server

2048 sounds realistic

I generated 4096 ones for my hosts

On a side note: Ignite should be using default settings for encryption, as provided by Java. I generally assume that those provide a good balance between security and interoperability.

not anymore

and, no

Java is known for not dealing well with DH key sizes ;)

It's the other way around, things have been accepting 1024-bit DH groups for compat with Java, but no more

The future seems to be ECDHE-only tho

is it openssl 1.1 or debian which requires 2048 bits now?

Also I would check that Java indeed has reasonable defaults. Not an assumption I would make.

If we don't seem this acceptable any more, then xmpp.net scoring should be adjusted.

probably

Guus: " Server uses Diffie-Hellman parameters of < 2048 bits. Grade capped to B. " wasn't enough? It's been there for years

Zash, maybe it should be capped to E now?

B is a pretty good score

I think this is Debian, but IIRC the browser folks are in on it

The good thing about Java defaults is that they depend on the JRE version you are running.

https://www.debian.org/releases/stable/amd64/release-notes/ch-information.html#openssl-defaults

Ge0rG: Indeed.

We do use Java 8, I think. So that might warrant an upgrade.

hm, I should load that hack Zash has about fetching security info of s2s connections on the server and let muclumbus scrape that kind of stuff. then I would lower the requirements and show nasty warning signs next to rooms which are on insecure servers :>

Hehehe

This is sooooo different from a conversation I had with a customer not to long ago

jonas’: https://gist.github.com/Zash/5946686 ?

They insisted that the password being equal to the username was safe.

Guus, oh my god.

Zash, probably

I'll see if we can switch Ignite to Java 11. I'd be interested in finding out what that does to the encryption parameters.

I wonder if this accounts for the issue we've had with contacting the ChatSecure push service

given the name, not impossible

> (I could’ve sworn that igniterealtime was once indexed, so that’s why it dropped off the index) Without Muclumbus support?

jonas’: ^

Guus, uuuh

you weren’t talking about scraping igniterealtime for public MUCs, but about using the client against it

yeah, I can’t do that either with those dh keys, but at least now I know what you want from me :D

There aren't many rooms on that particular domainto, but I wanted to test the scraping implementation that was built.

right, so, scraping with muclumbus as in search.jabbercat.org does not require server support beyond XEP-0045.

the client thing is a different matter, it scrolled of of my mind’s backlog that you were about to implement that :)

I think I have an account on yax.im, maybe I can connect using that

Ah, I thought muclumbus was the scraping protocol used by jabbercat

Oh well. 🙂

Guus, do you have a search term for me?

where I’ll find something for sure?

the reply I got (a) is empty and (b) lacks an <rsm/> element which makes my test client crash :)

Guus, ^

the combination of both, or either?

open_chat is an existing muc name

combination of both

searching for "openfire" or "smack" should give you a result ✏

You'd expect an error instead?

Guus, an empty result is fine, but with <rsm/> element

searching for open brings me bad-request

(without further error code)

same for open_chat

Guus, here’s the full interaction in scs format (no, that’s not the actual password in there): https://paste.debian.net/hidden/01b30c03/

tx

Openfire does not like <set xmlns="http://jabber.org/protocol/rsm"/>

hm

eek, my client formatted that weirdly.

mine did not

Hmm... This might be a bug in Openfire

it expects _all_ fields.

all in rsm?

I can’t give you *that*

at most I’d give you a <max/> ;)

code is somewhat hard to read

but setting <max/> helps already!

I get a reply

it does expect a positive max value

and it cannot have non-specified fields...

seems to be pretty strict.

Guus, it doesn’t return a <max/> value

I think I wrote this when I was in college 🙂

interestingly, no example in XEP-0059 shows a server returning max

so why do I require that :)

it indeed does not re... yeah, what you said. 🙂

so I assume the meeting is over? :)

Guus, I use it as break condition to figure out when the result set is done and I expect the page size used by the server to be in there...

jubalh yup - thanks for your patience 🙂

no problems, I wasn't aware of the meeting, just joined and typed. so i realized it too late.

jonas` isn't 'count' more appropriate for that?

more or less

jubalh no worries, no harm done

fixing my code ;)

you're not the only one.

wee

it works

when I explicitly set <max/> in my initial request, I get a proper reply

I got a bugreport and I wondered whether Cisco Jabber is (still) XMPP and is also 100% compatible? bug report is this, and I thought maybe the server could be the reason https://github.com/profanity-im/profanity/issues/1165

Guus, here’s a successful exchange for reference: https://paste.debian.net/hidden/f4671816/

I have no firsthand knowledge, but from what i've heard, it is not.

Guus, ^5

jonas’ thanks - max does not seem to be required by the XEP (even though it's in all examples, that's probably what threw many-years-younger-me off)

I'll see if I can make that optional in Openfire.

Guus, in my implementation, <max/> is defaulted by the thing handling the RSM-modified request

i.e. it’s a service-specific default

jubalh: probably not 100% compatible no

we have a validity check that simply insists it _must_ be present. that seems to be to strict.

When they report, make sure you also get debug logs with what their server sends

Sadly, it's in an upstream library, so updating this will take some time.

pep., do you think that this bugreport could be due to that reason?

jubalh: ask for XML logs?

will do

Is there an XML console in profanity or sth?

there is, yes

I'll ask him

K

I think there is no explicit rule that says you can't send (repeated) `<presence type="subscribed"/>`, but I can see how that's annoying.

A client could check against local state to prevent annoying the user.

ralphm that's in reply to what? (Am I missing context?)

Guus: not you

jubalh's message above about Cisco Jabber

I didn't see him talk about presence subscribed though

or is that in https://github.com/profanity-im/profanity/issues/1165 ?

right, sorry.

Yes

I've been working on an issue where occasionally, messages were not being delivered to a MUC

so I'm now jumping at instances where I appear to be missing messages (which is hard to detect, visually)

ralphm, so if locally I already have the user tracked as subscribed I should ignore the incoming message subsribed?

how does one interpret an RSM request that defines both an 'index' element, as well as an 'after'?

jubalh: I would

so basically this means looping through roster and seeing who i have subscribed if i'm not mistaken

Looping? I assume your client has some local state for each contact/roster item, indexed by JID

right sorry

got it :)

No worries

“15:59:32 MattJ> I'd love to just move to Link Mauve's magic DOAP project in the near future, when it's ready”, I’d say it’s ready for project maintainers to start using, and for the XSF to start accepting; we don’t have all of the tooling yet, or not as integrated as I’d like, but that can come with time.

I could update #594 to not include any tooling, and instead let authors progressively fill their DOAP entry upon renewal.

Guus, what's the motivation for allowing both <after/> and <before/> in tinder's RSM implementation? I think it is right now underspecified what this exactly means, as <after/> is used to page forward, and <before/> is used to page backwards, and hence should be avoided until this is clarified

That is indeed highly ambigous.

flow: it's currently not allowed, although I'm playing with code that could allow it. I was actually looking for feedback.

what was this again for?

paging backwards but the page is also reversed

i guess

Prosody with SQL backend does allow it but I'd call it undefined behavior.

I tend to believe that RSM should just disallow using <after/> and <before/> together

it makes not much sense

though where is the harm flow? ✏

Actually I think Prosodys MAM code will allow it always, but some backends will ignore one of them and good luck figuring out which.

its not mentioned in the XEP, nobody reading the XEP would ever get the idea that this is even possible

there is no way you can discover that the server supports that "hack"

so i dont see any client actually using that

lovetox, ambigouty and implementation dependent behavior is always harmful to an protocol

but its nowhere documented that this is even possible, and as you say undefined

it is also not specified that it is impossible

so its basically a feature some dev knows and can play with

sometimes it is better to be explict

sorry, its also not defined what happens if add <after> twice

or if i add a element thats not even mentioned in the XEP

that, at least, is disallowed by the schema

Schema validators hate it!

Something something this weird trick

does it not follow that everything not mentioned in the XEP is *not defined*

adding optional extensions is a common pattern for most elements in xmpp, I don't think you can compare it using existing elements in an unspecified way

…compare it *with*

In the case of Prosodys SQL backend, `after` and `before` gets turned into SQL like `WHERE id > after AND id < before` altho after page size limits it'll behave like only 'before' was there.

great Zash, only a madman would use this though

or someone writing clients that only operate with prosody

Mostly because internal details like that the presence of `before` means it sorts the results backwards.

(and then it flips them around before returning as MAM results)

It'd be good to explicitly define expected behaviour or restrictions in the XEP.

I think other storage backends will simply ignore `after` if `before` is present

Changes in behaviour caused by an invisible implementation detail seems undesirable.

Having both `after` and `before` is UB, so what you gonna do?

We could explictly forbid it since it makes no sense

you talk like this happens per accident

As in, return some error stanza

Sounds good

It happens because the query and the data flow through two layers with slightly different API and semantics.

Well. Three layers if you count SQL.

Java works with 4096 DH key: https://bugs.openjdk.java.net/browse/JDK-8172869

Kev: Have you planned to upgrade M-Link to last version on the new server?