XSF Discussion - 2018-04-19

Holger, I have a hard time following the argument. What’s wrong with having a http_upload_hmac_secret: "…" option in the cluster configuration shared by all nodes?

just like web services have a CSRF secret or something. I don’t see any difference. unless you want to have different quotas per-user

jonasw: Nothing wrong with it.

so that would do the trick as hmac(cluster_wide_key, jid) for dirnames?

Yes sure.

There's no "argument" besides it solves an issue I didn't try to solve.

If your goal is anonymous file sharing, HTTP upload is the wrong tool I think.

That said, I'd be fine with adding such an option as soon as there's any demand outside this room 🙂

hah

Guus, ralphm: you guys both still up for the board meeting later?

MattJ: I am available.

Finally a vote to abolish Pidgin?!

I'm suddenly ill, I can't attend :P

Avian flu, probably

daniel, SamWhited look google thinks self destructing emails is a good idea too https://www.theverge.com/2018/4/13/17233504/gmail-design-confidential-mode-feature ...

XSF Board Meeting | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

T-7min

0. Welcome and Agenda

Who do we have?

hi

Nyco and Martin apologized, MattJ probably responds after this ping.

Hey

see? 🙂

as it has been foretold.

impressive :)

:)

wow

Any new things not in Trello?

The Pidgin vote.

Is that a board issue?

I don't know what that means. Ge0rG is this a serious topic?

I think Board are being asked to resolve a difference of opinion, in summary

ralphm: semi-serious, it's about https://github.com/xsf/xmpp.org/pull/425 and whether we want Pidgin on the list of XSF-approved XMPP clients

I'll add it to the agenda

1. Minute taker

Who?

(not me, this time)

(also. did I forget to do it last time?)

(can’t promise anything (like, not leaving in the middle of the meeting for an hour or two), so won’t volunteer)

We're done at 14:00 UTC

(I’m aware. that doesn’t change it unfortunately :()

I'm going ahead hoping somebody does this, even retroactively

I'll do it

2. Topics for decisions

Well, I guess we have the PidGin item

Can somebody give a summary?

ralphm, somebody tried to renew the listing for pidgin on the client list, and some people raised voice against it being listed there.

for compatibility reasons

I don't think this list has ever been a Board topic before

it has.

the intention of the new software listing rules was to rule out unmaintained software and software where the developers don't care about the listing. There is a very implicit requirement of project members submitting the item.

I’m pretty sure that it was discussed by board when the renewal-policy was introduced.

It was indeed. Roughly a year ago.

I mean we didn't make decisions on the content of the list

It was a definite shift in the purpose of the list though

I don't know if #425 was created by a Pidgin project member, and technically there _was_ a new Pidgin release, so it's not unmaintained. But everybody agrees that it's a horrible XMPP client and maybe even that it's damaging XMPP's reputation

What we had before was an extremely long directory of every XMPP (and Jabber) software ever written

and we agreed to introduce changes to ensure the list is more current, by requiring projects to re-list periodically

Without enforcing a ruling, perhaps board can offer an opinion?

would that suffice?

Who maintains the list?

From the peanut gallery, I think if this is a Pidgin person asking for it to be listed, it should be listed, otherwise not.

whoever has power over the merge button, taht’s at least guus and me.

whoever has commit rights.

I'm not sure if we have a defined WT for website maintenance.

Kev: formally, you are right. But IMVHO this is also a subjective issue of whether we want to serve our community well.

I agree, but I think we either have to curate the list, or not curate the list, not having uncurated except for one excluded project.

Answering the peanut gallery: I'd not be opposed listing software even if it was asking to be listed by end-users, instead of developers.

I would, however, not oppose a semi-objective "compatibility" rating for each of our listings - if it's not to detailed.

Kev: as it is right now, this list looks like the officially endorsed clients™, and I'm not sure we really want to endorse every client that applies for the list.

Ge0rG, I share your opinion that Pidgin's current situation is not helping us, but I don't think we've actually made that decision to make the lists "only software recommended by the XSF"

On the other hand we don't have a proper way to objectively describe client quality

and that's a difficult subject that has never been solved in the years we've been discussing it

MattJ: I'm talking about the impression to new users, not about our internal bureaucracy.

I'm well aware that my counter-point of the PR (probably) not originating from a Pidgin developer is just a fig-leaf excuse to not have it listed.

I think it is useful for people to know that Pidgin can do XMPP (even if its implementation is crappy, at best).

I think the best objective measure we have at the moment is "Has the project itself asked to be listed".

Guus: people who already use Pidgin are probably aware of that. Do you want people who are learning about XMPP to end up with Pidgin, though?

If the project itself doesn't care to list itself as an XMPP client, that suggests to me that it's better off not listed.

Kev: I think (hope) this is uncontroversial.

OTOH, Guus disagreed earlier today.

Ge0rG: Guus was disagreeing :)

