GuusI like how !XSF_Martin is single-handedly trying to save us from another event like the crash that happened in February 1637.
GuusI appear to be here, against all odds.
ralphmWho do we have?
pep.Seve was here ealier?
ralphmAlso, I'm expecting a contractor to show up at my door between now and 16:00, so I might have to leave early.
ralphm1. Minute taker
Guus(as if those ever show up on time)
nycoI'm on it: https://mensuel.framapad.org/p/9dye-cfzbnvup1y-XSF-board-weekly-2019-12-19
ralphm2. Board Mailing List
nycomy contractor is there tomorrow morning :)
ralphmI've saw a few mails around this subject, and I'd like to reiterate my view:
ralphmThe email@example.com mailing list is specifically for non-public discussions and silly things like sending regrets for meeting attendance. We aim to do as much as possible in the open, either here or on the members' mailing list.
ralphmNon-public stuff would include discussions on particular individuals, eg. bad behavior. I don't see a lot falling in this category.
pep.I've raised the subject because I haven't seen anything explicit about this.
ralphmAs for the archive, I actually don't know if it is archived currently.
SeveOne thing to mention as well, the firstname.lastname@example.org address can be used as well to receive emails from people outside our communitiy, trying to get in touch with the Board. So in that sense this cannot be public.
pep.Seve, cannot is a strong word
Sevepep., either we create a email@example.com or we cannot make it public
ralphmpep., you may not have, and I'm not entirely sure how to make sure we do going forward. Like a standing list of decisions on a wiki might be a good thing, but I'm not sure how unweildy that could become.
pep.That'd be a first step I guess
MattJA general observation: I think there is much about the running of the XSF that is currently undocumented
pep.Like a "board decisions" category on the wiki or sth
Guuslet's stay on point though.
MattJBoard decisions are buried in minutes, but there are other things that are often just a verbal "This is the way we do things, this is the way we have always done things"
ralphmI'm happy with such a decision list, with identifiers like 20191219-001
ralphmSo you can refer to the original discussion dates.
ralphm(I've seen this in many other orgs)
pep.A bit cryptic to me, but I'm happy to bikeshed once we've agreed that this needs doing
ralphmI was going for a date and a sequence number, but whatever you want.
pep.So do we agree that members@ is the venue we want to use? and board@ only when things need to be private? (when is that even6)
ralphmmotions we will keep a public list of Board decisions, on our wiki, using identifiers that help finding context (much) later.
ralphmpep., yes members is our venue by default
SeveI didn't know that was the point, but to that sentence I'm +1✎
SeveI didn't understand that was the point, but to that sentence I'm +1 ✏
pep.That wasn't (in my agenda items) but it's an underlying issue
pep.What about the list history? Is it kept somewhere?
pep.If not can we? And if so can we open it?
GuusAs far as I know, Peter answered that correctly. We might want to ask iteam to have another look, as I think having history would be nice.
ralphmmotions that we re-affirm Board uses public communications channels (such as firstname.lastname@example.org, email@example.com) as much as possible, and firstname.lastname@example.org is strictly for matters that are (initially) confidential.
ralphm(sorry, I was typing for a while)
SevePerfect ralphm :) +1
KevISTM that if conversations have to be confidential, possibly not archiving them is ok?
ralphmpep., as I said, I honestly don't know if we keep archives of board@. MattJ ?
MattJI don't believe we do
KevI do not believe board@ is archived.
ralphmKev, I think so
ralphmboth motions carry and will be the first to go on the wiki, yay!
GuusFor reference: Peters answer mentioned technological challenges to getting a non-public archive realized.
ralphmI'm curious about those, but I agree with Kev that this might be a thing we shouldn't do
GuusI don't agree with that.
pep.I don't agree with Kev on this point. And I'm curious about the technical issue
Guusit might be very benificial for new boards to be able to read back.
GuusI don't, however, think this is so valuable that we should spend a lot of effort on this.
pep.But if it's a technical issue I'm happy to leave it be until iteam changes software (maybe)
ralphmI do know that I have private mailman lists (as administrator) on ik.nu, and that's not been an issue
KevGuus: I guess the question is "What is the issue that means that members should not be able to access the discussion history?".
KevBecause I'm prepared to bet that lots of those are cases where potential future Board members likely shouldn't be privy to it either.
MattJHaving new Board members able to read previous discussions I think would be a desirable thing - especially in the case where issues are ongoing at the point of a handover
GuusKev members or general public?
Kev(Well, 'lots of those cases'. I believe that such instances are rare in the first place)
ralphmSorry gotta leave.
KevMattJ: I think in such a case it would be very appropriate for old Board to brief new Board directly.
KevGuus: They're basically one and the same :)
MattJBrief != access to raw data
MattJi.e. the outgoing Board then has full control over the narrative passed to the new Board
Guusfor example when discussing negotiations with outside entities
KevGuus: Find a nominal member of the general public who shouldn't have access to a discussion while a member should, and then how that public person would be prevented from joining :)
Guusmight be relevant to keep that under board/membership and not the outside world, pending negotiations (we've had some examples with making our minds up about the way to work with sponsoring, copyright, things like that)
GuusIs there anyone here that wishes us to further look into (technical) possibilities to realize such an archive at this point?
Guus(if not, I'd like to move on)
MattJI'm fine with things as they are right now, though would be open to making this a potential iteam todo later down the road
Guusthat's the same for me
pep.I'd like to have it if it's technically possible. If it's an issue with our software then maybe moving to something else (mailman3?) would be benefitial (also for other things). I'm not rushing iteam but I want this to be considered
SeveAn archive for email@example.com accessible by Board?
SeveThen what MattJ said sounds very good to me, indeed
Guusok - MattJ with your iteam hat on, will you commit to look into technical feasibility?
MattJWith my iteam hat on, iteam has more pressing todo items unless Board considers this high priority (and I'm not sure most of us do)
pep.Well I'm in board and I already don't have access anyway so I guess we got at least a year :-°
Guuspep. can you agree to this being a low-prio thing?
pep.Well, lower priority than other things
GuusI've moved the Trello card to the backburner lane
pep.Not low priority
pep.(If there is a semantical difference here)
Guuslet's circle back to this once iteam has found the time to look into it.
GuusWe've got five minutes let.
GuusI'd like to tackle this item from trello:
Consider speaking out about savedotorg.org
Guusas that is going to be outdated soon.
GuusDo we want to pursue this?
Guus(speaking out publicly)
pep.I don't see why we wouldn't
GuusIn a previous meeting, we postponed discussing this topic, to give board members time to read up.
pep.I don't think we especially have to write something about it
SeveSo do we have to take any actions?
GuusI personally do not want to publish anything about this. Sure, I don't like what's going on, but I am not concerned that it will have the impact big enough for us to speak out against it.
MattJMany larger organisations than ours have already spoken up. That doesn't mean we shouldn't, but also ICANN are reviewing the situation - I'm not sure "speaking up" will make a difference to the outcome in any meaningful way.
pep.But not saying anything about it is also saying something about us.
pep.Especially now that we're aware of it
SeveWhat should be acceptable then? A tweet?
MattJI'm on the fence between speaking up and just avoiding getting involved in the latest internet outrage currently top of peoples' minds
Guuslet me put it this way: I'm not seeing anything that we should voice concerns about. It's more of an internet outrage (thanks Matt) than an actual issue, in my opinion.
GuusI've read some texts about potential far-reaching effects of this that I absolutely don't agree with.
MattJThere is the possibility that the transition will allow the increase of .org pricing. I find it hard to believe this will affect us in any way (if the XSF and other organisations cannot afford their domains, switching is painful but possible)
Guussure, it's a bastard move from people wanting to make money - but I don't feel that this is going to significantly hinder free speech, or anything to that extend.
MattJThen there is the possibility that the deal was under-handed in some way. I don't think we know enough to pass judgement on this.
MattJNor is it necessarily our place to get involved in that debate
MattJ(when as I said, I don't think it would affect the outcome in any way)
Guusdo we want a vote on this?
MattJDon't see why not
pep.I guess there is consensus. I don't especially agree but I'm not going to block it
MattJWe need to fill up that wiki page
Guusmotions that the XSF chooses to not make a public statement about savedotorg.org at this time, without ruling out that future developments might reverse this decision.
GuusOur time is up.
SeveThanks nyco for the minutes :)
pep.I had one but it's been discussed (wiki stuff)
GuusI'd like to mention two things:
Guus1. GSOC has been announced. If we want in, we should act before mid january. Let's think about that.
Guus2. People interested in joining the Summit or FOSDEM should subscribe to the summit mailing list.
Guusdate/time of next
Guusas +1 week is Chrismas, I propose +2w
pep.I can do both.
pep.I'm fine with +2w
SeveI can do next week, but probably not until two weeks after (not sure yet)
GuusI can't make it next week.
SeveSo that settles it :)
Guuslets do +2w
Guusbangs gavel, carefully places it back on Ralphs bench.
SeveYou all too! Thank you for the mmeting
pep.I guess I forgot an AOB, and I already said last week I'd take that to the list. I'd like to stop having meetings be at the center of what we do. Topics for discussion can and should be taken up to the list first IMO, to give a choice to anybody (board mostly but also members) to express their opinion and not be simply ignored because they can't participate in meetings.
dwdHow did Mozilla, which employs a bunch of XMPP experts, end up choosing Matrix? Did anyone know this was being chosen?
pep.They discarded XMPP early on
ZashXMPP is not a product. They were looking for products.
Danieldwd: what xmpp experts do the employ?
pep.and they're using the hosted versions the article says, ugh.
dwdDaniel, Joe, Peter, Jack, M&M. Many aren't very active. But it's massively disappointing to me that XMPP isn't a serious competitor.
MattJWhat Zash said. Not surprising.
MattJXMPP is a protocol, Matrix is a stack from protocol up to official clients for all platforms.
edhelasdwd the issue was not about XMPP, but the lack of client that "looks like" Mattermost/Riot/Slack…
pep.dwd, what Zash said. Name a single viable product to compete with Matrix or Slack that is also free software
Danieldwd: thanks. I was just asking out of curiosity.
DanielTo be fair. The open source tooling we have that you can just start using right now is kinda bad
MattJdwd, they were pretty open about this whole process (which has been going on for months), but I don't think there is any XMPP solution I would personally stand behind as meeting their requirements
MattJAnd I assume the same applies for everyone else who didn't submit a proposal to them
larmaThey also use the modular.im hosted service instead of hosting theirselves. I guess they really just wanted slack, but not slack (= a fully-managed, cloud-hosted, mostly centralized chat solution with good web client)
pep.fwiw Matthew (Matrix) told me directly at POSS that they would work again on the XMPP bridge, so we'll see..
larmaliterally everytime i have met any matrix fan or employee they were telling that 😀
Ge0rGand they immediately start the marketing machine: https://matrix.org/blog/2019/12/19/welcoming-mozilla-to-matrix/
pep.Ge0rG, you surprised?
Ge0rGpep.: not at all. I'm rather sad about the lack of a comparable machinery (or a /product/ to brag about) in xmpp land
larmaThey worked hard for it for about 4 years, so obviously they are happy about the achievement 😀
pep.Ge0rG, bring monies to the XMPP.
larmahttps://discourse.mozilla.org/t/matrix-and-irc-mozillians-custom-client/2911/7 < completely neutral pros and cons there
Ge0rGpep.: hey, that was my argument!
Ge0rGpep.: so how much is an xmpp-based IM product that I can deploy in March 2020?
pep.You'd need money from VCs!
ZashMattJ: So how's that Hype Machine coming?
Ge0rGdid you say it's hyped?
larmapep., Ge0rG, I think the main issue is rather that all XMPP clients have severely different feature sets and UX. Most of them are fine. Conversations is solid, Converse.JS also works pretty good. But both have features that the other one doesn't have, so you end up with the smalest common feature set and also the UI is completely different. Also conversations is more focused on private chat and less on organization chat (converse does a better job for the latter)
Ge0rGlarma: let me tell you about Riot for Android and RiotX ;)
Ge0rGlarma: but you are fully right of course. Which is why I've been pushing for Easy XMPP and Compliance Suite
larmaI don't really think compliance suite will help. It will always be the smalest common feature set everyone can agree on, and that won't be enough
Ge0rGlarma: the alternative is to have a team like Xabber or Tigase provide a set of apps for all major platforms
edhelasi think it's also more about the UI
edhelashaving the same colors, buttons
larmaedhelas, true, also chat bubbles vs the other thingee (is there a name for it)
Ge0rGedhelas: for corporate use, yes. for a community like mozilla, probably not so much
larmaGe0rG, Tigase hardly has the same feature set across platform last time I checked
Ge0rGthe chat bubble has burst in 2004.
Ge0rGlarma: I'm sure that Xabber iOS will be the bestest of all XMPP clients, though.
larmait will probably take the ugly parts of other iOS XMPP clients and combine it with the ugly parts of other Xabber clients 😀
DanielConversations 3.0 will probably get rid of bubbles.
Ge0rGlarma: who am I to judge ugliness of xmpp clients?
DanielBut yes not having an entity that can provide a unified product is a big hurdle
DanielAnd compliance suites and the so called easy xmpp wont solve that
ZashWhat you need is to have a single well-funded company do everything.
Ge0rGDaniel: speaking of easy xmpp, MattJ and Zash and me have a first prototype of XEP-0401 with minor protocol changes at https://gist.github.com/mwild1/088b89ea6073671ff33b4303f222a0e9 - would you mind adding that to conversations?
> Ge0rG, bring monies to the XMPP.
DanielGe0rG: I currently have no plans for that
DanielBut I am happy to see support for pre auth
Ge0rGDaniel: it's also fixing your major issue with 0379 - the tokens are completely handled by the server
edhelassmall question, where can I store the password in Bookmark 2 ? I see it was removed
MattJYou can't (in any standard way)
Ge0rGstore it in the JID :P
ZashMUC Passwords considered harmful
MattJGe0rG, but security!
edhelasso I'll go with members based
Ge0rGedhelas: yeah, private, hidden, members-only
ZashI can't remember seeing an actual password-protected MUC
Ge0rGI'm still member in one.
dwdZash, That's because they're all hidden too.
Ge0rGUnfortunately, all the other members have vanished.
ZashWe got a bug report about handling MUC passwords insecurely in Prosody. But we need to because they're supposed to be included in plain text in invites.
SpaceFreak aka Tracerhas joined
Ge0rGif only we had invitation tokens. What about per-occupant-JID MUC passwords?
ZashThat might be doable without protocol changes?
Ge0rGit totally is
Ge0rGbut you can't request an invitation to a members-only MUC
dwdGe0rG, Can't you?
ZashGe0rG, can you invite me to The Secret Room?
Ge0rGZash: you and me are in the same MUC, and you know my JID and you know that I'm online right now.
Ge0rGZash: imagine a room with multiple admins of which you know none directly.
dwdGe0rG, I meant https://xmpp.org/extensions/xep-0045.html#register and https://xmpp.org/extensions/xep-0045.html#regapprove
Ge0rGdwd: can you do that from the outside?
Ge0rGI haven't seen an implementation of that anyway.
ZashThe text seems to be specifically about that case.
ZashI forget if the Prosody implementation of this allows it, can check.
ZashTho it was more focused on registering your nickname
dwdGuus, Doesn't Openfire do that ^^ ?
ZashDidn't know this was in 0045.
SpaceFreak aka Tracerhas left
GuusRegistering yes. Regapprove, don't know
emus> XMPP is a protocol, Matrix is a stack from protocol up to official clients for all platforms.
Even more, there are more or less central instance in a decentral network which is in my view not there for xmpp unfortunately
Steve Killehas left
pep.I started this: https://wiki.xmpp.org/web/Category:Board. All these templates might not be useful ("Board" might be enough), but that's details
Zashemus, I'm not sure that having a single central gigantic instance is a sign of health for a federated network/protocol. jabber.org being a half-dead zombie is in a way a sign of maturity for XMPP. We can go on without it (but it make make a comback!)
Kev"Half-Dead Zombie" - in the sense of running reliably.
ZashI mean more in how registration has been temporarily closed for years
pep.reliably? Why did we recreate jdev@ on muc.xmpp.org again? :)
KevLack of interest in upgrading it, I think.
KevThat was because of the dhparams I think, wasn't it?
pep.Yep. Which causes many people being inable to join✎
pep.Yep. Which causes many people being unable to join ✏
KevSure, but that has nothing to do with reliability.
pep.To me it is pretty much the definition of it (and we can go on like this for a long time as long as nobody gives a definition of that word. Just like people use "stable" for pretty much everything)
KevI think our understanding of English is probably different.
KevTo me, functioning as intended, consistently, and not failing would be reliable.
emus> emus, I'm not sure that having a single central gigantic instance is a sign of health for a federated network/protocol. jabber.org being a half-dead zombie is in a way a sign of maturity for XMPP. We can go on without it (but it make make a comback!)
Im sure you see that I dont want a gigantic instance, but a resonable guidance / landing boat with some kind of official manner.
still I agree its a good point its working (technically) without it
emusAnd back to the central thing. not every characterisitc of central organisation is bad
emusfor the beginning it can make thing easier. i think you get my point
ZashBased on my hobby archeology, I'd say it was, back in 1999-2004.
ZashBack when you had a single server, a few clients, the Jabber Software Foundation and Jabber Inc.
Guusdwd I checked: no manual approvement of nickname registration in MUC in Openfire.
ZashCan those things be done in MIX?
ZashI think I've seen something similar in XEP-0060, ie subscription approval, so maybe.
Steve Killehas joined
emusZash: I mean for the beginning for newcomers and companies interested