XSF Discussion - 2019-11-21

just came across this https://en.wikipedia.org/wiki/SiteJabber does that infringe on *the trademark* ?

I'm happy I don't have to answer that for them :x

I think the XSF does, since it has _ days to enforce trademark infringement or it loses the right to the trademark

I can't remember the # of days, but it's few, 30/60/90 or so, no problem since we have lawyers on retainer right? :/

It is NOT, I repeat NOT, the XSF's job to police the JABBER™ trademark. That is the responsibility of the trademark holder (Cisco). It is not even our job to police use of the JABBER mark in open-source software implementations of XMPP. Our only job is to sublicense the JABBER mark on request to projects that request sublicensing under the terms of the XSF's (formerly JSF's) agreement with Cisco.

hmm, https://xmpp.org/about/xsf/jabber-trademark/pending-applications the link in there gives 404. Maybe we should ask the person handling trademark@jabber.org (stpeter?) to PR against that page when it happens? (/pending-applications)

I think we have an open issue or PR about that.

and jingle again.. can we force in the XEP for content-add and some other messages to have just one content definition? To solve the case when for example we have in the time out-of-order and some other response for different definitions?

as for me all the jingle has nice ideas but bad design :(

Or we can introduce another error. like ambiguity. and describe best practices.

another way is to always send iq error if we have it for at least one content definition and let a developer decide what's he's doing wrong while sending requests

rion, could you elaborate on the possible issue that arrises when content-add has multiple contents?

I am asking myself why the unique 'name' of the contents doesn't help to resolve ambiguity

flow: for example for incoming transport-replace for 2 jingle-ft. Where for one of them our side as initiator also started transport replace but not sent it yet and should respond with iq error, but should accept the second because our side thinks it's not failed yet

How does one retrieve a list of all MUC rooms that one has an affiliation with, from a particular XMPP service? ✏

not

Guus, disco#search

Guus, One day we should actually design such a thing.

rion, can't you do a transport-accept for the one and a transport-reject for the other? and what does "also started transport replace but not sent it yet and should respond with iq error" mean? why does one has to respond with an iq error here?

also just do verify: we are dealing here with two file transfers in the same jingle session?

flow: if I send transport-reject instead of iq error then remote can think I don't support this transport at all and remove it from the list of available for replace. then consequent transport-replace from my side may fail

flow: yes two file transfers in the same jingle session

it's better to not send transport-replace for multiple applications. but xep doesn't explicitly says that

maybe we should go one step back: what makes the one party send a transport-replace while the other party still believes that the transport is still functional?

Guus: Make a serverside thing that keeps track?

tcp timeouts

Like the MIX PAM thing

or, to put it in a different perspective: shouldn't invovled jingle parties always assume that the other party has a good reason for sending a transport-replace and usually accept it?

flow: I believe there are many such ambiguity cases

I don't think we have reached the point where I see an ambiguous case, but this could very well because I don't have all the information yet

Thanks guys

Zash, but that wouldn’t work because you don’t even get notified if you’re made member of a MUC

(or the notification may get lost in the void)

jonas’: There's something in XEP-0045 about sending notifications for that

I recall that too, but I don’t think that was for member

but maybe I’m wrong

in any case, my second point still holds :)

True

Something something perfect vs good enough?

PubSub has a thing allowing you to ask what nodes you're subscribed to

flow: same for *-info messages. being combined for multiple applications, one of them may report unsupported-info iq error while the other accepts

> shouldn't invovled jingle parties always assume that the other party has a good reason for sending a transport-replace and usually accept it? it break tie-breaking rules

sorry. that's what I meant from the beginning. not out-of-order.

rion, how can a tie-break be needed here, you wrote that "[has] not sent it yet"

but it doesn't matter. basically any kind of IQ error combined with valid response

flow: well it maybe not sent but prepared for sending. or sent but no iq ack yet. does it matter?

I think a document (pastebin, gist, …) which shows the exchanged stanzas and the state of the jingle state machine would be helpful

rion, I don't think tie break is needed if you don't sent anything yet

if for example I spend a few second on collecting candidates, should I abandon them or just sent tie-break?

I prefer the second

I assume that you only need a tie break if there is a chance that the two parties send something which would require one

yep

that's the case.

so if you only locally processed some data but didn't put anything on the wire yet, then there is no tie-break needed, even though you would need one if you had send the stanza

Currently I'am trying to implement something like "convert my prepared request into response". That's weird

for s5b/ice I'll make a candidates cache probably. That will improve performance for such cases. But if standard would forbid such ambiguity cases, that wouldn't be needed.

rion: on a slightly different note: have you done any interop testing with Conversations yet? If not would you be willing to try (with me) at some point

Daniel: tried only with Gajim so far

rion, of course if you are the initator you could force a tie-break and overrule the responder, not sure if there are situations if this is sensible

Daniel: does Conversations support multiple transfers in one session?

but if I understand the initially sketched scenario correctly, then why shouldn't you simply accept the incoming transport-replace, as there is probably a good reason the other party send it

uh, and I am also not sure if we really want to have multiple transports in a single jingle session

In 363, this requirement is odd to me: > Do not provide any kind of access control or security for file retrieval beyond Transport Layer Security in form of HTTPS and long random paths that are impossible to guess. That means everyone who knows the URL SHOULD be able to access it. I understand "requirements" defined in the XEP to be requirements that must be met by the specification, not by the implementation. Does this requirement try to express that the specification is defined in such a way that access control or security (beyond TLS) is not needed, or does it try to express that implementations SHOULD NOT apply additional access control / security?

> Daniel: does Conversations support multiple transfers in one session? rion: no

I always assumed that multi transports in a single jingle session is sensible if both transports are related, like audio and video

but for file transfers, even if you are transfering the pictures of the same cat, I would have probably used different jingle sessions. But I love to hear arguments for using the same session

Unfortunately the general answer to 'can Conversations do x' is usually no when it comes to jingle

flow: maybe sending a collection or something, tho then you could bundle them up in an archive of some sort

It's probably faster

flow: if something is not prohibited then it's allowed. Psi currently allows to select multiple files for sending and they all go into one session. then if any party adds more files to the session they will be accepted automatically without user interaction. (not tested this way though)

rion, If something isn't working we should disallow it though.

Zash, rion: sure, but as conversation nicely demonstrates, you will have a higher probability of success if you use exactly one transport per session

David Cridland: then we need another NS in disco

The problem is that you can't signal support for that

rion, I don't think we do if it's currently unclear.

David Cridland: I mean where multi file transfer is supported by remote :)

