XSF Discussion - 2021-07-01

jonas’, MattJ, we have prior art for a split between a standards track XEP which is “set in stone”, and its live informational sister XEP expected to evolve with changes in the world, in XEP-0300 and XEP-0414.

Splitting XEP-0313 rules into that kind of document could be an idea.

Or even into a registrar maybe?

Although it seems we kind of stopped relying on those.

(I don't think that is a good thing)

(Me neither.)

well actually we rely on registries

but we have noone taking care of them

Oh btw thanks jonas’ for merging the accessibility PRs, the testing tool is happy now. :)

thanks for making them :)

I think we need a standards track XEP with versioning for MAM rules.

Not opposed to having it inside 313

You don't think it would be weird to have XEP-0313 referencing a bunch of experimental XEPs?

while itself in Draft

Implementation details!

Not if it’s not a normative reference.

MattJ: so you say it's okay to not have any rules at all, but having the rules in an experimental document is bad?

“Precise rules for determining which messages to archive for different environments may be specified in separate documents, e.g. XEP-XXXX"

I was referring to: > Ge0rG> Not opposed to having it inside 313

I think I tried to make the point from day 1, that it is weird to not have specific rules inside 313, especially given that those rules seem to be known by server developers anyway

So 313 would be a Draft document referencing elements and namespaces defined in Experimental specs

Ge0rG: I think the rules change over time and ‘known by server developmers’ isn’t exactly true. It’s going to depend on deployment/environment which messages it makes sense to archive.

I would be more comfortable with 313 describing how to query/manage an archive, and another document that defines the (currently unknown and unstable) rules for what servers should put into archives

So I think having a base 313 XEP that you’re not compliant with because your environment doesn’t match the included requirements seems unhelpful.

I'm not sure there were any changes over the last three or so years.

I think putting these rules into 313 now is only going to enshrine brokenness

> I would be more comfortable with 313 describing how to query/manage an archive, and another document that defines the (currently unknown and unstable) rules for what servers should put into archives This works for me (and is what I tried to suggest with my text above)

Kev: We have the Carbons rules inside 0280, with a namespace

Kinda assumes what we put into archives won't affect how we query it.

Ge0rG, there have been changes within the past 3 years for sure

But this is not a hill to die on. I just want the rules written down and discussed

E.g. magic with references / chat markers / whatever.

MattJ: regarding the archival rules?

Holger, you can query it how you want, within the spec. Do you see a reason the spec would need to change based on what gets stored?

Ge0rG, yes

“13:00:51 Ge0rG> I'm not sure there were any changes over the last three or so years.”, Jingle MI comes to mind, as a recent change.

Yes, that (and it's Experimental)

EME, 333, JME

Link Mauve: did that need specific rules, or did it add a store hint?

Ge0rG, rule required

Ge0rG, the examples don’t include a hint, so obviously no client will ever add one.

Weren't hints killed by a previous council?

Zash: the XEP was.

I'm pro hints - not necessarily the current version of the spec, but some protocol-level encoding of whether stuff should be archived

MattJ: Just wanted to note that this is the implicit assumption. Not that I'm assuming the opposite :-) I could imagine we'll end up with clients wanting to filter certain types of stanzas or whatever, but I guess that shouldn't be a show-stopper, if all else fails things can go into additional XEPs.

As soon as it gets into "if you see a payload with this namespace, archive it" - that's not something I would like to see in 313

Because hints belong into the respective original XEP that defines the hint semantics

Holger, sure, that's why the filters are extensible

so it shouldn't be a problem

The thing _I_ am more unhappy with is still how 0313 says "use 0059 but a bit differently".

XFMP.

MattJ: An issue with hints is that I’ve seen in the wild clients issuing hints that tell you to store stupid things.

Kev: how is that an issue with hints and not with stupid clients?

Luckily they are only hints ;)

But yes

Another issue with hints is that the sending client may not know whether the querying client wants it

Ge0rG: It’s an issue with using hints as our mechanism for determining what should be stored, rather than server-side rules, or basing it on the types of stanzas.

