XSF Discussion - 2020-09-03

I thin we've once discussed whether personal MAM archives should or should not include messages exchanged with a MUC by the archive owner. Was there consensus?

It's awkward as long as MUC is the way it is, as you see 0 or more messages depending on how many clients are online and joined

I think the consensus is to exclude type=groupchat from personal MAM, but then you end up with MUC-PM duplicates

https://fosdem.org/2021/news/2020-09-01-dates-fosdem-2021/

FOSDEM will be an online event next year, so what is going to happen to summit?

Online summit?

The XSF could host a jutsi meet

Not sure how good this would work online. Those that joined remotely usually were mostly excluded from discussions

So next year everyone will be equal 😛 ✏

Online Meeting is always < RL Meeting, but what else can we do?

Maybe with everybody online this time people generally present would pay more attention to the others :)

Somewhat similar to a company where a small part works remotely, compared to a majority working remotely ✏

vanitasvitae, maybe by february we have vaccination? Than RL meetings really wouldn't be a big deal

Or just quarantine for 14 days before summit 😀

fingers crossed

and i can imagine that more folks will choose to stay at home despite a vaccine

Yeah, without FOSDEM it's less worth traveling to Brussels

maybe instead of decentralized online summit, we do federated online summit? People gather in smaller groups and those join a conference call

If we could do an online sprint there might be merit too.

An online XEP-sprint, that is.

> maybe instead of decentralized online summit, we do federated online summit? People gather in smaller groups and those join a conference call That sounds like a good idea!

We could hack in smaller groups on dofferent topics and every now and then come together online to discuss what has been done and what will need to be done

Hehe I really like the term "federated summit"

that’s a terrible idea

group/room microphones are terrible

Then maybe organize some mics that are handed around?

Physical rooms?

We could go for either.

vanitasvitae, also annoying

and still requires meeting people IRL

I wouldnt say it *requires* people to meet irl

Handing mics around using the postal services seems inefficient though. ✏

0. Welcome

hi!

o/

!

ullo

Seve sent apologies

Right.

1. Minute taker

Ill do it

2. MIssion statement

This is in items for discussion. Was this already discussed?

no

not in a board meeting, at least.

Ok. I did some digging on this not too long ago. If the problem is "did board officially adopt this mission statement?", then I believe the answer to be yes.

I don't have the references handy right now, but that's what I gathered from the various mail threads around the time it was written.

I also do not think the mission conflicts with a neutrality stance.

I disagree with this statement and I guess you're all already aware

Oh, we discussed this on July 16, too.

Yeah we did once

https://logs.xmpp.org/xsf/2020-07-16#2020-07-16-3f57d5757711a34b

From a quick reread, I think we agreed to disagree, where the majority seems to not think this is a problem.

Anything we need to discuss further?

Also related: https://www.mnot.net/blog/2020/08/28/for_the_users, that I linked last week

linked where?

here

I missed it.

I'm still at the same place where I was a couple of months ago: to me, this all feels like a semantics discussion where I've yet to see tangible results.

TL;DR: “So at its heart, The Internet is for End Users is a call for IETF participants to stop pretending that they can ignore the non-technical consequences of their decisions”

Guus, I'm not entirely sure what you call tangible

I think that's actually the main goal of board, to discuss of what you all call meta-stuff

I haven't read that fully yet, but I'm not sure how the XSF is pretending that they can ignore non-technical consequences of their decisions, if that's the implication.

lol

Sorry

?

Even the mission statement is not clear on who are priorities are. It states « freedom, openness », but these words mean nothing without any context and they can be used for anything

So we need to include in the mission statement definitions of all the terms?

Maybe be slightly more specific? For exemple even just mentioning (end-)users

As far as I'm concerned our protocols are open (they are developed and published publicly) and free (anyone can use them)

(And of course applying it afterwards, not just for show)

MattJ, good. Now who are these protocols designed for, what purpose. Does the XSF accept anything that comes by? If so why? Or why not?