rion, Or we just say people should use multiple sessions and/or an archive.

David Cridland: I'm fine with that. Who will add it to the XEP?

rion, You should be able to do the PR yourself I'd have thought?

David Cridland: it won't be accepted anyway we regular reason - breaks compatibility

David Cridland: new corrected xeps won't be accepted either

there is no way to fix xmpp :)

Not with that attitude!

Isn't jingle ft still draft?

Or experimental even

Well, I'm telling you I'd have accepted it in the last Council session. Can't speak for everyone, but it seems reasonable to me.

I can certainly say it won't be accepted if there's no PR to accept.

so guy can you bring this up on a session? then I'll be happy to make a PR if the decision will be to simplify the things.

for now just for ft.

rion, make a PR, but note that council will be re-elected today, so there’s lots of uncertainty and some delay to be expected :)

But... I'd do it for Jingle rather than just FT. Not entire sure you *could* do it for just FT. But I may be wrong, I've not looked at the detail here.

one file transfer = one session is fine. but for rtp is not possible. and for rtp+filetransfer in one session is not clear at all

probably it has to be stated in xep-0166 that some application types should disallow multiple contents per session for simplicity. xep-0234 should apply this rule. and review cases or errors handling when we have multiple contents in a request.

Ah, I think I understand. Yes, that makes sense. If you're transferring a file, don't do anything else with the session.

Maybe fippo might have some views on this if I incant his name.

> rion> David Cridland: it won't be accepted anyway we regular reason - breaks compatibility Not if it is just a recommendation, which seems sensible instead of a hard requirement

there is something I am not sure about, can anyone (try to) explain it to me? I want to compare XMPP's MUCs to Matrix's Channels I didn't spot fundamental differences I mean the groupchat is hosted on a (home)server every participant receives the messages and the participants' server archives the message locally correct? so what is this eventually consistent replication that is sometimes presented as an advantage?

I wouldn't say MUC works like that

> and the participants' server archives the message locally wrong

