moparisthebestcan, or should I say do, any XEPs define new stanzas ?
danielhas left
danielhas joined
efrithas left
SamWhitedmoparisthebest: 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
moparisthebestthat makes sense but I wasn't absolutely positive
moparisthebestthanks 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
Ge0rGmoparisthebest: 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
jonaswdaniel, 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
GuusFellow 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
Flowdwd: "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?
dwdFlow, Pretty sure you know the answer to that. :-)
danielhas left
ZashProsody doesn't initiate piggybacking, everything is weird
Zashhas left
ralphmhas joined
Flowdwd: I can only guess. I still hope we could give clients the ability to provide a resource prefix when using bind 2.0
jonaswI 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.
KevFlow / dwd: Except that the split resource thing actually means that in this case it's just as easy.
Kevjonasw: Debugging is easier if you have friendly parts to the resource, at least.
Flowjonasw, it's not about stable resources, but as debugging aid
FlowKev, didn't get that, sorry. It's just as easy was *what*?
KevIt wasn't important.
FlowKev, It still would be nice to understand what you meant
KevI 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.
KevOr more difficult, anyway.
KevMy bind2 plan is still the split-resource thing we discussed at the summit, to allow for this.
Ge0rGBut what was discussed at the summit is `kev@isode/{random}/{morerandom}`, which is just crazy.
GuusI think what was discussed was `kev@isode/{freeform-butpredictable}/{random}
Ge0rGI'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
dwdI have to admit I'm worried that all jids will now begin "kev@isode".
dwdWE ARE ALL KEVS NOW.
Ge0rGdwd: the double-UUID namespace would allow for a conflict-less mapping of all XMPP users onto kev@isode, at least.
Guusyou can't have enough Kevs.
jonaswGuus, the proper way to add me to Summit is to simply edit the wiki page?
dwdBut 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.
GuusGe0rG: 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 )
Guusjonasw: and show up in Brussels. :)
jonaswwell, yes
dwdAnd right now, I'm more concerned about fragile clients and misbehaving servers when trying to join chatrooms.
Ge0rGGuus: I'm solving that for many years now by using `"yaxim.%08x" % uint.random()`
Guusjonasw: there's a MUC and a mailinglist you might want to subscribe to.
Ge0rGdwd: welcome to MUC hell.
jonaswGuus, URIs?
jonasw(ugh, yet-another-MUC, I’m running out of tabs!)
Guussummit@
Guussummit@muc.xmpp.org
Guussummit@xmpp.org for the mailing list.
jonaswthanks
dwdGe0rG, Well, the actual bug here is in S2S routing, not in MUC per se.
jonaswGuus, is there a recommended check-in/check-out date if one wants to participate in the Summit?
jonaswlike, "latest recommended check-in, earliest possible check-out to get all of summit"
jonaswe.g. would it be sufficient to arrive on the 1st, or is that too close?
jonaswsame for checkout
ralphmhas joined
danielhas left
Ge0rGdwd: I'm sure that the problem is triggered by s2s issues, but it's still a shortcoming of the MUC protocol
Guusjonasw: 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.
jonaswI see
Guusjonasw: maybe take further questions to summit@ ? :)
jonaswsoooo maaaany muuucs :)
jonaswbut sure
jcbrandhas left
archas left
archas joined
la|r|mahas joined
ralphmhas joined
dwdGe0rG, 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.
dwdGe0rG, Not saying I think MUC is perfect, but I don't think it's the MUC protocol at fault in this instance.
Ge0rGdwd: 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
dwdGe0rG, 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).
sonnyhas left
sonnyhas joined
Ge0rGdwd: in that case I'm going to read your mail now
ralphmSo 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
KevAsk for volunteers on-list. Vote at the next meeting. Anyone missing has 7 days to vote.
jcbrandhas left
Alexhas joined
KevIdeally in the new year, in case people are going to be absent due to the holidays.
KevBut something like this :)
MattJYeah, I'd be fine with that
ralphmOk, I'll draft an e-mail about this
nycolet's schedule a dedicated meeting, specifically for this, at an agreed time & date
ralphmnyco: we do. It is called a board meeting
nycoI mean at a different time
nycoone that is specific, short, dedicated, efficient
ralphmcome on, we tried to agree upon a date for the last few meetings and didn't get everyone to respond (in time)
ralphmThese meetings were short (30min) and efficient.
MattJYeah, this is the time and day that everyone agreed on
ralphmOk. Given the rest of the agenda and the lack of 2 people, I suggest we adjourn.
dwdMartin's ill. Or as he put it this morning, developing a closer relationship with the toilet. Sorry, should have passed that on.
ZashQuestion: Why does the new board and council go "live" right after elections?
nycohas left
GuusZash: the bylaws state that an elected official holds office until a successor has been appointed (paraphrased).
GuusI don't know why that was put in.
GuusHaving more procedure would add complexity. If there's benefit to it, I'd be open to changes.
Guuswhy are you asking?
remkohas joined
ZashWondering about having a transition period to ease handoff.
GuusI'm not sure if it'd meaningfully ease things. The added complexity might outweigh it.
ZashBut 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)
jonaswdwd, ugh, I hope Martin gets well soon!
Zashhas left
Alexhas left
Alexhas joined
Alexhas left
Alexhas joined
jubalhhas left
jmpmanhas joined
KevI don't think you need concurrent or delayed responsibilities to do handover.
KevIt'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
dwdKev, 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
ZashLike, elect half the board at a time?
Ge0rGWe have that process with the XSF Membership.
sonnyhas left
sonnyhas joined
sonnyhas joined
sonnyhas joined
Tobiaswe 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
moparisthebestit wouldn't be bad to kind of interleave them with member votes, that would actually bring number of votes per year down
moparisthebestlike we vote for members 4 times a year, we could vote for council/board 2 of those times also
Ge0rGbut then we only vote for half the board.
Ge0rGthe process will be... challenging
moparisthebestwhy?
@Alacerhas joined
danielhas left
sezuanhas joined
Alexhas joined
sezuanhas left
sezuanhas joined
nyco2.5 humans?
moparisthebestI think we could divide it sanely :P
tuxhas left
GuusI'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
nycowell, refreshing half the team mid-term is a good practice, generally
given we are short on resource and engagement, that would generate onboarding overhead
XSF Discussion - 2017-12-14