The mission statement doesn't live a vacuum. It lives on our website, so it other documents go into details, like https://xmpp.org/about/technology-overview.html. Additionally there are well-established meanings behind these words. I am not sure we need ironclad definitions.

I don't think that level of detail belongs in a mission statement. Maybe in some other document...

Whatever the answer to these questions these are choices that the XSF (board / members) has to make, and choice means taking sides

So no we are not neutral, even if we haven't answered these questions they are answered implicitely

Anyway I encourage you to read that blog article, and the RFC that goes with it

Yes, it might be that we decide to non accept a submission. Usually this is on technical grounds. Sometimes on license issues. I don't think the XSF is 100% neutral. We encourage, and require at a stage, open source implementations. But we do not, as an organisation, favour particular contributors or specific implementations.

Would we accept a spec that encourages tracking users for example

Also just the use of the word "open-source" and not "free software", etc. etc.

Sorry to interrupt, where would I find said mission statement? Is it the first paragraph of https://xmpp.org/about/xmpp-standards-foundation.html ?

https://xmpp.org/about/xsf/mission.html

ty

It's not linked from anywhere :/

We can fill hours of discussions on the difference between Open Source and Free Software.

I'd also like to contribute a small AOB topic to the meeting: the IETF's use of Jabber.

To me, this feels like an never-ending rabbit hole of trying to preemptively define everything - I wonder what the benefit will be of us putting in the time and effort to do so.

This

ralphm, the actual difference is not the point. The mere fact that there are differences is a clue that choices have been made and this is not neutral

The "neutral" thing is being thrown about a lot, did we actually formalize any statement on what this means?

But what is the *problem* with that then? We are not 100% neutral, and I also don't think we claim to be.

MattJ, I haven't seen any :/

So where does this perceived incongruence come from?

The primary neutrality that I am concerned with is one of implementation neutrality, along the lines of the question that was included in the members survey a few years ago

ralphm, don't we? Maybe not publicly but everybody present here at least has heard of the so-called neutrality I'd hope

There has even been a poll a few years ago

i.e. the idea that the XSF should not favour/promote certain XMPP projects above others

It's nothing to do with favouring one or another stance on protocols

Guus, is it not important to define who we're doing what we're doing for?

To me, the XSFs so-called neutrality is focussed on the ability for everyone to implement protocols we standardize in our process, and not actively promote certain implementations over others.

(+english)

I mean, not developers, obviously they're gonna be the ones using the technology, but who is that technology for

And we did have a loooong discussion on the Signal protocol used in our XEPs, *because* of the neutrality stance on this point.

I disagree on why we had that discussion, but that's another story

Well, it was had, and we had an opinion.

And to be clear Dave did raise that discussion to its fullest because of that specific reason.

(hi dwd)

I still disagree, and that's a discussion we can have later if you want. That does relate to that so-called neutrality certainly

And who we're making/accepting protocols for

I note that nobody answered "Would we accept a spec that encourages tracking users for example" :)

Did that issue come up in the last ~20 years?

Nobody has proposed such a spec, so discussing it is helpful how?

and if it did, don't you think we can handle those on a case-by-case basis?

There are many thought experiments we could run along similar lines, but I don't see the benefit

Even if we made a decision now (before any such spec has been submitted), what's to say our stance couldn't change?

we would, as the IETF does. The statement refenced by pep. was accepted by the IAB, not the IETF itself.

Would we preemptively accept such a spec by saying "yes" to your question now?

Guus, I don't, actually. That's a pretty obvious example of what people might be uneasy about, but there are plenty of other exapmles, more subtle

(case by case, I mean)

ralphm, surely it's "only" the IAB (and yeah that's another excuse I hear often), but it still has quite a lot of weight

It all depends on what "tracking users" means in the context of that hypothetical specification.

pep., and that weight is felt in our community too. I don't see us actively opposing that.