MIX otoh would be closer

yes, but MIX isn’t eventually consistent

so I want to roughly understand this Matrix replication

> eventually consistent replication Everything is in a DAG, like git. Every event has a previous event, so you can figure out things eventually.

nyco: I think Matrix' main advantage is that the room's messages are linked into a history (a Git-like DAG).

nyco: Plus it's replicated to the servers of all participants, which may or may not be seen as an advantage depending on your trade-offs.

Right, for scalability, that latter part is not great. ✏

yeah, more storage consumption, more bandwidth use

is that resistent to netsplits?

Random message loss due to s2s failures would eventually heal

yes, hence the 'eventual'

I mean, a Matrix channel is hosted on one homeserver, right?

No.

nyco, nit: they're called "rooms"

sorry

Every room is hosted on every participanting homeserver.

that would be: homeserver => bedrooms... (or toilets, maybe?) :)

ok, thx

And the DAG thing means you need merges, and that's where I stopped reading.

so, merge whatN

XMPP s2s is super easy by comparison

?

Well merges without conflict resolution.

merge of what with what?

It basically just means that an event can have multiple parents.

so an event in the Matrix protocol context is a message?

Equivalent to a stanza I suppose

ok, so can be a presence as well... I guess

(not talking about IQ, not sure there is a mechanism in Matrix protocol)

nyco: There's message X in the history, then a netsplit between our homeservers, then we both respond to X, someone else receives both responses and sends a message himself. This last message will have _both_ of our messages as parents in the DAG.

Not sure. They do have a proper separation of persistent and ephemeral events (chat states etc)

Not sure how that fits into the DAG thing

ah ok, so merges happen after netsplits?

Yes.

Or, well, they can occur simply due to normal races.

ouch, so there is netsplits like in IRC in Matrix???

XMPP s2s: Open connection, TLS, auth, send messages. Simple.

yes

nyco, There are in XMPP too. It's just that conversations halt on one side.

proof S2S is simple: I understand it... :)

nyco, can't avoid netsplits on the Internet

David Cridland indeed, I was referring to IRC-like netsplits

well, there is no such thing on XMPP as: half of the room is gone, because

FWIW, I think there's room for both "this chatroom exists as its own entity in a particular domain", and "we are having a group chat which doesn't formally live anywhere".

of course, a MUC room can totally fail if the server fails

You mean XMPP doesn't distribute rooms. Right.

I've never fully understood how Matrix manages chatroom permissions in a distributed manner.

David Cridland I got that as well, it is werid since a Matrix room has an address on a specific homeserver

They are aliases

The same room can have multiple different addresses

oh

nyco, No, that's the name of the room - they're namespaced to a domain, not controlled by it.

The real room address is a long weird string that nobody would remember

MattJ can give examples of Matrix rooms addresses aliases?

So then if you want people to join it, you give it an alias like 'xsf'

got it

Examples here in the spec: https://www.matrix.org/docs/spec/#room-aliases

thx

So #xsf:xmpp.org may be an alias for the same room as #xmpp-standards-foundation:jabber.org

their public search features gives only one alias, is it consistent? is there an alias mapping somewhere?

so, as a user, how do you know it is the same room?

Each server keeps a mapping

A jolly good question :)

meh

Their #matrix:matrix.org room has actually moved a large number of times

uniqueness and human-readability

well... "meh" again

David Cridland, I wouldn't be suprised if distributed permissions are handled through the fact that there's so far only a single server implementation with any real deployment.

Like the time there was a bug in their DAG merge algorithm, and someone took over the room by injecting a room creation event that got preferred over the authentic room creation event

So all the servers accepted this as fact, and they lost control of their primary discussion channel

This reminds me of IRC netsplit merge algorithms

wow...

But they fixed the bug, created a new room, and redirected the alias to their new room

Other upgrades and bug fixes in the protocol have required them to recreate rooms

Is that what room versions are?

Do they have as many room versions as we have groupchat protocols yet?

Yeah, rooms have versions, they can be upgraded, which I think creates a new room, I'm not sure

It's an interesting model, and it solves some problems for some use cases, but I still prefer the simplicity of XMPP

and nobody >5 years ago would have once thought us defending XMPP on the grounds of simplicity ;)

It does go further into the "complicated servers, simple clients" direction tho