I have to agree that what Kev said is the only objective thing we have

short of verifying the Compliance Suite 2018 compatibility.

But if we enforce that, we will end up with a _very_ _short_ list.

And I might not like Pidgin, but that's subjective. If you want objective, you need to say: all listings have to comply with something, like the Compliance Suite. I don't think we did that before.

Ok, so I think we need to make a decision on "project members only" or "anyone"

We did, FWIW.

Kev, in the past you mean?

At the Summit where this policy was created.

And it was Project Members Only.

Is darkpsy3934 a project member?

in that case we should make it more explicit in the README.

I don't recall (not saying it's not true), but I certainly do not enforce that.

Kev, defining project members is tricky for FOSS

(as I don't know how to enforce that)

commit access? maintains the documentation? Non-coding community manager?

MattJ: it's tricky, but something like "does regular contributions and can influence (the other) developers" would be a good start.

MattJ: once we get a hold on somebody who cares and can do that, we can shame them into implementing the most basic interop things. Like the 8-years-pending Carbons support.

I think we need to separate the Pidgin situation from this :)

If we're not setting a baseline technical requirement, Pidgin qualifies

MattJ: that was just a figurative example.

and I assume they have at least 1 active team member, who will ultimately ask us to list the project

I think we'd best not add any complexity to that adding-things-to-the-list thing.

MattJ: I agree

So the question is simply what our requirements are in general

I understand Ge0rG's concern, and probably agree that I'd like Pidgin to do better, but I don't see enough reason to reject this request.

Well. 1) Are there any requirements on the software listed. 2) Are there any requirements on the person listing.

ralphm: Pidgin has failed to do better for a very long time now.

I'd prefer having a list of clients that at least one person cares about, over an overengineered process.

ralphm, that's the gist of what I'm thinking too.

AFAIK the only requirement is 'somebody asks for inclusion at least once a year'

ralphm: having a software listed on that page is (to an outsider) equivalent to us, the XMPP organization, endorsing its usage.

ralphm, Could I submit bash?

Dave Cridland: ITYM openssl s_client

ralphm, Could Donald Trump submit the White House Website?

yes

Dave, you could submit it, but I (as someone who has the ability to merge the request) would reject it

Guus, On what grounds?

Guus: on what grounds?

on my semi-objective opinion that it's not an XMPP client or server.

Guus, Because you're telling me now there's a line. I'd like to know what that line is.

Guus: it fulfills the technical requirements.

Dave Cridland: please suggest an alternative

Dave: I've previously not accepted PRs for projects that were silos.

(xmpp based silos, but silos)

ralphm: "a project member submitting the project to indicate that they care about XMPP"

there's a degree of subjectivity in there - and I'm fine with that.

ralphm, I'm trying to find what the current policy is, before suggesting a new policy that differs.

TBH, an XMPP client is something that implements XMPP IM

as a point of order: I can't overrun this meeting. We should conclude this, or resume next week.

We have no objective requirements on UI

ralphm: so a text window where you enter XML qualifies?

Dave Cridland: I think the current policy is: somebody can submit an XMPP Client (whatever that means) once a year, and it would be included.

I think this discussion isn't very useful right now

Pidgin is no doubt an XMPP client

If the criterion is "Person with website commit access gets to choose whether it's listed or not", then we should say that. I don't think it's a good policy, but at least we'd be stating it, and it's different from what we've stated before.

Ge0rG: I want to note that compliance suites also have no such requirements

Kev, +1

> To achieve this, the XSF Board has decided that all implementations have to reapply once per year, to ensure that they are still actively maintained and that the listed info is accurate.

This is from my mail to jdev@, Thu, 23 Mar 2017

I think all of this work is best effort and there is no completely definitive answer. Some person is going to accept or reject and then maybe somebody else has opinions later

ralphm: Then just go with my suggestion above.

I propose that we currently vote on whether to accept this PR. If someone objects, state why so we can resolve it for next time

It is clear. Not good, I think, but clear.

Kev, where 'website' is our website, not the project applying, you mean?

Yes.

MattJ: but I don't want to have to vote on this every time.

If we're being arbitrary about it, it is best to be explicit that we're arbitrary about it.

Agreed, neither do I - but what we decide ultimately sets a precedent and we can document it

Rather than pretending we have one rule, and acting on another.