Zash, but neither does the server, necessarily

Nope

If the "whether the querying client wants it" question is a real-world problem the solution is filters, no? (Though it becomes more complicated if this should also affect push notifications.)

We briefly discussed the idea at the last(?) summit of in im-ng encoding things so that normal/chat would be stored, and headlines not, and then we’d encode the type of message into protocols, or similar. That’s also fraught with issues, of course.

Kev: yes

But I think it would be a nice way to refine our routing semantics

Exact same problem just with different (nicer) syntax, no?

Holger: kinda, yes. Also kinda not :)

MAM data should be sent in headline for example

Kev: I feel like that's always your answer, no matter what statement I make!

Otherwise a MAM response might end up getting routed to a different client

I think there’s a difference between saying e.g. “Here are hints and you can add this one to store something in the archive”, with a client author deciding CSN really needs it, and “CSN notifications must be sent in headlines"

Holger: Well - yes and no ;)

:-)

Well I don't see much difference between that and saying "CSN notifications must include the X hint"

MattJ: Maybe I’m being overly naive. But I think with hints being additive, you would continue to find clients wanting to add random hints in nonsensical places (as they do at the moment), whereas one might hope that clients would add the right type (although history does suggest otherwise!).

Kev: We can break incompliant clients in visible ways when forklifting to IM-NG

Kev, ralphm, MattJ, arc, dwd: I have a topic for the next board meeting: I would like to suggestion onboard Daniel Brötzmann (wurstsalat) for the CommTeam. He is member now, but has already helped for almost 1,5 years actively on the newsletter but also and the website. He further supported me on other tasks and has knowledge on HTTP/CSS stuff which is really great. I asked Seve and jcbrand already and they would be fine with this. Let me know your feedback ☺ ✏

I’m not Board, I just talk a lot :)

Haha

Kev: sorry I always get confused between you and dwd

Poor dwd.

tahts why I tagged both of you 😃✌

> Kev escribió: > Poor dwd. nothing personal 😃

hi there! thanks for suggesting me, emus!

Board meeting time soon

I've read that as... > Beard meeting time soon

What even is beard meat? Sounds revolting.

As long as nobody is eating yaks...

it's the snack you save for later

Snack the yak!

0. Welcome

Hi!

Ho!

\o/

Most welcome to all! What items do you bring?

See emus note above, and also update CoC.

Updated Coc, even.

arc here?

Yup

full house!

1. Minute taker

I don't know who's up today.

I think it's your turn

Splendid.

2. Daniel Brötzmann for CommTeam

Sounds good to me.

indeed. I motion we add wurstsalat to CommTeam

+1

+1

+1

+1

Carries. Congrats all around!

3. CoC update

So... I updated the CoC, but actually now I think about it I'm not sure if I did the PR for the updates.

dwd, I merged something the other day

jonas’, Oh! So maybe I did?

I sure hope it was a PR for the updates :) ✏

dwd: be so kind and check :-D

there’s also "[Standards] UPDATED: XEP-0458 (Community Code of Conduct)" from tuesday

I should probably fwd that to members@ now that I think about it

So yes, I clearly did that and jonas’ did his Thing.

And I've received no comments at all. Either apathy of else I have addressed everyone's concerns.

So our options are either:

a) We prod people to see if I actually have answered their concerns, or

b) We Last Call to formally do the same.

A non-member sent comments here the other day.

Yeah, per Appendix E the primary discussion venue is standards@, but I think it would be useful to also include members@, as suggested in the appendix.

Zash, Here? Ah, I'll see if I can find them.

I think?

dwd: https://logs.xmpp.org/xsf/2021-06-28?p=h#2021-06-28-a3970c1480b7787b

Oh, interesting. So there's a suggestion that the Conduct Team, which is appointed by the Board, would have the ability to fire a member of the Board. That'd need Bylaw changes, I think.

Yeah, removal of one of us involuntarily requires a majority of the members. I see the point, but I don't really see an alternative.