Yeah

I've seen an internal client that's basically just a few lines of jQuery

> and nobody >5 years ago would have once thought us defending XMPP on the grounds of simplicity ;) muhahahaha

> I've seen an internal client that's basically just a few lines of jQuery because their C2S "protocol" is a basic RESTful-like API?

nyco: Yes

Fairly simple RESTful BOSH+MAM like thing

yeah, on MongooseIM we had also created a very basic and minimalistic REST-like API iOS and Android clients could be developed very rapidly

While the s2s protocol has distributed transactions and DAGs and merges and whatnot

Lance did something similar, it is not hard, per se, but a trade-off, as you are also limiting what kind of interactions you have.

exactly

on a C2S API, you would have to map the entire XMPP protocol

XMPP-FTW?

so I guess Matrix's VoIP signalling is just another event/message, right? then it goes RTP like SIP, Jingle, etc.

nyco, WebRTC.

Conferencing is literally Jitsi Meet in an <iframe>

Dunno what the 1-to-1 calls are tho

ok... I was not sure

Slack uses Jitsi Meet as well? HipChat used to do so

And Jitsi Meet embeds Prosody! 😀

so Matrix has XMPP in their core :)

MatriXMPP

ok, thx all! :)

Jitsi meet uses XMPP internally

so yeah, what's that part? MUCs?

MUC. LDAP authentication.

thx

https://github.com/jitsi/docker-jitsi-meet#architecture might be a good starting point if you wanna look closer

thx

"Guus> In 363, this requirement is odd to me", I would assume the latter? an implementation should not add additional access control? that is, you get the url you should be able to access the thing behind(?)

pep. I had someone ask me if we could add additional security checks. I'm wondering if that requirement allows for that.

Like I said - I think this 'requirements' are supposed to be requirements for the protocol design, not the implementation based on the XEP - but it'd be good to have clarity.

Generally the url is the password. It has enough entropy that it's not guessable. I agree though that SHOULD NOT could be relaxed. It doesn't entirely make sense in private setups

Again - if the 'requirements' are reflective of the protocol, not the implementation, then there's no issue.

I don't understand

These are two different things: - The protocol defined in this document must be designed in such a way that implementations/deployments need not add additional security checks if they feel that using an URL with enough entropy is safe enough - It is illegal for implementations to add more security checks other than the unguessable URL.