I see us talking about things that are opposite to this. What does « neutrality » even mean in the context of this hypothetical spec?

"yeah well we're neutral we'll accept your spec, sure"

A more concrete example maybe. I read that two weeks ago board voted to support/sponsor an event on message encryption or something,

Great, I would probably have agreed as well (even though I now think it might have been a SCAM matter? anyway). But why?

Why do we care about message encryption

I have my answers obviously, and they are political

Not neutral.

(I don't even know what neutral would mean here tbh)

I saw a no-objection mention in minutes. It covers messaging, a space the XSF seems to live in. Why is that a neutrality issue?

Ok so, whatever comes in we'll just accept? Is that what that means to you?

What if tomorrow encrypting things becomes illegal in most of the world? (note that it already is in some countries)

Is the XSF explicitely going to support evil people wanting to encrypt messages

In the context of the earlier discussion on Signal, MLS has come up several times. It makes sense to me to be involved with topics like that, so that if people want to do encryption of message, there's a common way that also works for XMPP.

Secure Messaging Summit, that's happening today and tomorrow?

No only good-doers.

ralphm, but they'd be against the law!!

There's no 'the law'.

Isn't there. Not that I care much about it either and I'd explicitely support encryption even if it was illegal in most countries.

(Because it is illegal in some countries already, as mentioned above.)

Can we come to some kind of conclusion please?

I don't think this discussion is leading in a particular direction. pep.: if you really want to change something here, you need to make it more concrete.

I say we drop the neutral stance, because it doesn't actually mean anything (or at least I'd expect some document defining what this means to us), and we aren't neutral anyway (according to my definition).

Or rather than dropping it, define explicitly in what ways the XSF is neutral and in which not?

Might as well put that in the mission statement or similar document and say how we'll do things and how we won't do things. Instead of clinging to that notion of neutrality

And there maybe we'll realize it's not that easy

As in "the xsf is neutral in regards to implementations, but will protect end-users™"

Fortunately(?) we don't have the same trafic as the IETF

I do not like the optics of removing a 'neutral' stance - even without defining it. "ah, the XSF is no longer neutral" That will not have any positive effects.

pep. if you want to draft a change like that, we can discuss it more concretely. IMO

and what Guus says

as to defining things - I'm not seeing the point, but I'm happy to discuss a concrete suggestion.

Who are we trying to please when we're afraid that the XSF is "no longer neutral"

(I bet that's exactly those I don't really care about)

Cutting it short here. Let's pick this up for a next meeting.

k

Also the AOB will move to next week.

3. Date of Next

+1W

4. Close

wfm

Thanks people!

Thanks

🤷

Sorry Ge0rG I took all your time :p

pep.: wasn't important anyway :

:)

I think we need better time management than this

it was just that I've recently impersonated the XSF and offered our resources for free.

also, can we please have agendas, as we agreed earlier?

Guus: I'm sorry.

Ge0rG: splendid

fwiw, I'm not so fond of defining something I have no stakes in. This neutrality thing is not on the website yet and I'm not going to try to promote it for you

I'd just like that we drop the ball internally once and for all

unfortunately, you seem to be the only one so far that believes there's a ball to drop and we have a problem. Again, make a concrete proposal, and we will discuss it.

To me it seemed like the board members agreed that the XSF is not 100% neutral in all matters, so I agree with ralphm that the ball is already dropped at least among Board members?

I'm not the one claiming that we are neutral

Syndace, might as well drop the word then

Neither is anyone else, to such an extent as you seem to believe?

Indeed

Wait

pep.: Isn't that a good topic for a broader mailing list discussion? I think I'd personally disagree with your goal (sorry) but I do get your point, and think your examples weren't bad to clarify it (i.e. I don't agree with your point being vague). I'd see value in clarifying these points.

Can you rephrase

I see several examples of different kinds of neutrality that have been discussed in the past year, they are not all the same thing, and we don't have a single "neutrality" stance

