XSF Discussion - 2018-04-12

Maranda, requesting the config form is a smart thing to do, because usually you want to offer configuration to the user.

jonasw, for muc? I'm not sure the end user will know what to do with it also as MattJ said if something does it like Gajim does you may end with an undefinitely locked room

Why not just do what Swift does?

"[x] Automatically configure new rooms"

And regarding subject I decided to send it after the room is unlocked

Sensible defaults? Never!

Kev, or just request an instant room

We didn't even have that to start with, but we had people who required reserved rooms.

Maranda: I think that's not one of the two obvious readings of the spec :)

I think lovetox is more incline on auto requesting an instant room though

Even because if you cancel the config form the room has to be destroyed ™️

> undefinitely locked room say what?

Yes

Undefinitely locked room

i think you meant: indefinitely

Whatever

I'm an illiterate english wise 😜

Keep a timestamp and unlock or destroy it on some timeout?

Possible, but how much time and what happens if the user just creates the room and goes to pick up a coffee (leaving the config form open)

That's not too silly either

As example

Measure how long it takes to fetch coffee

Unlock the room if the user leaves prior to finishing configuration

allow to create rooms by just submitting a config form to a MUC JID?

Or join and just request an instant room

It's already provided

I think instant rooms are underspecified in 0045

Ge0rG well I didn't even know about all this mess before yesterday, and/or I suppose my brain could've just removed it because it's too messy

Maranda: so I made you have nightmares about MUC? Yay.

About all this locking mess yeah it's horrible UX wise, but I have to care about the protocol not UX ultimately

does gajim 1.x still do resource locking?

I suppose, never experienced chat disjoints (yet)

:/

Maranda: what? you put protocol over UX?

as a server deve, I think that’s a valid argument ;-)

Ge0rG, shiny things is your thing mine is the rubbery below that..? 🤷‍♂️

😘

Maranda: if the protocol goes against UX, it needs to be ignored and/or repaired.

Indeed but since there's a standard I have to abide to that

Until it's fixed ™️

Maranda: there are server devs in this MUC who have ignored the standard to improve UX

> Until it's fixed ™️ So did you submit a PR? An XEP?

Submit a PR to muc?

sure

I would remove the locking mechanism completely and leave instant rooms while I understand the reasons below it

That's my PR

Maranda: I've submitted multiple PRs already ;)

Maranda: a PR is a diff against the XEP xml

not a sentence on this MUC :D

I can already see a lot of people voting against it

I know

But that's what it would be

And then I'd need some editor to re edit it and make it comprehensible for the masses too.

🤣

Maranda: you could collaborate with an editor

the way pubsub does it would be cool. create a room by sending a config form along. if the room exists -> conflict, if it doesn’t exist -> configure as specified by the client (if possible, otherwise error)

jonasw: for instant rooms, I'd argue that the server should assign a room name.

Yes that's indeedly a better solution

<iq to=chat.yax.im><gimme-a-room-pse>

gah

s/room name/room JID/

jonasw's for sending the config form, but then rooms aren't persistant by default

So we get into an implementation issue

…?

the client would send a config form with persistent set to treu.....

gotta go

And what about non persistant members only rooms mr. "jonasw gotta go“ 🤨

Maranda, what?

the client can request whatever it needs?

I don’t see your problem.

That a non persistant room to exists needs someone in it, that's what all the locking junk is about

ahhhh

so?

<presence><x><create-config>form goes here</create-config></x></presence>

So what I said above applies as issue in your solution

this joins and creates the room

and configures

Ok that could work 😁

I don’t see the problem with that.

:)

and it’s atomic, which is neat

much better than MUC logging

wtf

what did I just write

locking is what I meant

I need lunch, gotta go now for real

jonasw your "work like in pubsub" didn't trigger the "publish-options" example in my head (which fits more than "create-and-configure" and won't apply for non persistant)

s/and won't/that won't/

And well GC1.0 breaks spim blocking horribly for mucs

Maranda: does it?

Yes

And I sense a tip of <sarcasm/> there Ge0rG 😜

Maranda: and I sense a large pinch of generalized statement.

Ge0rG muc private messages, I track directed presences with the x element atm

I'll have to track all directed presences using bare instead but that's a bit more expensive

On GC1 private messages will break mod_spim_block

Atm

Maranda: don't you have to track all directed presences anyway?

Maranda: the funny part is when you try to join a nick as `Maranda`, but the MUC tells you that you joined as `Dumbass` instead. It will break both most clients and presence tracking!