("illegal" is probably a bit stronger than the 'SHOULD' that's in the actual XEP, but I was trying to illustrate the point here)

I see

dunno then ✏

Board meeting time/

ah, yes.

nice.

0. Welcome + Agenda

Welcome to the last Board meeting of this term!

Seve mentioned that he might not make todays meeting.

I think we can do this fast.

Indeed

nyco, MattJ?

yep

Here

1. Minute taker

me

yay

but please do help me

2. License for website content

If I remember correctly, and this was a *long* time ago, the idea was that everything on the website was beholden to our IPR policy, which would mean MIT.

ah, that would be clear

I'd like to note that initially there was a CC license for this, but it got changed to MIT to make it easier to embed XEPs into software projects (see the changelog)

https://mensuel.framapad.org/p/6E9JDfCF5L-XSF-Board-Meeting-2019-11-21

but Peter would probably know more about this.

https://github.com/xsf/xmpp.org/issues/407 calls for _a_ license to be denoted.

Is this is ment to be under MIT, lets add MIT

In any case, I think this does merit better clarity.

Let's check with Peter and then have next Board make a decision soon?

wfm

ok

(because the wording of the IPR Policy isn't clear on this either)

Who is actionable for this?

(pinging stpeter ...)

badly worded

pep. I'll ask Peter, and then next Board.

Thanks

3. Task Boards

Item by nyco on the use of Trello instead of free software alternatives.

I guess this can move to next board?

I'm not in favour of changing things around just because of this, to be honest.

yep, since Trello is proprietary SaaS, we are more and more relying on it

I'm sympathetic, but I'm seeing benefit in using a SaaS project if that means not adding additional tasks to iteam.

I share the sentiment around Trello (I'm not a fan, and there are plenty of decent open alternatives)

Guus, this way, we do nothing, everything is additional things to other people..

But a FOSS solution would require someone to host it, and that's pretty much the same difference to me

The core XMPP standards with the IETF are open, and so are our XEPs, but this doesn't mean that everything the XSF is involved in requires the avoidance of proprietary solutions.

Unless we run it ourselves, which as iteam lead I would veto :)

For now at least

why veto as iTeam?

Maybe you're not on board after tonight, and have all the time of the world, MattJ 😉

nyco, because iteam is currently in no state to run additional services

And iteam is spread a bit thin already

clear

Have you seen the wiki recently? :)

The who has to interact with it should decide what to use.

I edit the wiki, so yes, why?

(off-topic, but Zash put some time into trying to upgrade the wiki recently)

oh about obsolete version? yes

ok then

So we're voting against mandating the abandonment of Trello?

looks like we don't have a consensus to move out of Trello, and iTeam is limited capacity

Otherwise.. there's the mailing list :)

In the future maybe we can improve iteam and host some more services ourselves where it makes sense, but right now it's not even worth considering

ok

We could have a broader discussion on this in the future, e.g. on how to make sure we have resources to work for infrastructure, including possibly funding that work, but this doesn't seem the time. I believe MattJ is also still working on his inventory.

ok

no need to vote then?

I don't think so.

4. Other items on the trello board

badge, adopt character?

I think all of these are either waiting for feedback, or should be handled by the next board anyway.

why put off the adopt a character thing?

put off?

put off discussing it now.

oh

From what I remember we said we wanted to do it, but then I am unsure what the next step was going to be.

we chose one, the process was not clear

then we pay, then what do we use it for?

Marketing marketing marketing?

There wasn't a next step, which is what we could discuss now 🙂

what about marketing marketing marketing?

Deciding for a specific character is where we are now

yes, let's discuss the adoption

I don't think we need to do anything with it, other than knowing that we're supporting the Unicode consortium with it.

again, could be fun to say out loud we adopted this character

Ok, so I need to dig up which character we settled on (one of the speech bubbly ones) and then do it.

Of course the comms team can then have their field day with it.

did we decide to do this? And if so, what level? If we, as board, decide on that, we can put the question of "what character" to memberhsip.

field day?

nyco, look it up

look it up?

Guus I remember something like we kind of were reluction to take time and energy for such a vote, high effort

nyco: https://lmgtfy.com/?q=having+a+field+day

I'm happy for commsteam to pick one.

I'm just not sure if we actually decided on doing this.

and if so, for what level.

I remember we said yes, only discussing which chatacter to pick

I believe we did have consensus in an earlier meeting, I just need to find it in the logs.

CommTeam, not commsteam, could be taken for "Comm Steam" :)

nyco: whatever, again

which is not wrong, btw :)

I'll try hunt it down in the logs.

ok, assuming we did indeed agree to this: shall we have the communication / stream team pick one?

stream... OMG :)

Guus: I think we already picked one

so I'll look up which one

thx ralphm

5. AOB

Ok - so lets ask the treasurer to pay for it?

and be done?

Naturally

Any AOB?

cool.

None here

AOB: it was my pleasure serving this year

Yay!

oh yeah, bye all! :) thx for this term!

I'd like to thank you all for this term!

Yes, thanks :)

Thanks yall

Thank you, dear Board

6. Date of Next

I'm suggesting to keep this timeslot for at least the next meeting, to do a proper handover.

Ge0rG you somehow make it sound as if you're now taking us out back to get put down 😉

So, +1W

+1

+1w wfm

7. Close

Thanks, all!

Guus: sorry, I don't understand

nevermind, my mind wonders and has to many movie references in it.

Oh, and if you can, please join Alex at 19:00 UTC in this same venue!

I actually cannot 😞

maybe from mobile, but unlikely.

I'll try from mobile

https://mensuel.framapad.org/p/6E9JDfCF5L-XSF-Board-Meeting-2019-11-21 please review, edit, correct, fill, etc.

Thanks nyco

👍

nyco added one reasoning, otherwise lgtm

thx!

Re Trello; if that's the way to communicate with Board then I'm kinda sceptical. If it's an internal tool for Board themselves then they can agree on whatever.

I'll send it in 10 min, so you all still have time to review :)

Trello is not only for the Board, SCAM as well, and maybe CommTeam

dunno about iTeam

and yeah the tool is not critical

Zash, it's not for communication with Board, I don't think non-Board have access to it

yes, it's fully open