^

MattJ, right, so that's even more confusing

1) implementation neutrality, which as I said earlier, is the thing that was asked about in the members survey

2) licensing neutrality, which was heavily discussed to death during the OMEMO debate

3) political neutrality, in which some non-tech issues were recently discussed at board meetings, and what action the XSF should take, if any

1) and 2) are explicitly encoded in our Mission and in XEP-0001

A single person can have different views on each of these three "neutralities", and still be a member of the XSF

For 3, if we can't get consensus in Board, we tend to ask our membership and/or wider community.

2) isn't about "neutrality", it's about being permissive, not about allowing any kind of license, right

See how that's also confusing

2) definitely ties into neutrality in that we want *everyone* to be able to implement our protocols. Most of the OMEMO debate was exactly about this point.

neutrality in that sense is that we should not exclude people from implementing the protocols we publish

by applying a limiting license to the protocol itself (Signal), that invalidated that goal

ralphm, I still disagree wrt. the point of the OMEMO debate. I agree it has touched this subject of neutrality but I disagree that was the main purpose

Of course others can have other angles, but the discussion was kicked off on this point particularly, by dwd

The purpose of the OMEMO debate to me was about saying "Hey if we allow specs to mandate GPL implementations, I don't have off-the-shelf pieces I can use anymore for my non-GPL product". And tbh, I couldn't care less about this specific point

That quoted statement is internally inconsistent.

pep.: well, it was about adding a dependency on something that only existed as a GPL implementation

MattJ, so neutrality of implementation still

Ge0rG, sure

Non-GPL product developers would totally ok with implementing MEMO, if the spec would allow for this.

ralphm, how so?

pep.: if there was a permissively-licensed protocol specification, adding it would be neutral.

OMEMO, I meant from scratch

ralphm, yes and note that I'm not talking about OMEMO in the quote

Because it doesn't matter

Indeed, we would reject all such protocols

I think you're missing my point. Anyway..

pep.: the important difference is between "there is only a GPL implementation of this" and "there can only ever be a GPL implementation of this"

Or just ignoring it, dunno

> Or just ignoring it, dunno cmon...

Syndace, I'm genuinely asking :/

Makes more sense to me if you think of it as the protocol and its normative references being incomplete and insufficient to implement the protocol.

pep. yes, I have a track record on ignoring peoples opinions when they don't match mine, and always shutdown discussions

Ah well, that explains it :P

MattJ, so to me the "neutrality" that's been used around for years is really just about allowing anybody to implement our stuff, nothing less nothing more

It doesn't say anything about what we accept or we don't, who our protocols target etc.

