XSF Discussion - 2017-12-14

can, or should I say do, any XEPs define new stanzas ?

moparisthebest: no, and no. You can define payloads to be transmitted in existing stanzas or new unroutable top level elements, but not new routable stanzas with their own delivery semantics.

that makes sense but I wasn't absolutely positive

thanks SamWhited

moparisthebest: if you define a new routable stanza type, you'll have to change all existing clients and servers

daniel, please re-send the council minutes to standards@

Fellow board members: I've mentioned this in mail last week, but didn't get any ack, so just in case it was missed: I won't be able to make todays meeting.

dwd: "I deliberately use a fixed resource string here because it makes debugging much easier.", so what do you think about bind 2.0 not allowing for that?

Flow, Pretty sure you know the answer to that. :-)

Prosody doesn't initiate piggybacking, everything is weird

dwd: I can only guess. I still hope we could give clients the ability to provide a resource prefix when using bind 2.0

I don’t see a use in a prefix. It can’t be used for addressing, which would be my main use-case for stable resources.

Flow / dwd: Except that the split resource thing actually means that in this case it's just as easy.

jonasw: Debugging is easier if you have friendly parts to the resource, at least.

jonasw, it's not about stable resources, but as debugging aid

Kev, didn't get that, sorry. It's just as easy was *what*?

It wasn't important.

Kev, It still would be nice to understand what you meant

I think that a resource of kev@isode/client1/{random} is as easy to debug as kev@isode/client1 in terms of grepping and following logs. While kev@isode/{random} does definitely make it difficult.

Or more difficult, anyway.

My bind2 plan is still the split-resource thing we discussed at the summit, to allow for this.

But what was discussed at the summit is `kev@isode/{random}/{morerandom}`, which is just crazy.

I think what was discussed was `kev@isode/{freeform-butpredictable}/{random}

I'm pretty sure the consensus was kev@isode/{client-generated-uuid}/{server-generated-uuid} with a strong implication of those horrible 128-bit-hex-blobs

I have to admit I'm worried that all jids will now begin "kev@isode".

WE ARE ALL KEVS NOW.

dwd: the double-UUID namespace would allow for a conflict-less mapping of all XMPP users onto kev@isode, at least.

you can't have enough Kevs.

Guus, the proper way to add me to Summit is to simply edit the wiki page?

But anyway. I understand that there is benefit in some implementations to enforce a server-written portion of the resource. I don't think this benefit is applicable to all implementations.

Ge0rG: I was under the impression that we discussed a combination of a human-recognizable identifier (for easy debugging/grepping), and a random part (to prevent predictable full jids). But then again, I'm enjoying the sight of a new castle every 7 seconds or so.

(Guus: this is the wiki page I’m talking about: https://wiki.xmpp.org/web/Summit_22 )

jonasw: and show up in Brussels. :)

well, yes

And right now, I'm more concerned about fragile clients and misbehaving servers when trying to join chatrooms.

Guus: I'm solving that for many years now by using `"yaxim.%08x" % uint.random()`

jonasw: there's a MUC and a mailinglist you might want to subscribe to.

dwd: welcome to MUC hell.

Guus, URIs?

(ugh, yet-another-MUC, I’m running out of tabs!)

summit@

summit@muc.xmpp.org

summit@xmpp.org for the mailing list.

thanks

Ge0rG, Well, the actual bug here is in S2S routing, not in MUC per se.

Guus, is there a recommended check-in/check-out date if one wants to participate in the Summit?

like, "latest recommended check-in, earliest possible check-out to get all of summit"

e.g. would it be sufficient to arrive on the 1st, or is that too close?

same for checkout

dwd: I'm sure that the problem is triggered by s2s issues, but it's still a shortcoming of the MUC protocol

jonasw: having attended only once, I'm not much of an expert, but last year, the summit was two full days. From the Netherlands, I arrived in the morning, and was able to attend the entire day, then spent four days to also be able to visit FOSDEM. I think I travelled back on Monday, to catch all of FOSDEM.

I see

jonasw: maybe take further questions to summit@ ? :)

soooo maaaany muuucs :)

but sure

Ge0rG, What's the shortcoming? If traffic is dropped due to a bug, and a client relies on perfect network conditions, then I think blaming the protocol is a little excessive.

Ge0rG, Not saying I think MUC is perfect, but I don't think it's the MUC protocol at fault in this instance.

dwd: the MUC protocol lacks provisions to test whether the client is still connected and to restore connectivity. The existing workarounds are very complicated and unreliable

Ge0rG, Sure. But the sequence I showed occured on initial client connect. The client *knows* that it's disconnected from the chatroom (the MUC might not, but we have a simple atomic solution there).

dwd: in that case I'm going to read your mail now

XSF Board Meeting | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

0. Welcome + Agenda

hey

Hi! Who do we have?

many

MattJ, Guus, Martin?

ralphm: in absent as announced

Guus said he can't be there

Hey

I missed that

So we are lacking two. I am a bit worried about appointing a Chair for this Board's term. Since we haven't been complete since the start of the term, we haven't been able to do this, and we have to figure out how to resolve this. I don't think hoping we are complete a next meeting is a good strategy. Ideas welcome

Ask for volunteers on-list. Vote at the next meeting. Anyone missing has 7 days to vote.

Ideally in the new year, in case people are going to be absent due to the holidays.

But something like this :)

Yeah, I'd be fine with that

Ok, I'll draft an e-mail about this

let's schedule a dedicated meeting, specifically for this, at an agreed time & date

nyco: we do. It is called a board meeting

I mean at a different time

one that is specific, short, dedicated, efficient

come on, we tried to agree upon a date for the last few meetings and didn't get everyone to respond (in time)

These meetings were short (30min) and efficient.

Yeah, this is the time and day that everyone agreed on

Ok. Given the rest of the agenda and the lack of 2 people, I suggest we adjourn.

I'll send that e-mail and we meet in +1

W

wfm

Thanks ralphm

XSF Discussion | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

Martin's ill. Or as he put it this morning, developing a closer relationship with the toilet. Sorry, should have passed that on.

Question: Why does the new board and council go "live" right after elections?

Zash: the bylaws state that an elected official holds office until a successor has been appointed (paraphrased).

I don't know why that was put in.

Having more procedure would add complexity. If there's benefit to it, I'd be open to changes.

why are you asking?

Wondering about having a transition period to ease handoff.

I'm not sure if it'd meaningfully ease things. The added complexity might outweigh it.

But suddenly I'm unsure if any of the orgs I've been involved had that or not.

(also, the current board differs with just one person from last years board - not sure if there is the need for much transitioning)

dwd, ugh, I hope Martin gets well soon!

I don't think you need concurrent or delayed responsibilities to do handover.

It's not like a job where you leave the building.

Kev, I have pondered, in the past, suggesting that we stagger elections though, to try and maintain some sort of continuity. But not enough to actually propose anything concrete.

Like, elect half the board at a time?

We have that process with the XSF Membership.

we do indeed

it wouldn't be bad to kind of interleave them with member votes, that would actually bring number of votes per year down

like we vote for members 4 times a year, we could vote for council/board 2 of those times also

but then we only vote for half the board.

the process will be... challenging

why?

2.5 humans?

I think we could divide it sanely :P

I'm not opposed to any of this, but I'm not seeing real benefit either.

well, refreshing half the team mid-term is a good practice, generally given we are short on resource and engagement, that would generate onboarding overhead