huh...

board can be contacted here or on board@xmpp.org, or info@xmpp.org for more general stuff

let me check

Our meeting board is 664.

None

> Our meeting board is 664. exactly

Zash anyway, anyone (I guess) can ping the board

there is just not an unique/official way

I send the minutes

tx

Thanks for the minutes

nyco, I chose trello for SCAM because board was using it, but yes I'm also in favor of changing to something more free :)

board@xmpp.org is not public though..

Not used tho, they meet here

I mean the list

Oh, ah

https://tools.ietf.org/html/draft-rosenbergjennings-dispatch-ripp-03 looks like we are a little behind here, need draft for XMPP over http/3

moparisthebest: you got it backwards. We need to update XEP-0332 to HTTP/3

regarding "Direct messages SHOULD be used over PMs in non-anonymous rooms". What benefits does it bring? When it's muc private chat (with muc private jid) everything is quite clear - logic is fully the same as in anonymous room but we can draw a button like "add to roster" But when we use real jid instead for muc private it's like communication with any other contact not from roster: - presences do not work - pubsub doesn't work - we have invent something borrow status,vcard,whatever from muc.

You could draw the line based on whether the contacts are in the roster or not

Pidgin does this iirc

rion: it reduces user confusion: you shouldn't have two different chat windows to the same person

The only time I suggest Pidgin may be doing the right thing...

Directed presence could be used as a kind of temporary subscription

what's wrong with _not_ having avatar and presence in that window?

rion: MUC-PMs are not very reliable

if you are offline, or your friend is offline, or only one of their clients is offline...

"why did I see your message on my PC, but not on my mobile? also why was it in a new window?"

Why do I see message three times?

Why do I (not) see my own messages

Why is it in the same chat view as the group messages and why did I just reply in public

That PR was guided by an impulse that was ignited by biboumi, because on IRC it doesn't even make _any_ sense to have PM routing

Why did you reply from a different JID?

What's a JID?

"Can you use Whatsapp please?"

well I'd prefer to switch to real jid when the contact is already in roster.

Isn't that what the change says?

Hmm it doesn't say roster

wanted to ask what Kev meant in the vote by commenting "(this breaks things)"

I think I said more about this at the time, and intended to say more on-list once Ge0rG starts the discussion there.

I'm still sorry.

But it may be that clients can talk only through the room, and that direct messages will fail.

Ge0rG: No need to be sorry.

e.g. it may be that a user only allows incoming messages from JIDs for which they have exchanged presence.

Those users are broken.

hey guys, anyone ready for our annual meeting?

yes

hi Alex :)

Hi jonas

Hey

yes, hi Alex

Oh, it's the time already!

lets give the rest of the crew 2 or 3 more minutes to wake up ;-)

I was still feeling like CEST

ya, prime time

EVening all.

okay, lets start

here is our Agenda for today: https://wiki.xmpp.org/web/Meeting-Minutes-2019-11-21

1) Call for Quorum

as you can see 39 members voted via proxy, so we have a quorum

2) Items Subject to a Vote

There is a typo in the agenda: > Board and Election,

Board and Council elections, you can see the appications here: https://wiki.xmpp.org/web/Board_and_Council_Elections_2019

fixing the typo now

(relevant gif for "bangs the gavel": https://external-preview.redd.it/7P3i0dah8goJXU7BfsdKkF2SthYeoF6Pq6xeEi8H1kc.gif?width=440&height=230.366492147&s=04324486f65cbb7ff2b0ed265caafd552bc6546d )

🤣

3) Opportunity for XSF members to Vote in the Meeting

anyone here who has not voted via proxy yet?

looks like there are none

then I will shutdown the bot and start working on the results

While Alex carefully counts the votes, who do we have present?

I was mostly wondering if my scare-mongering earlier caused a bit more attendance. :-)

/me

I'm sort of here. :-)

larma: you are missing the trailing space, aren't you?

✏

stpeter, thanks for the clarification about trademark things earlier

Ge0rG, works without for me 😀

larma, that’s not XEP-compliant!

The XEP clearly says that it must be the 4 characters '/', 'm', 'e' and ' '

jonas’ - my pleasure (I mostly respond to GitHub pings, obviously)

result-ish things

Zash, I can still do without, I also tend to use /me inside a sentence