join a MUC

(no offense intended)

source for 'it will break most clients'

daniel: maybe yours is a notable exception, but please don't generalize that.

i'm just wondering if you actually experienced clients breaking on this?

I know of two that will be broken.

with different degrees of brokenness.

Servers changing MUC nicks will certainly break things. How much things break might vary, but it'll screw things up.

You need both your client to understand it sensibly and your server to do unspecified things.

Kev: I think there are two different cases here; a MUC telling you that you joined with a different nickname, vs. changing your nickname later on

maybe sometimes you need to break things to have nice things

something something omelettes

but it's pretty reckless to have the renaming in 45 w/o a way for the client to signal that it will be able to process that

45 is broken in many interesting ways.

daniel: yeah, but we can solve that. Just have the MUC service keep a mapping of (actual client nickname <-> what the client thinks its nickname is) and add some renaming on conflicts

so if my client thinks I'm `Ge0rG`, but I'm actually `Not_Ge0rG` in the MUC, when the real `Ge0rG` sends a groupchat message, I will see it as coming from `The_other_Ge0rG`. Easy!

whatthefuck

Sorry I haven't done the minutes of the gdpr meeting yet :(

I might have a conflict next tuesday, my boss is looking to sort this out.

k, we can move if necessary I guess

if and only if this conflicts, I’ll be available on wednesday instead of tuesday.

conflict resolved

Ah, minutes are in. Always a pleasure to read.

.

I'm here

(but in a meeting)

Ending soon?

Nyco sent apologies

god knows ...

I know the kind :)

I can lurk here

Martin, around?

Yup, sorry, chat window popped onto the wrong monitor

I haven't heard anything from Ralph

can any of you start off?

I have to pay some attention to this meeting 😕

Pinged Ralph but no response. I'm not sure of the value of starting with 2.5 members present - unless you want to be counted as a 1

I agree, probably a better idea to defer until next week

And then there were four. Or maybe 3.5.

Ok, meeting over 🙂

Ok

Let's do what we can

0) Role call

I'm here!

Me, Martin, Guus

nyco, sent apologies (but is here if he wants to retract them)

Anyone have anything for the agenda?

(nope)

Anyone free to take minutes?

<--

Thanks!

No decisions to make this week, it seems

1) Commitments

1.1) Membership survey

I've converted the survey to a Google Form, you can take a look here: https://docs.google.com/forms/d/e/1FAIpQLSdZL6iNYhLJCTWYg3vZ_2XEC5dYrzeQuZtaJZ3OdJFL2UwFpQ/viewform

MattJ: there is an item to decide, https://github.com/xsf/xmpp.org/pull/425

Can I fill that out as a test/

or will my responses be inrevocable?

Feedback welcome. Main open questions I think we need to decide: should it require an email address? (I say yes), and who should the survey be for? XSF members only? or the community at large?

Guus, feel free

if we're doing this for members only (my preference), I'd make change the email field in a name field.

MattJ: what is the email required for?

Ge0rG, follow-up, preventing duplicate responses

MattJ: that should be stated in the form

and if we opt for members-only, potentially verification

Ge0rG, is that with your GDPR hat on? ;)

(maybe we should discuss the details off-meeting)

MattJ: not only

MattJ: if somebody asks me for my email, I want to know why.

Ok, we can discuss. I'd like to send the form out before the next meeting

We're short on time, so let's move on

as I said: I think a member-only thing is most suitable: if only because we know these people to have some affection with XMPP.

and with that, an email is not 'needed' (as we know who you are)

Guus, I worry that may exclude some valuable opinions (the XSF may be a bit of a bubble)

For example, lots of memberships have lapsed - we might be able to learn why

fair

ok, you won me over

1.2) Online swag shop

Nyco sent some details to the board list

If we go ahead, I'd opt for not having any up-front costs

perhaps first decide if we do want to go ahead?

I think last week we agreed on going ahead with the research

Research is done (?)

sure

What reasons are there to not go ahead?

I can't think of any, it's essentially an experiment though

(I don't have any major ones, but so far, it's only been three people talking about this)

Do we know who'd come up with the creative elements? Or would we just use existing logo assets?

Martin, I assumed the latter, but that's a good point - we may want to do more than that (as we have done for FOSDEM in the past)

Martin: I think this'd be best served by the comms team, but possibily scam as well?

But then someone has to volunteer to do that

there might be taxation issues for the XSF

whoever is responsible for the XSF tax forms should be asked first.

that's sensible