Kev: I don't agree that it's needed to be explicit about that (don't mind to much either)

I'm vanishing now anyway.

In that case, I move we accept this request to add Pidgin on the grounds that it is an implementation and somebody wants it added for another year

I think we're somewhat overcomplicating a proces that has worked pretty well so far

it's jsut this Pidgin thing that now acts up, which is understandable.

ralphm: +1

also, I need to be going. Can stick aournd for a couple more minutes at best.

I'm -1, because I think we should limit submissions to people affiliated with the project to ensure accuracy of the submitted data

and it's not clear that this person is affiliated in any way, other than as a user

mattj, the person merging assures accuracy.

(at least, I check if the name / website exists, and that's pretty much it)

If all the data is trivially verifiable, then I'd be fine with that

"all the data" is just the name and link to the project site

I still think that this is a huge disservice to our community.

Ok, then I'm +1

Ge0rG, I hear you, but I disagree.

FWIW, I would think Compliance Suite compatibility would be a good criterion. The resulting list will be short because there isn't many good clients, but I don't see how it helps the end user to make it longer by filling it up with not so good clients.

Holger: it could end up with Conversations as the only client.

Ralphm, can we conclude the meeting please? 🙂

I think as a separate task, we should add a field for latest supported complaince suite

yes

But that's for another day

Ge0rG: I'm not sure that's true. If it is, so be it.

3. AOB

MattJ: some form of conformance should be added, yes. Not sure if it needs to be compliance suite or not.

Guus: it's the most logical one.

nothing today

4. Date of Next

+1W

(no aob for me)

+1w wfm

wfm++

5. Close

Thanks all

Thanks ralphm

thank you, and goodbye

Thanks everyone.

Maybe the Compliance Suite or the referenced XEPs need fixing if nobody is able to implement it.

Ge0rG: But doesn't Gajim also meet it? And maybe even ChatSecure these days?

Maybe also JSXC and/or Movim ...

I would also like to see License listed there

XSF Discussion | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

moparisthebest: how is that relevant?

I'd like to see programming language :-)

Ge0rG, so you can quickly rule out crap you can't use :)

I'd like to see a commit graph of the last 365 days.

moparisthebest: crap and license are completely orthogonal

the last entry for example uses some custom license which makes it worthless

'you can look, but not touch'

moparisthebest: people who care about software licenses are typically sufficiently competent to obtain that information on their own.

well sure, you can search each individual website for such info, but it's time consuming and annoying

moparisthebest: How much time have you spent searching XMPP client web sites for licensing ingo?

info even

I think if authors have to submit the info, it'd be a good chance for them to put the license

moparisthebest: the alternative is this: https://en.wikipedia.org/wiki/Comparison_of_instant_messaging_clients

Holger, wasted a few minutes on the last one :)

moparisthebest: it would be good to have it in the JSON, but not in the rendering.

moparisthebest: "a few minutes" is not a valid reason.

oh well that'd be fine with me too Ge0rG , just as long as it existed in an easy to find/standard way I think that'd be excellent

Of course now you made me curious about the Zom license.

moparisthebest: make a PR to extend the JSON format.

moparisthebest: also add an icon field while you are at it ;)

And programming language!!

I'd much rather move to the model we've discussed many times, where projects host this info themselves in some standard format

But guess what, it always comes down to a JSON vs. XML debate :)

maybe a compromise could be made on YAML or TOML or something :P

that way *no one* is happy

Link Mauve posted some concrete proposals to the list a while back

But then there's a nice project that fails to do this ...

Holger: yaxim doesn't have XEP-0368 (failing Core Client), avatars/vcard (failing IM Core Client), and push (failing Mobile Advanced Client).

and they don't get listed, poor them. They're probably not a nice project :)

Ge0rG: Then that's either a good reason not to list it or there's something wrong with the Suite.

Holger: or both.

Yes :-)

Holger: of these I consider only MAM as mission-critical. But I wasn't able to convince the XEP author.

wait, MAM isn't even part of my list because it's Advanced IM

0368 seems totally optional to me. For the others I dunno.

Holger: I have the highly controversial opinion that ensuring reliable message delivery is the most important task of an XMPP based IM solution.

it looks like it says TLS is required, and that you could get it by implementing either 368 or STARTTLS

But I have no idea what the purpose of a Compliance Suite might be if it doesn't even work as a criterion for recommendable XMPP software.

unless I read it wrong?

moparisthebest: by that logic one could implement RFC 7622 instead of 6120 and be compliant.

that is how it's worded isn't it?

the feature is 'TLS' and under Providers it lists: RFC 7590 [4], SRV records for XMPP over TLS (XEP-0368) [5] [6]

moparisthebest: there is no explicit wording on that at all.