4) Announcement of Voting Results

jonas’, Your Refresh-Fu is mighty.

are you ready?

when you refresh the page at: https://wiki.xmpp.org/web/Meeting-Minutes-2019-11-21#Announcement_of_Voting_Results you can see the results

Well, that's fun. Maybe I should have actually voted for myself. :-)

dun dun DUN!

fun

congrats everyone

this is going to be a fun round of things

top 5 for counsil are: Georg Lukas Daniel Gultsch Jonas Schäfer Kim Alvefur Dave Cridland

is board also fixed at 5 members?

Wow, congrats everyone!

jonas’, It is.

Woop

Alex, I think you should remove the "No" column, as no Yes is not the same as a No

ah, I could’ve inferred that if I was able to count

larma, I was thinking the same thing earlier

Top 5 for board is: Matthew Wild Guus der Kinderen Ralph Meijer Severino Ferrer de la Peñita Maxime Buquet

congrats to everyone

jonas’ - in the far past we had boards with more people, but then we settled on 5

If it's not the same, they aren't redundant, are they?

congrats to the new board!

Voting was difficult this time - so many good candidates!

and thanks to everyone who applied and did not make it this time as well

stpeter, agreed

Alex, Most of all, thanks to you for running the election once again.

stpeter, agreed. Was recasting and chaning my mind a couple of times ;-)

Thanks Alex!

+1 Zash

Congratulations to the winners and thanks for your trust!

+2

oh congrats to new council as well, I missed that message

Alex should get an award of some kind. :-)

he should

For Board, I spent ages picking, and once I'd finally cast my vote realised I hadn't voted for myself.

+3

An xmpp badge!

So yeah, lots of very good candidates.

stpeter, I got, last year in brussels

the famous hat

David Cridland: it would've been very interesting if you had ended up on both top 5 lists

Alex: The ~talking~ voting hat? ✏

Ge0rG, Done it before, it's not a lot of fun, so I'm quite glad I didn't this time around. ✏

yeah, that sounds like a lot of work to be in both

Ge0rG, Of course, it's a little disappointing not to be voted in, so mixed feelings.

shall we agree on a time for a first meeting real quick, David Cridland, Ge0rG and Zash? (I’m trying to summon daniel)

The famous Jabber hat, someone may have a picture of that

5) Any other Business?

jonas’, After the meeting, sure.

David Cridland, wfm

Is that allowed? I was under the impression that you have to decide on one, which is rather political considering that by that time you know who gets shifted into either list

Alex, none from me

Alex, Tempting as it is to propose some arcane motion, none from me either.

Alex: I had some controversial ideas regarding the start of a new council / board period, but was too lazy to make a text proposal for bylaws

6) Formal Adjournment

Alex, Once again, thanks very much.

I motion that we adjourn

+1

+1

Thanks for doing the things with the numbers and stuff, Alex

thanks everyone

Thanks Alex

David Cridland, Ge0rG, Zash, Daniel, usual time, usual place worksforme.

jonas’: I suggest the same

(being Wed 16:00Z xmpp:council@muc.xmpp.org) ✏

wfm

That's fine by me.

David Cridland: with you being a very close sixth, we of course expect you to move forward with your board ideas by proposing them to the elected board!

Ge0rG, And then running away and not helping? Traditional...

LOL

David Cridland: isn't that how everything works?

(okay, maybe "work" is not an adequate term in all of its meanings)

Ge0rG, Sadly. But no, I'll put together a concrete proposal for the conferences stuff. Looking around at improving our discussion of public record is a little harder - that's a lot of work to do without any likelihood of it going anywhere.

David Cridland: what do you have in mind for "our discussion of public record"?

Hello everyone. I managed to miss the meeting almost exactly. Thanks for getting it all organized once again, Alex!

stpeter, I don't have anything in particular, but discussion about XEPs etc are fragmented across Github, the mailing list, and here (at least).

stpeter, Makes it very hard to track as a Council person, and feels very cliquey I suspect as a newcomer.

FTR, editors try to force technical discussions away from github

ah

but that doesn’t solve the chat issue indeed

Ok, I have to leave now, you can ping me if the usual time doesn’t work for anyone, I’m rather flexible.

jonas’, Yeah, and I'm not sure we should be "banning" discussion in chatrooms. Seems very ironic.