I assume it's no different to selling t-shirts at FOSDEM, but we probably should

Peter, as the Treasurer (and general -has-been-around-forever-and-knows-everything-) might be able to help here

Guus, do you want to add it to your list? :)

k

Thanks

So let's do that, and push the final decision on this off for another week when hopefully we'll have more voices

1.3) Collect information on the role and responsibilities of the executive officer

Martin, any success with this so far?

Unfortunately not. I'm about to leave one job and start another one, so my week's just been eaten up. Sorry.

The title of the card is inaccurate, we're specifically discussing the Executive Director role

change it? 🙂

Shall do

2) Items for discussion

Guus, financing - ongoing I believe?

yeah, i've send out emails (cc'ed board), but no responses so far.

Noted

other than that, i've not started anything on the subject myself.

Other item is ED search which is blocked on the other task

3) We've hit our time, does anyone have important AOB?

Ge0rG highlighted that PR about Pidgin

I haven't read it yet, and don't really know what's going on, so I'd rather push that to next week

I've commented on that in the PR

and maybe give some feedback in the interim

Ok

no AOBs from me.

4) Date of next

+1w

5) Close

wfm

Thanks all!

thank you!

Thanks MattJ

Ge0rG, ok, I see the issue. The neutrality issue is actually in the community survey so that might provide some data on what people would like to see here

Personally, I'd be fine with including it if we had the right markings next to it indicating that it is not up to date with the latest protocols

But down that road lies a whole kettle of worms

MattJ: I know. I'm not the one asking easy questions :P

Someone needs to determine what the compliance level is. If it's self-reported, someone needs to verify that

(or do they really? Probably some competitor will submit a PR to fix it and we'll need to resolve the dispute :) )

We don't have compliance level requirements.

Back when introducing the new policy, I wanted to make it more clear that only application authors are allowed to submit their respective application.

However, even that opinion was controversial.

It's hard to enforce, would be my main concern

In open-source projects the line isn't always clearly defined

Are only application authors allowed to?

If someone submits a couple of patches, are they allowed?

If they only maintain the documentation, are they allowed?

Or if they are on the inofficial marketing team by speaking positively about your project at least once? :)

This is why that plan to have XMPP projects host some metadata on their domain would be the best option

But if the current situation is that project authors won't even bother submitting a one line patch, who's going to motivate them to author such a metadata file?

The people who are currently trying to submit the projects to us :)

I'm not a fan of restricting applications to that JSON file

We as the XMPP community have a huge quality issue. We won't solve it by having "inofficial marketing volunteers" submit zombies to The Official Client List

Guus, why so?

Because being the one that created the app doesn't uniquely qualify you to add it to our list.

Hell, I think I've added a couple of clients on there.

Also, me, being against forcing people onto singular platforms, feel meh about it being done by github pr.

Zash: you can send .diff files

Why would we limit our list by denying entries from enthousiastic users that are not devs?

Guus: because enthusiastic users don't know whether their favorite client is actually good for the general audience.

Guus, it depends entirely on the purpose of the list

At least less so than the developer.

I think you and Ge0rG have different opinions on that

It's up to us to merge or reject the PR.

so quality control is up to us. I'd be happy for anyone to offer suggestions for us to put on those lists.

Was the purpose of the renewal not to filter out inactive projects.

Zash: yes

Pidgin is not an inactive project, even it's not moving very fast.

Guus: what kind of quality control do you want to apply, that doesn't violate the Holy XSF Neutrality Stance.

Ge0rg: a judgement if the entry is appropriate. I've denied stuff before.

Guus: judgment on which grounds?

lemme think

Guus: I agree with you that we want quality clients there. But we need to have some formal grounds for that

i think I denied at least two, because they were XMPP-based silos (that did not federate)

Oh, but then we disagree 🙂

FWIW I had multiple conversations with ex-XMPP users who had moved to other platforms because XMPP can't do $feature

I don't think quality is a requirement.

When it turns out they were Pidgin users, and don't even have Carbons

as that's subjective, at times.

exactly, lots of people are happy with Pidgin, even fi we're not

and this has given me the opinion that Pidgin is harmful to XMPP, as it stands

so I'wouldn't mind adding it

No, these people left XMPP because of Pidgin

Maybe gathering a minimum of XEPs implemented?

Guus: except that pidgin makes your XMPP experience break in unexpected ways if you add another client

for IM.

Seve/SouL: like the Compliance Suite?

Pidgin is extremely popular (whether we list it or not)

and for a significant number of XMPP users, it *is* XMPP