https://xmpp.org/extensions/xep-0387.html#core

moparisthebest: I think the XSF is looking for a volunteer to make next year's Compliance Suite.

A feature is considered supported if all comma separated feature providers listed in the "Providers" column are implemented (unless otherwise noted).

ah I missed that, so looks like 368 is required

Ge0rG, hehe if I wrote it it'd be pretty simple "Do you implement everything Conversations does? If so, compliant, if not, you suck."

just joking :)

...or are you?

(thinking of the aesgcm discussion)

moparisthebest: yes, that's the Conversations Protocol Compliance Suite.

FWIW: https://github.com/xsf/xmpp.org/pull/425#issuecomment-382759398

(and, as it was foretold, I was dragged away from board meeting mid-meeting)

jonasw: apparently, all present board members voted to approve that PR.

Ge0rG, my understanding was under the condition of that we can verify project membership.

jonasw: I think this is not what was voted in the end.

but I might0ve misread

I guess I should write up the minutes now :)

right

I misread

fixing

done

mine? darn, I just made an incorrect comment. no need to write my resignation for me :<

Ge0rG, What are you resigning from?

jonasw: no, it's not a termination letter.

Ge0rG, I know. you could still write that letter, lay it in front of me, say "sign it" and hold a gun next to my head though :)

Dave Cridland: I haven't decided yet. I'm just feeling a strong wave of resignation.

TBH I'm not sure this list is all that important anyway, these days :-) It's probably way more important to have a good ranking in app store search results.

Holger: I'm sure desktop users will share your view.

There are no desktop users.

The cake is a lie?

Ge0rG, you are aware that all major desktop platforms have appstores by now?

look at Ubuntu (and derivates) (and I’m not sure even that counts in as major), look at Mac OS, look at Windows.

the scary thing is, I just opened the Windows store and it greeted me with my name.

jonasw: I thought the Windows store was Win10 only?

Ge0rG, is there any other windows in use anymore?

I've heard Win7 is still a thing.

It's called Microsoft Store now. GET IT RIGHT.

So what's the policy regarding that web site list now? I've re-read the backlog and don't get it.

Maranda: tell me about Android Market.

Ge0rG, :P

Holger: anything that is deemed an xmpp client by the editors is good to go.

apparently, it needs to support rfc6120 to pass.

yeah, anything which can make an appearance which convinces the merger that it’s an XMPP software thing is good enough. ✏

So like before?

A complete list of all existing XMPP software?

Holger, except that people need to go through the effort of renewing

Holger: a list of all xmpp software somebody submits once a year

Ah.

Ge0rG, oh yes, I can’t wait for Roster List TUI 1.0 to appear there!

to be fair, the adhoc_browser example could actually be useful.

jonasw: I'm much more excited about quickstart_serve_software_version.py!

I would rule out that you end up with a useful list that way :-) But whatever.

Holger: it's as good as any arbitrary list!

Holger, the idea was that we can tighten the constraints once we have the renewal thing

I mean, at least we've averted the listing of /bin/bash!

reminds me to build the xmpp client in sed

I still think that the initial rule of "submitted by a developer" that was created by last year's board is much better. But what do I know.

at least a simple echo bot should be doable

and then I’m gonna release that as GPLv3 XMPP "library" for sed :>

jonasw: it needs a home page and a shiny name.

Ge0rG, github repository is fine

aioxmpp doesn’ have a fancy homepage either

jonasw: make it a proper client. With a Jabber™ trademark license.

EBUSY

with that other proper client and helllota different stuff

https://upload.lightwitch.org/share/dafff9ca-2651-4a31-a578-d95d6781877f/KFE5mlBPTTqdf9IdE9Yzow.gif

> jonasw> reminds me to build the xmpp client in sed wat?

pep., sed is turing complete after all.

the only issue might be the line-orientedness maybe, but a pipe with xml2 as suggested by Zash might fix that

I see. It makes a lot more sense now, I would definitely approve this

I sense sarcasm.

A mere sensation ignore it

xev | sed | nc | xml2 | sed | xdotool

Zash, oh my god.

oh my god.

praise golb

https://github.com/uuner/sedtris

dear glob, and lead us not into temptation, but deliver us from evil. *signs cross*

Reminds me of when a colleague aeons back decided that it was easier to write a partial XML parser in AWK than to use a library and create a binary program.

Huhu

oh my god.

I’m playing tetris in a sed interpreter.

and it’s colourful

I wonder if there's a sed pinball version

jonasw, I did as well!

pep., except that I’m 100% serious :)

i really want to do an echo-bot in sed

just becasue it should be possible and to keep my brain from becoming too normal

hmm