David Cridland, indeed

We're not the only ones feeling the tension here - I've seen this in W3C and IETF, too.

stpeter, For sure. Had lengthy chats with Joe Hildebrand a while back about this. It's not helped by the likes of Google making traditional mailing lists difficult from both a UX and technical perspective.

I hope I've made it clear that I don't think an account at some non-federated service should be required for participantion. 🙂

Zash, Absolutely not. But equally, I have very few answers at the moment, just noting problems.

if you are talking about DKIM etc, the mailing list just needs configured correctly

I'm not sure if the XSF's are or not at this moment

Hm?

I thought it was about the discussions being spread out over various places and hard to find

I was responding to "It's not helped by the likes of Google making traditional mailing lists difficult from both a UX and technical perspective."

We need in-reply-to !

moparisthebest, No - DKIM deliberately breaks mailing lists, so you have to configure them incorrectly. But it's more that the average developer is unlikely to have come across a mailing list before, and Gmail et al don't offer any support for them, so they're pretty arcane to use.

Also it would be great to be able to tag certain things as "belongs to XEP 45", after the discussion took place

yea, XSF mailing lists do break DKIM, they should stop doing that

Maybe we need XSF Wave?

niiice

MUC full-text search?

Zash: and XEP tags as reactions?

We do have archives that go way back (modulo disk crash loss)

...for whole threads

moparisthebest, Seriously, it's the other way around. DKIM was created by Google, Facebook, etc without regard to mailing lists (and if they thought about them at all, it was in order to break them).

moparisthebest, no, David Cridland has got it right ;)

I was under the impression that DKIM was created by Amazon, Paypal etc (transactional mail users) without regard for any type of non-transactional mail though

and Yahoo?

here's just the first result for a search about how to fix mailing lists https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html

moparisthebest, but that breaks mailing lists

all decently modern MTAs support all those things, so mailing lists won't be broken in any way

I mean I can complain about how IP isn't a crypto-routed authenticated encrypted protocol by default, and refuse to use IP until google fixes it

or I can just bite the bullet and use IP as-is

Didn't modern Mailman default to 'STRIP_DKIM_SIGNATURE = Yes'?

fix the mailing list already, DKIM/DMARC is never going away

It's all a moot point anyway - my point was more than the UX sucks for most people.

Everything is terrible, news at 11

right UX is a different discussion

but it'd be nice if the XSF mailing list actually delivered mail reliably to people

seems like a bad tradeoff for adding this at the bottom of each mail: Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards-unsubscribe@xmpp.org

isn't that useless?

useless because https://tools.ietf.org/html/rfc2369 and https://tools.ietf.org/html/rfc2919 have been around about as long as XMPP that is

moparisthebest, And 90% of MUAs people actually use don't support them. :-/

I have no objections to removing the footer, especially on the standards@ list (it can be useful for lists where less technical people subscribe).

David Cridland, I would have imagined 90% of MUAs is just gmail, and they support it ?

actually now I'm curious which don't support it

moparisthebest, 2369 isn't supported by Gmail, isn it? I think 2919 is, but only in as much as Google filters based on it automatically.

David Cridland, https://support.google.com/mail/answer/81126?hl=en

In any case, mailing lists, and email in general, is not ideal.

that's support for 2369 List-Unsubscribe

AH, that's RFC 8058, which I'd never even seen before.

"David Cridland> Of course, it's a little disappointing not to be voted in, so mixed feelings.", I agree. I was seeing you in at least one of them

Wait you are, I didn't interpret your message correctly :p

ah indeed, I was just searching List-Unsubscribe, wonder what the difference is...

pep., Oh, I'm on Council still. Just!

pep., But not Board.

oh, 8058 seems to just be "2369 List-Unsubscribe except do it with a single click instead of a confirmation page" ?

this is about a year old https://litmus.com/blog/the-ultimate-guide-to-list-unsubscribe if it's accurate, iOS Mail, gmail, outlook.com, and yahoo all support List-Unsubscribe as a mailto, like we have in our DKIM breaking footer

So hmm, board keeps the same meeting dates I guess? Nothing was mentioned

pep.: it's up to new board to decide

I know, it's just almost the same as last time and nobody said anything.

I'm curious.

pep.: you might say whether the usual time works for you and then just see what happens