Pidgin and Zom on top of Cisco Jabber.

XMPP does not support Carbons or MAM if Pidgin does not support Carbons or MAM

Matt, that's why I think we'd better list it, but with some kind of footnote.

we need a traffic light, and pidgin will be red.

except colorblind.

Ge0rG, I don't know how many active/good clients would the Compliance Suite exclude, but yes. Something like 'minimum decent experience'. This way we even could list clients that have these features or more, and 'others' that do not, like Pidgin or whatever.

As long as yaxim ends up on the "good" side, and Pidgin on the "bad" one, I don't care :P

Heh

Seve, I largely agree. I do think we should prevent the qualification to be very strict or detailed though, as it'll lead to too much discussion

Seriously though, the list on xmpp.org is intended for people who don't have an XMPP client yet.

but a simple stoplight type of deal would owrk.

I can't see any rational reason to tell them about Pidgin, except not to use it.

I think that it does add value for many people, even if it does not for you.

Guus: what kind of value do you think it adds? ✏

Ge0rG whatever makes the gazillion people that use it for XMPP today think of it.

Maybe have an Subjective Persons Pick of the Week thing before the full list?

Also: if people see it on that list, and are used to pidgin, but see that there are many better clients (by looking at that traffic light), they might be motivated to explore what better things are out there.

Zash, and in 4 weeks we run out of clients ;)

Guus: ask jonasw what he thinks of it.

Someone (read: Ge0rG) could review clients and post under a big "NOT THE OFFICIAL BLAH OF THE XSF" banner on the blog

Ge0rG: I'm not disputing that it's lacking

Zash: I'd be the Angry VideoGaming Nerd of XMPP clients.

Ge0rG yes but they're normally tracked with the full jid so I need to make another table that contains bare and I didn't want to do for non muc cases I guess I'll have to make a third one just in case

hi Maranda! Your message came in 4 hours late.

I know i was without data

I exhausted credit

Guus: as long as we don't have a formal mechanism to put clients into "good", "bad" and "ugly" lists, and the appropriate tooling on the web site, I'm strongly against putting pidgin onto the list.

Ge0rG: my formal mechanism is your gut. 🙂

Wikipedia has huge tables of XMPP clients, sortable by criteria and listing some "important" aspects.

And exhausted it just I was typing said message too

😎

Listing 'Minimum decent experience' clients and 'others', could even motivate client developers to work on their client. This way we can add to the list more clients and also specify which ones you should choose first. If adding clients to the list is what we aim for.

Ge0rG: i don't want to keep that kind of detailed data on our site. That'll be always out of date, and lead to too much bickering. Just a "good/bad/ugly" qualifier that's based on whatever the XSF member(s) in charge of the list semi-objective thought on the matter is, is good enough for me.

semi-objective in a semi-official place is weird tho

Zash: better than the alternative, perhaps

Guus: so you and jonasw disagree, we'll have an edit war?

Ge0rG: no, because we're sensible people.

... at least jonas is.

I wish that'd be true for all XSF members.

I think we can strive to an acceptable compromise on a 1to3 level of things.

given the semi-objectes arguments based on compliance levels, I don't think there'll be much discussion between the highest and lowest levels anyways, so compromising should be doable.

we're not having an edit war now, do we? And we both have the ability to add/remove pidgin today. 🙂

Certified Approved by Guus, Ge0rG or jonasw on arbitrary subjective grounds™

Zash: I'll order that in rubber stamp format.

I'll order a tiny "Zash approves" rubber stamp to stamp on those stamps.

I don't think there are any clients that would deserve the "Approved by Ge0rG" stamp.

instead of the compliance levels, we could have "things that Ge0rG complains about a lot / sometimes / hardly ever."

Guus: I like that.

We would require you to complain to some degree on everything on the list then, though.

Someone will have to provide me with the required devices to run the shit to complain about, then.

Maybe do a community survey on rankings?

"shit doesn't run on my device" is a valid complaint.

oh shit, kids

need to pick them up

byes! 🙂

Falling out of Debian's own wrangling with the upcoming EU GPDR regulation, I thought it might be a good idea to have a cross- community discussion group to discuss the GDPR and its impact on free software and free culture projects. This has now been setup here: https://www.earth.li/mailman/listinfo/gdpr-discuss Please feel free to pass the link onto other communities who would be interested in participating. Best wishes, -- ,''`. : :' : Chris Lamb, Debian Project Leader `. `'` lamby@debian.org / chris-lamb.co.uk `-