can, or should I say do, any XEPs define new stanzas ?
danielhas left
danielhas joined
efrithas left
SamWhited
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.
danielhas left
danielhas joined
moparisthebest
that makes sense but I wasn't absolutely positive
moparisthebest
thanks SamWhited
la|r|mahas left
SamWhitedhas left
SamWhitedhas left
la|r|mahas joined
SamWhitedhas left
uchas left
zinidhas left
zinidhas joined
waqashas joined
danielhas left
danielhas joined
@Alacerhas joined
danielhas left
danielhas joined
danielhas left
@Alacerhas left
danielhas joined
waqashas left
waqashas joined
waqashas left
danielhas left
SamWhitedhas left
zinidhas left
zinidhas joined
danielhas joined
danielhas left
danielhas joined
danielhas left
danielhas joined
@Alacerhas left
@Alacerhas joined
danielhas left
nycohas left
danielhas joined
nycohas joined
@Alacerhas left
@Alacerhas joined
ralphmhas joined
valohas left
valohas joined
Tobiashas left
Tobiashas joined
danielhas left
danielhas joined
danielhas left
danielhas joined
moparisthebesthas joined
zinidhas left
ralphmhas joined
Ge0rG
moparisthebest: if you define a new routable stanza type, you'll have to change all existing clients and servers
uchas left
uchas joined
marchas joined
danielhas left
ralphmhas joined
Ge0rGhas left
tim@boese-ban.dehas joined
danielhas left
danielhas left
danielhas joined
ralphmhas joined
tim@boese-ban.dehas left
Ge0rGhas joined
Kevhas joined
Steve Killehas left
Steve Killehas joined
ralphmhas joined
danielhas left
danielhas joined
danielhas left
danielhas joined
Kevhas left
efrithas joined
jonaswhas left
danielhas left
nycohas left
nycohas joined
danielhas left
jubalhhas joined
Zashhas joined
Steve Killehas left
ralphmhas joined
ralphmhas joined
jonasw
daniel, please re-send the council minutes to standards@
Kevhas joined
danielhas left
nycohas left
nycohas joined
goffihas joined
ralphmhas joined
valohas left
valohas joined
Tobiashas joined
Tobiashas joined
ralphmhas joined
@Alacerhas left
danielhas left
danielhas joined
Zashhas left
Zashhas left
Zashhas left
Zashhas left
Zashhas left
Zashhas left
Zashhas left
Zashhas left
@Alacerhas joined
dwdhas joined
efrithas left
ralphmhas joined
@Alacerhas left
ralphmhas left
@Alacerhas joined
jubalhhas left
archas left
archas joined
archas left
archas joined
archas left
archas joined
Guus
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.
ralphmhas joined
jcbrandhas joined
debaclehas joined
Ge0rGhas left
mimi89999has left
Ge0rGhas left
Ge0rGhas left
Zashhas left
lskdjfhas joined
danielhas left
danielhas left
danielhas joined
Flow
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?
dwd
Flow, Pretty sure you know the answer to that. :-)
danielhas left
Zash
Prosody doesn't initiate piggybacking, everything is weird
Zashhas left
ralphmhas joined
Flow
dwd: I can only guess. I still hope we could give clients the ability to provide a resource prefix when using bind 2.0
jonasw
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.
Kev
Flow / dwd: Except that the split resource thing actually means that in this case it's just as easy.
Kev
jonasw: Debugging is easier if you have friendly parts to the resource, at least.
Flow
jonasw, it's not about stable resources, but as debugging aid
Flow
Kev, didn't get that, sorry. It's just as easy was *what*?
Kev
It wasn't important.
Flow
Kev, It still would be nice to understand what you meant
Kev
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.
Kev
Or more difficult, anyway.
Kev
My bind2 plan is still the split-resource thing we discussed at the summit, to allow for this.
Ge0rG
But what was discussed at the summit is `kev@isode/{random}/{morerandom}`, which is just crazy.
Guus
I think what was discussed was `kev@isode/{freeform-butpredictable}/{random}
Ge0rG
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
dwd
I have to admit I'm worried that all jids will now begin "kev@isode".
dwd
WE ARE ALL KEVS NOW.
Ge0rG
dwd: the double-UUID namespace would allow for a conflict-less mapping of all XMPP users onto kev@isode, at least.
Guus
you can't have enough Kevs.
jonasw
Guus, the proper way to add me to Summit is to simply edit the wiki page?
dwd
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.
Guus
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.
goffihas left
jonasw
(Guus: this is the wiki page I’m talking about: https://wiki.xmpp.org/web/Summit_22 )
Guus
jonasw: and show up in Brussels. :)
jonasw
well, yes
dwd
And right now, I'm more concerned about fragile clients and misbehaving servers when trying to join chatrooms.
Ge0rG
Guus: I'm solving that for many years now by using `"yaxim.%08x" % uint.random()`
Guus
jonasw: there's a MUC and a mailinglist you might want to subscribe to.
Ge0rG
dwd: welcome to MUC hell.
jonasw
Guus, URIs?
jonasw
(ugh, yet-another-MUC, I’m running out of tabs!)
Guus
summit@
Guus
summit@muc.xmpp.org
Guus
summit@xmpp.org for the mailing list.
jonasw
thanks
dwd
Ge0rG, Well, the actual bug here is in S2S routing, not in MUC per se.
jonasw
Guus, is there a recommended check-in/check-out date if one wants to participate in the Summit?
jonasw
like, "latest recommended check-in, earliest possible check-out to get all of summit"
jonasw
e.g. would it be sufficient to arrive on the 1st, or is that too close?
jonasw
same for checkout
ralphmhas joined
danielhas left
Ge0rG
dwd: I'm sure that the problem is triggered by s2s issues, but it's still a shortcoming of the MUC protocol
Guus
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.
jonasw
I see
Guus
jonasw: maybe take further questions to summit@ ? :)
jonasw
soooo maaaany muuucs :)
jonasw
but sure
jcbrandhas left
archas left
archas joined
la|r|mahas joined
ralphmhas joined
dwd
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.
dwd
Ge0rG, Not saying I think MUC is perfect, but I don't think it's the MUC protocol at fault in this instance.
Ge0rG
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
lumihas joined
dwd
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).
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
Kev
Ask for volunteers on-list. Vote at the next meeting. Anyone missing has 7 days to vote.
jcbrandhas left
Alexhas joined
Kev
Ideally in the new year, in case people are going to be absent due to the holidays.
Kev
But something like this :)
MattJ
Yeah, I'd be fine with that
ralphm
Ok, I'll draft an e-mail about this
nyco
let's schedule a dedicated meeting, specifically for this, at an agreed time & date
ralphm
nyco: we do. It is called a board meeting
nyco
I mean at a different time
nyco
one that is specific, short, dedicated, efficient
ralphm
come on, we tried to agree upon a date for the last few meetings and didn't get everyone to respond (in time)
ralphm
These meetings were short (30min) and efficient.
MattJ
Yeah, this is the time and day that everyone agreed on
ralphm
Ok. Given the rest of the agenda and the lack of 2 people, I suggest we adjourn.
Martin's ill. Or as he put it this morning, developing a closer relationship with the toilet. Sorry, should have passed that on.
Zash
Question: Why does the new board and council go "live" right after elections?
nycohas left
Guus
Zash: the bylaws state that an elected official holds office until a successor has been appointed (paraphrased).
Guus
I don't know why that was put in.
Guus
Having more procedure would add complexity. If there's benefit to it, I'd be open to changes.
Guus
why are you asking?
remkohas joined
Zash
Wondering about having a transition period to ease handoff.
Guus
I'm not sure if it'd meaningfully ease things. The added complexity might outweigh it.
Zash
But suddenly I'm unsure if any of the orgs I've been involved had that or not.
Guus
(also, the current board differs with just one person from last years board - not sure if there is the need for much transitioning)
jonasw
dwd, ugh, I hope Martin gets well soon!
Zashhas left
Alexhas left
Alexhas joined
Alexhas left
Alexhas joined
jubalhhas left
jmpmanhas joined
Kev
I don't think you need concurrent or delayed responsibilities to do handover.
Kev
It's not like a job where you leave the building.
Alexhas left
jmpmanhas joined
efrithas joined
jerehas joined
ralphmhas left
ralphmhas joined
jcbrandhas left
jcbrandhas joined
jmpmanhas joined
jmpmanhas joined
danielhas left
danielhas left
archas left
archas joined
archas left
archas joined
jubalhhas joined
jcbrandhas left
ralphmhas left
Ge0rGhas joined
goffihas left
danielhas left
dwd
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.
nycohas left
efrithas left
danielhas left
Zash
Like, elect half the board at a time?
Ge0rG
We have that process with the XSF Membership.
sonnyhas left
sonnyhas joined
sonnyhas joined
sonnyhas joined
Tobias
we do indeed
danielhas left
sonnyhas left
sonnyhas joined
Ge0rGhas joined
sonnyhas joined
sonnyhas joined
jcbrandhas joined
jcbrandhas left
jcbrandhas joined
jerehas joined
@Alacerhas left
jcbrandhas left
moparisthebest
it wouldn't be bad to kind of interleave them with member votes, that would actually bring number of votes per year down
moparisthebest
like we vote for members 4 times a year, we could vote for council/board 2 of those times also
Ge0rG
but then we only vote for half the board.
Ge0rG
the process will be... challenging
moparisthebest
why?
@Alacerhas joined
danielhas left
sezuanhas joined
Alexhas joined
sezuanhas left
sezuanhas joined
nyco
2.5 humans?
moparisthebest
I think we could divide it sanely :P
tuxhas left
Guus
I'm not opposed to any of this, but I'm not seeing real benefit either.
jubalhhas left
jcbrandhas joined
tuxhas left
lumihas joined
danielhas left
Alexhas left
nyco
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