It is, incidentally, significantly easier to remove a Board member than an XSF Member.

I don't think such a facility is needed. Firing a board member any which way will be a very public event. What would be gained from adding this control instead of having the Conduct Team calling a general meeting and persuing a vote to remove per 4.6 of our bylaws?

So there is no way to fire somebody without a huge theatre show?

I think all the raised concerns were valid (Board members should not be immune from CoC enforcement, but also the Conduct Team should not have the power to remove people from Board at their leisure)

Ge0rG, No... Would you *like* there to be?

Make it so that the Conduct Team consists of enough members to call that meeting if they all agree? No Bylaw changes required!

FWIW, Sam, our by-laws can be found from our home page: About XMPP -> The XSF -> Bylaws (in the side bar)

In any case, the root issue - what happens if one of the Board is the problem - is addressed, I think by having a Conduct Team and allowing people to report concerns to other Board members.

ralphm, Or by "xsf bylaws" in your favourite search engine.

dwd: Sam did find it that way, but complained he couldn't from the site itself

Ah!

(I fixed that only a few months ago)

I feel this discussion is kind of gone a bit off rails

So anyway. The structure of the XSF as a corporate entity means the Board is accountable to the members as the body corpoate, and I think that's OK. If we have a problem where a member of the Board is being abusive to the point that removal is the only remedy, I think it'd be preferable to have the membership eject them.

wfm

So with that, do we want to try for a Last Call, or do we want to see if any other comments are raised for a week or two?

> And I've received no comments at all. Either apathy of else I have addressed everyone's concerns. It’s in my inbox, but I’m tidying up before a week off, so not looked yet.

But given my first round of comments were fairly light, I don’t imagine my next round will be terrible.

dwd: yes

Kev: will two weeks be sufficient to reach the top of your todo list?

One can hope.

Hope seldom is a useful strategy, but whatever works for you :D

arc: any other words on this? ✏

No I'm just reading the conversation

I have an AOB

One thing I did note in the updated CoC is that Board and XSF Members do have a higher trust placed upon them due to the difficulty of removing them. See last para of section3.

Ge0rG: noted

Mostly I just want to re inject at the primary reason for the CoC was manage non-members conduct in chat. And we should probably avoid having things that involve the removal of membership in it.

CoC should be separate from the bylaws.

dwd: indeed. Not sure how to highlight that during member elections, though.

arc, Well, the CoC applies to XSF Members and members of the Board equally. But it cannot add any further mechanisms for the removal of either.

arc: so that seems to align with the opinion of the other directors, right?

indeed, we don't have the power to even add such facilities ourselves

i.e. this would require a proposal to the membership to change the bylaws

arc, Also, more "immediate motivation" than "primary reason".

Sure. Censure should be the most serious outcome of a CoC. If censure is followed by a removal of membership that can be a separate step covered by the bylaws

And yeah it should obviously apply to board members equally

If not more so.

I think the procedures for removing people from (just) board or membership are similar in the requirements.

Exactly. So obviously having a board member censured because of abusive conduct is something we would take very seriously.

Either by asking Chair to call for a special meeting, or by affirmative action

(note that removing from membership doesn't automatically remove from board, as board can have non-members)

It seems we are in agreement. Move on?

Yup.

Sure. There was aob

4. AOB

Ge0rG?

In my position as the representative of the XSF to the German Government, I've received the messenger interoperability questionnaire (by snailmail), filled it out (the online version) with the help of emus and *IM* from freie-messenger.de and submitted it just on time last Monday. It was structured for typical centralized IM service providers, so some questions only made limited sense, like which platforms are covered and what amount of money we make from chat, video and groupchats, respectively. Others, like what benefits there would be for the market from messenger interop, made more sense and got better answers.

There was no response yet, I'll keep you updated when there is something new. Big thanks go to emus and *IM*.

Oh, that's great.

Thanks for working on that! :)

Cool. Can you pass a copy to Board and/or our Secretary? Or more publicly to members if that's reasonable?