(who we're doing all this for)

that'd be #2 from the above list, then

You raise a good point on not being explicit on who we develop protocols for.

Then why are talking about our "neutrality" stance in the context of sponsoring a secure messaging summit? (which is implementation-agnostic)

I think that is orthogonal to the neutrality thing.

MattJ, because it does seem all mixed up

Clearly you think the "neutrality" thing *does* cover more than just implementation neutrality

Well I don't remember a clear statement anywhere so..

(and no I don't remember that one private survey from 2-3-4 years ago)

Ok, in that case, let's assume that there isn't anything beyond that, until shown otherwise.

"Ge0rG> pep.: the important difference is between "there is only a GPL implementation of this" and "there can only ever be a GPL implementation of this"" now seeing this. And as much as I understand the difference, I'm not entirely sure it did matter in the thread. I can quote parts of it if you'd like

pep.: well, it's a complex topic and I'm sure there were misunderstandings both in reading and in writing opinions.

I like the three dimensions of neutrality that MattJ outlined above, and it probably wouldn't hurt to have some sort of Mission Statement Explanation that identifies our position, if any, on each of them

I think 1 and 2 are exactly the same

I read #1 as giving money to developers

No licensing is not the only possible issue. So are things like patents, copyright (on literal strings like with Signal), trademarks.

If you s/money/advertising space/ and then look at the software listing pages

not to drag this on, but I interpret pep.'s point as being: it's impossible to be universally impartial, so the XSF should state in which directions it aims to be and what what actions it takes to pursue those aims

Anyway.. I still don't like the word "neutral", because most often it's a lie. Being neutral most often just means supporting the status quo. Be it when it comes to licenses (What's our impact in terms of what kind of implementation (licenses)'s got the most users?), politics (who are our direct users in terms of their number of users?), etc.

theTedd, and as far as I'm concerned, we do, on a case-by-case basis

On what basis, what document should I refer to

I wouldn't oppose some general document that summarizes our stance in certain areas

But I'm not volunteering to write it, because I see other priorities

Maybe this will get me unelected soon, but: I care relatively little about the XSF as an organization

I think it serves as a decent steward of the protocol, but I think XMPP is bigger than the XSF

The XSF is a means, not a goal.

In terms of the ecosystem, and the directions XMPP needs to go in

Tbh if I didn't care about the XSF as an org I wouldn't be in board right now. It's not exactly going the way I want it (which is why I'm here), it's a huge time sink. If I only cared about XMPP I wouldn't bother with the XSF ✏

who should I poke for a website issue?

(also emotional sink, exactly because it's not going the way I want it, and lots of resistance :))

theTedd, issue, or commteam, but ultimately board members and iteam also have commit rights

The only thing an actual organization is useful for is holding IP (trademark, etc.) and channelling money... and I'm not sure the XSF is excelling at either of these things (though slowly improving)

pep. What if you never get consensus in your favor?

I think the XEP series without an organisation wouldn't work.

Kev, many open-source projects don't have an organization to back them

And I do think the XEP series, for its flaws, is still worthwhile.

and they work just fine

ralphm, I'm probably gonna give up. It's crossed my mind quite a few times. And I'll let you be in piece (finally?) :)

MattJ: But they don't generally provide open standards.

I know I'm not the only one with this kind of opinions, but I'm the only one vocal about it

Open source and open standards are two vastly different domains.

So is free software

all of those terms have become loaded, so different people understand them to mean different things

theTedd, https://thebaffler.com/salvos/the-meme-hustler I encourage you to read this

it was a good read

pep. I would hate to see you go. You say there are others, but rough consensus only works if people speak up. I can see that arguing against the 'rest' can be tiresome. On both ends.

theTedd: It was mentioned elsewhere that https://bitbucket.org/mrtedd/compliance-badges/ has been lost to the gitbucket. Putting those up somewhere else would be nice if it could be arranged.

pep., it looks long, but maybe later ;)

yeah it is long

Zash, I'm going to update it anyway, so I'll fix it then

on the website issue: xmpp.org/extensions/ has a broken link in the head -- <script src="/js/extensions-table.js"... should be "/theme/js/extensions-table.js"

If you can PR I'll merge it

(indeed it's borked)

I agree with Kev on needing an org for standards development. If only for our IPR policy

theTedd, or I can PR if you don't want to do github, that's fine :)

if you can pep., thanks

https://github.com/xsf/xmpp.org/pull/784 somebody to merge?

https://github.com/xsf/xmpp.org/pull/785 another.

Somebody™

YOLO /me clicks button

Zash: > gitbucket Hey!

Yes, I stole it. That's what it's called now.

😂

bithub?

Ge0rG, just wondering if we would need more than 389 + a more or less general definition of jabber:x:data for a token challenge (as defined in 389)

marc: I'm not sure. Are you speaking of data forms? We've had them in IBR already...

This is not my core competence

Ge0rG, yes, data forms

anyway, so far 389 looks like a quite flexible solution

Then we end up replacing data forms with... data forms?

Ge0rG, the difference is that we have proper definition what data elements are necessary for a given "flow"

like for 401 / token: provide a token and an username (optional when not defined by the token)

and can be used automagically by a client

and we can advertise features which is not possible atm