ralphm: well, it's a Microsoft Word form in German.

it is a record of a thing

Ge0rG, Not sure which part of that is more of an interop problem.

I'll see if I can get a PDF out of it.

yay!

That will solve all the interop problems.

PDFs are only in English now?

AOB?

Ge0rG, But yes, a copy would be really interesting. PDF/A, but Word is fine too TBH, I can make a PDF/A from it.

Honestly I think we are all pretty versed in Google translate

arc: too bad it isn't pretty versed itself

arc: can you apply google translate to a PDF?

probably

Copy/paste at least

if nothing else

5. Date of Next

+1W

6. Close

Thanks all!

Yay

arc, وتتوفر أنظمة ترجمة أخرى.

Pizza time!

Yes certainly other translations systems are available

Completely off topic, does anyone have any idea and how to clean a chicken's face? I have been giving them hanging melon rings everyday for the last week because of the insanely hot temperatures we've had, but the sticky melon juice plus dirt..

🎉 Official welcome Daniel! (wurstsalat) ✨ MattJ can you now provide the access now?

arc: ¯\_(ツ)_/¯ But are they so allergic to water?

Maybe spray them water in the air, they will like the cooling effect but the same way get clean

arc, A websearch for "How to clean chickens" suggests plucking them first, I'm guessing that's not what you're after...

Yeah I was thinking of like a mister or something. Something light enough that they don't freak out or have the water get in their nostrils

arc: I've heard seeds floating in a bucket of water would keep them hydrated in heat, seems like it would clean them too

That is not a terrible idea

Always best to let them do the work themselves 🥰

emus: already done as soon as the vote passed 🙂

wurstsalat will need to accept the invite

arc, Also this: https://www.omlet.co.uk/guide/chickens/chicken_care/cleaning though it suggests you don't need to bother unless you're showing them.

MattJ: cool

food in a wet hollowed out natural sponge? hmmmm

dunno if you have enough heat to also have water shortage

Baby shampoo is a good idea. Especially since it's around their eyes

And yeah chickens hate water more than cats do, but with the heat we've had here.. hit 47 degrees Monday, we had moments where I had to help them into the pool where they just passed out from heat exhaustion. Hence, the melons.

You may have seen in the news about the heat wave that hit them so the Pacific Northwest. It was very real.

emus, I have access now, thanks everybody!

30° is considered hot here.. 47° was simply record-breaking. And yet we have meteorologist saying that this might be the coolest summer for some time going forward, still.

arc: sorry to hear that

I always find it funny how people have been warned for decades about global warming who are then surprised when global warming happens after they do nothing about it

Isn't that how humans generally deal with things? Doing nothing until it's actually hurting not to do something about it. And then hoping wasn't too late decades ago.

63 people in my city died earlier this week from the heat

Yeah, and we love to blame others for problems we all create. Like is a common American thought that China creates way more greenhouse gases than we do, and anything we do to reduce greenhouse gases will just give China an economic advantage

Cool! We are blaming China as well. China and the US!

Blame Canada!

arc: Corona !!!1!

I think actually the next "pandamic" that does not go away in a life time is climate change

Do we have some more tribal knowledge regarding the RFC errata, beyond https://wiki.xmpp.org/web/XEP_and_RFC_Remarks/RFC_6120:_XMPP-Core

I'm picking up a pattern here, maybe we should just blame anything that starts with C

I just realized that XEPs have a bibtex-entry at the end. Wonderful! Is there a bibtex file for all xeps somewhere, too?

it's probably easy to create from the tooling

Blame Conversations!

Ge0rG, creating the bibtex you mean?

eevvoor: yeah

That empty features thing is why Prosody will now hit you with a stream error instead, if there's no way to proceed with an unauthenticated connection.

Since everything's plugin based, it can be misconfigured such that there's either no starttls or no sasl to offer, which would look like "you're done! go ahead" to some software.

Ge0rG ^

Thus I conclude that there is no all-xeps-bibtex-file. ✏