XMPP Council - 2018-11-21

00:47:52 vanitasvitae has left
01:00:54 vanitasvitae has left
01:00:55 vanitasvitae has joined
02:16:37 labdsf has left
02:16:40 labdsf has joined
02:19:42 labdsf has left
02:19:43 labdsf has joined
02:20:33 labdsf has left
02:20:35 labdsf has joined
02:24:19 vanitasvitae has left
02:24:20 vanitasvitae has joined
02:47:33 moparisthebest has left
02:48:25 moparisthebest has joined
02:49:03 moparisthebest has left
02:49:45 moparisthebest has joined
04:51:43 alex-ray has joined
04:52:25 alex-ray has left
05:51:14 lnj has left
05:51:16 lnj has joined
05:52:17 lnj has left
06:44:44 Tobias has joined
06:50:53 labdsf has left
07:36:16 Remko has joined
08:12:22 labdsf has joined
08:58:30 moparisthebest has joined
08:58:52 moparisthebest has joined
09:02:38 Zash has joined
09:14:27 pep. has left
09:20:30 ralphm has left
10:04:57 vanitasvitae has left
10:05:05 vanitasvitae has joined
10:42:03 daniel has left
10:42:06 daniel has joined
10:53:33 daniel has left
10:53:35 daniel has joined
11:00:56 Zash has left
11:07:23 daniel has left
11:07:25 daniel has joined
11:07:46 moparisthebest has joined
11:08:38 moparisthebest has joined
11:45:23 Zash has left
11:46:24 Zash has left
11:51:07 Zash has left
11:53:16 moparisthebest has joined
11:54:09 moparisthebest has joined
11:57:12 daniel has left
11:57:14 daniel has joined
13:31:18 SamWhited has left
13:31:19 SamWhited has joined
14:00:47 Zash has left
14:06:13 labdsf has left
14:09:45 labdsf has joined
14:17:24 Zash has joined
14:18:34 lnj has joined
14:39:57 moparisthebest has left
14:40:30 moparisthebest has joined
14:46:34 Zash has left
14:48:29 moparisthebest has left
14:48:55 moparisthebest has joined
15:12:38 moparisthebest has left
15:13:00 moparisthebest has joined
15:29:10 moparisthebest has left
15:29:38 moparisthebest has joined
15:30:59 Holger has left
15:38:10 ralphm has left
15:39:41 Holger has left
15:51:20 Ge0rG Still a bunch of votes pending, deadline tomorrow EOB.
15:51:29 Ge0rG or rather EOM?
15:52:26 jonas’ EOM?
15:53:36 Kev We agreed 'end of Council', I believe.
15:53:39 Kev End Of Meeting, I would assume.
15:54:08 dwd has joined
15:54:40 Kev I'm ready to vote on all of mine in the meeting, FWIW.
15:55:07 daniel has left
15:55:21 Ge0rG End Of Meeting, indeed.
15:55:25 Ge0rG Kev: 👍
15:59:46 dwd Right.
16:00:06 dwd 1) Is there anybody out there?
16:00:13 Ge0rG is out there
16:00:39 dwd Kev, SamWhited, daniel ?
16:01:08 daniel hi
16:01:22 peter has joined
16:01:23 Kev I is definitely here.
16:01:55 dwd OK.
16:01:58 dwd 2) Agenda
16:02:19 dwd I am working on the assumption that the only items for a vote are anything outstanding from last week.
16:02:32 dwd (And that nobody is mad enough to try adding new stuff).
16:02:38 dwd So with that in mind:
16:02:49 dwd 3) Outstanding votes
16:03:04 Kev I think it's everything from last week, yes.
16:03:11 Kev i.e. just the same agenda again.
16:03:14 Ge0rG I shortly considered adding items to vote on, but abstained.
16:03:46 dwd I believe I'm up to date, as is Ge0rG.
16:04:00 Ge0rG I've done all my on-list votes.
16:04:01 dwd And SamWhited is too.
16:04:19 Kev Alright. We did agree last week to have discussions on them all this week, rather than just treat them as purely on-list, but w/e.
16:04:30 Ge0rG I anticipated objections to my requirement to make stanza @id = origin-id @id
16:04:58 dwd We certainly can discuss.
16:05:13 Kev 3) Advance XEP-0357 (Push Notifications) to DRAFT - https://xmpp.org/extensions/xep-0357.html -1 4) Advance XEP-0359 (Unique and Stable Stanza IDs) to DRAFT - https://xmpp.org/extensions/xep-0359.html -1 5) PR #692 - XEP-0060: correct "entity" to "<subscription/>" - https://github.com/xsf/xeps/pull/692 +1 6) PR #693 - XEP-0060: Remove unused 'node' attribute on pubsub#event item - https://github.com/xsf/xeps/pull/693 +1 7) PR #715 - XEP-0045: Add missing disco#info feature to example 4, 9, 78 and 218 - https://github.com/xsf/xeps/pull/715 +1 8) PR #716 - XEP-0030: Clarify 'disco#info' feature in 'disco#info' responses - https://github.com/xsf/xeps/pull/716 -1
16:05:39 dwd Ge0rG, I suspect that's desirable, but also potentially difficult if the library sets the stanza's @id at the point of send.
16:05:40 Ge0rG Kev: that lacks rejection rationale
16:05:53 daniel > I anticipated objections to my requirement to make stanza @id = origin-id @id i think i suggested that a few times but the author always objected
16:05:59 Ge0rG dwd: ideally, the library should be the one adding the origin-id then
16:06:13 Ge0rG daniel: yes, I suggested that as well, and got the same reaction.
16:06:23 Ge0rG There was no rationale, so I'm using my Council hat now.
16:06:23 Kev I can't see a reason not to make stanza id = origin id.
16:06:25 dwd Ge0rG, Well, yes. But often, libraries bake in support after various apps have used them first.
16:06:47 jonas’ dwd, then it’ll take a while for libraries to adapt.
16:06:48 Ge0rG dwd: I'm sure this is a problem easier to solve than multiple mismatching ids on a message
16:06:51 dwd Ge0rG, That all said, I won't object very strongly whichever way it goes.
16:06:59 daniel wasn’t the primary reason that smack can’t do it
16:07:10 Ge0rG besides, we need to fix Receipts and LMC with origin-id in place.
16:07:30 dwd Ge0rG, Could a server just add in the origin-id, then?
16:07:44 Ge0rG daniel: even the old version of smack I run makes it possible to extract and change stanza IDs
16:08:06 Ge0rG dwd: that sounds like a reasonable proposal to solve some problem. I'm just not sure which one.
16:08:23 Ge0rG dwd: also not sure whether the rules of 0359 allow injection of origin-id
16:08:37 dwd Ge0rG, If a client wishing to add in origin-id has to add the same id twice, then a server could add in that as well.
16:09:01 dwd Ge0rG, Probably not, as written. My question was whether it made sense to do so.
16:09:16 Ge0rG As already stated, I consider origin-id to be a hack to work around bad servers, so I'd rather burn it.
16:09:42 Ge0rG I can see some benefit in <stanza-id/> for MAM purposes, because you have an independent entity defining _that_ id.
16:10:15 Ge0rG Originally, <origin-id> was a payload you were supposed to stuff into messages you send into a MUC or into transports, in the hope to see the element reflected
16:10:39 Ge0rG But then we got MUC changed to discourage that, and transports probably can't retain XML payloads anyway.
16:10:56 Ge0rG So in my eyes, <origin-id/> could go away.
16:11:09 dwd That I could go along with.
16:11:27 vanitasvitae has left
16:11:35 Ge0rG (and if you have a transport that can maintain XML payloads internally, you surely can send a reflected message to the sending client with the same @id attribute)
16:11:36 vanitasvitae has joined
16:12:08 jonas’ (for example, the transport implementation could inject its own version of the <origin-id/> thing into the "legacy" protocol and convert it back to the @id when the reflection comes back)
16:12:12 dwd Ge0rG, Yes, I was just thinking that. So does that mean there's no point to origin-id excepting some old servers?
16:12:32 Ge0rG the last reason to have <origin-id/> is that it's an indication that the client is using sufficiently-random @id's, and I think that can be signalled in an easier fashion, if needed at all
16:12:49 Ge0rG dwd: that's my understanding, yes.
16:13:02 jonas’ I am amazed. will we really solve this battle in the last sitting of council? probably not because SW won’t be able to react in time...
16:13:02 dwd Ge0rG, I'm not sure that *is* an indication of more than some vague intent.
16:13:05 Ge0rG dwd: excepting some old MUC implementations, to be precise
16:13:06 Kev I think this is a mailing list or after-Council discussion really. We've reached -1 point, I think.
16:13:15 dwd Kev, I think you're right.
16:13:21 Kev I think.
16:13:24 jonas’ aw pity
16:13:37 jonas’ how about "apply these changes and then +1"?
16:13:45 jonas’ where "these changes" points to a PR?
16:13:54 Ge0rG jonas’: not gonna happen in the next 15 mins
16:14:00 dwd Right.
16:14:08 Ge0rG how about "take authorship away and do it right"?
16:14:17 Ge0rG no, I don't volunteer.
16:14:22 jonas’ I do.
16:14:40 dwd Anything else ... XEP-0357? Kev, you'll owe rejection reasons, but I guess those are in your mail to list?
16:14:43 Kev We don't need to take authorship away to do it right, incidentally.
16:14:50 jonas’ I was about to write "challenge accepted!" and do a PR right away, but then I figured that the security considerations of stripping existing stanza-ids probably really can’t be figured out in 15 mins
16:14:53 Ge0rG jonas’: my -1 was already conditioned on "make @id = origin-id", but now it looks like it's just -1
16:14:57 Kev I think my mails today about both 357 and 359 are feedback enough on those.
16:15:13 Kev Especially as I'm the person that needs to make the 357 changes.
16:15:18 dwd True.
16:15:26 dwd Congrats on rejecting your own XEP.
16:15:30 Ge0rG Speaking of taking ownership away.
16:15:44 dwd So, PR #716?
16:16:03 dwd I was in favour of dropping the need to signal disco#info over disco#info.
16:16:03 Ge0rG dwd: is #715 fully voted on already?
16:16:36 Ge0rG dwd: re #716, last Council it was brought up that caps hash calculation would be inconsistent then
16:16:40 dwd Ge0rG, Oh, no, daniel hasn't I don't think.
16:16:42 Ge0rG also it's a MUST from a Final XEP
16:17:03 Kev I think the normative change here is wrong at this stage. I think noting that it'll be elided from many examples is reasonable, and probably even that some implementations may elide it (although what the implications of that are isn't entirely clear. I think it doesn't affect 115, though).
16:17:20 dwd Ge0rG, I think a client that includes it in disco#info includes it in XEP-0115, surely?
16:17:28 Ge0rG I'm not quite sure what Florian was trying to make on the list responding to my -1.
16:17:28 jonas’ at the very least, doing it inconsistently will defeat some 115/390 caches
16:18:06 Ge0rG dwd: I think that having it being defined implicitly leads to corner cases. Also Final XEP.
16:18:36 Kev We /are/ allowed to modify Final XEPs.
16:18:36 dwd Ge0rG, I'd be more convinced about the Final XEP argument if this affected interop, or indeed was actually followed.
16:18:46 Kev "Every effort" not to, though.
16:19:06 Kev dwd: I think the argument is that an implicit feature there might make future 115 bugs.
16:19:11 jonas’ dwd, I think most implementations do follow it
16:19:11 dwd Ge0rG, The fact that many implementations *don't* include disco#info, and everything still works, really does suggest it's wrong.
16:19:28 jonas’ we do have the luck to have a huge stash of disco#info replies from both servers and (a bit outdated) clients if you want to make a survey
16:19:37 Kev My inclination would be to leave the normative language, but note a) that examples don't include it, and b) some implementations elide it.
16:19:43 jonas’ I can modify the muclumubs ( https://search.jabber.network ) bot to make a stat on that
16:19:47 Ge0rG +1 to what Kev suggested.
16:20:19 dwd I can see I'm on the losing side here, and can go along with Kev's suggestion.
16:20:35 Kev Otherwise I'm not strictly opposed to making it optional if we're very sure that the language we introduce couldn't cause caps weirdness with it being implicitly added.
16:21:16 Ge0rG Kev: in my eyes, it's not about the language but about implementations that add it, then do caps, vs. implementations that just do caps.
16:21:26 dwd Right - anyone want to discuss anything else?
16:21:58 Kev I'd like to thank everyone for their work this term :)
16:21:59 dwd Ge0rG, I think if implementations were inconsistent then caps would be failing for them and people would have noticed, FWIW.
16:22:09 Kev I think dwd is right.
16:22:12 dwd Kev, Yes, I was going to do this:
16:22:18 dwd 4) Thanks, All.
16:22:35 Kev I'm worried that we might inadvertently make matters worse by adding language about optionalness. If we're sure we won't, I'm not strictly opposed.
16:22:42 dwd Thanks to everyone for your efforts - not only Council, but jonas’s work on Editor stuff, too.
16:22:49 Kev Indeed.
16:22:52 Ge0rG Thanks to you too, Dave.
16:22:52 jonas’ thanks to council :-)
16:22:59 jonas’ this was a fun ride
16:23:01 Kev And to the Chair.
16:23:04 jonas’ let’s see what the numbers tomorrow bring for next year
16:23:24 dwd Also, this year, we've had a number of useful contributions from the floor, so thanks to anyone who's chipped in.
16:23:27 Ge0rG I've heard we didn't pass that many XEPs to Draft, which is maybe a bit sad.
16:23:39 jonas’ exactly one.
16:23:42 jonas’ and it was the compliance suites
16:23:49 jonas’ three months late or something :)
16:23:53 jonas’ but whatever
16:23:59 Ge0rG jonas’: I've heard you are already preparing Compliance Suite 2019.
16:24:09 jonas’ yeah, that cp sure takes a while...
16:24:15 Kev It's not Council's job to make XEPs ready for advancement, mind, so I don't feel too bad about that.
16:24:26 jonas’ Kev, I didn’t mean to make anyone feel bad anyways
16:24:30 jonas’ just for the record :)
16:25:02 Kev 👍
16:25:15 Ge0rG We have five minutes left. Any technical topics?
16:25:32 Kev Happy for the 359 discussion to continue now I don't have to pay as much attention :)
16:25:53 Ge0rG Kev: I'm not sure what's left to discuss there. I'd rather discuss Push.
16:26:01 jonas’ what are my chances that someone updates the spreadsheet of doom right now so that I don’t have to go over the emails?
16:26:07 Kev 359-2 then :)
16:26:10 Ge0rG Besides, should we propose a meeting time for the new Council?
16:26:19 jonas’ new council will have to figure that out tomorrow night I think
16:26:30 Kev Well, not tomorrow night, but yes.
16:26:43 jonas’ although we could agree on a time; in any case, we know the maximum set of people who’ll be on it anyways
16:26:56 SamWhited oops, sorry, had guests and wasn't paying attention to the time
16:27:03 Ge0rG it's probably overly optimistic to assume that all five candidates will actually receive a majority of votes.
16:27:18 jonas’ Ge0rG, sarcasm?
16:27:21 Ge0rG SamWhited: are you missing any votes?
16:27:32 dwd Ge0rG, Thankfully it needs people to vote against to actually lose.
16:27:46 Ge0rG jonas’: no, just saing it's rather inappropriate to proclaim "I'll probably get reelected anyway"
16:27:46 jonas’ in any case, the wednesday 16:00Z slot wfm
16:27:47 Kev dwd: Simple needs people to not vote for.
16:27:48 jonas’ for now.
16:27:48 SamWhited No, I emailed mine and should be all caught up now
16:27:52 dwd SamWhited, Ooops, soryr - didn't think, it's Turkey Day tomorrow, isn't it.
16:28:19 SamWhited dwd: yup, don't worry, I forgot too and I live here…
16:28:27 dwd Kev, Well, yes, but if they do not vote at all, that's not counted.
16:28:35 daniel has left
16:28:39 Kev I'm not sure that's true.
16:28:51 Kev Someone can submit their vote, for no candidates.
16:28:54 Ge0rG Let's postpone this until after the election.
16:29:01 Kev If a majority of people did that, we'd have no Council.
16:29:04 dwd Kev, True. But that counts as voting.
16:29:06 jonas’ > Third, the individuals elected shall be those receiving the highest percentage of votes cast, up to the limit set by the Members and with the proviso that no individual receiving less than a majority of votes cast shall be elected.
16:29:10 Ge0rG Does memberbot allow that?
16:29:15 jonas’ Ge0rG, yes
16:29:15 dwd Ge0rG, Yes.
16:29:17 jonas’ you can abstain for all five
16:29:27 Kev dwd: Yes,t hat's what I said. It just needs people to not vote 'for'.
16:29:30 dwd Anyway. I think we may be done.
16:29:39 jonas’ thanks again y’all
16:29:46 dwd Kev, Yeah, I just think it's more likely they won't vote at all.
16:30:02 dwd So, for the final time this Council:
16:30:05 Kev Our voting rules are actually broken, because all we need is for enough (non-joke) candidates to apply and we can't form a Council.
16:30:10 dwd 5) Ite, Meeting Est
16:30:15 Kev Diolch, pawb.
16:30:21 Zash Thanks all
16:31:02 jonas’ Kev, as long as this doesn’t happen to board (or whoever has power to fix bylaws), we’re good!
16:31:02 Ge0rG Kev: so we need to define a second ballot process with at most 10 candidates?
16:31:23 dwd Kev, I suspect that it's memberbot breaking. The way the bylaws are written, one could argue that each council candidate is voted for/against individually.
16:31:26 Kev jonas’: I think that for Board we're probably already covered.
16:31:41 Kev dwd: True.
16:31:46 jonas’ dwd, I agree
16:32:05 jonas’ I was a tad surprised to see the memberbot process after reading the bylaws more carefully this time
16:33:20 dwd Meeting's tomorrow night at 1900Z, right?
16:33:52 jonas’ yes
16:35:53 daniel has left
16:38:29 daniel has left
16:39:07 jonas’ also, I don’t think that we need to have an elected board to fix the bylaws... we could have an all-member-vote about the change :)
16:41:49 Kev ISTR (without checking) that in the case that we somehow had no Board elected, Peter could pick his own.
16:41:50 dwd jonas’, We did that one time in a meeting when we realised we'd catastrophically f**ked up. Ah, it was fun.
16:42:24 dwd jonas’, Strangely, XSF Meetings were very well attended for the next few.
16:42:30 jonas’ :D
16:42:35 jonas’ storytime?
16:42:42 SouL is paying attention.
16:43:02 Kev There was a thing. Hopefully there isn't a thing again.
16:43:11 daniel has left
16:45:53 daniel has left
16:50:46 daniel has left
16:52:22 vanitasvitae has left
16:52:24 vanitasvitae has joined
16:54:07 peter Kev: I can't do any such thing because I'm no longer the executive director.
16:56:19 Kev Ah, ok. I thought you still were until they found a new one :)
16:58:52 peter Seems to me we're doing fine with just the council. And as noted the members can always call a special meeting to fix things.
16:59:00 peter er, board
16:59:07 daniel has left
17:00:15 Kev I prefered your first version :)
17:00:24 peter heh
17:00:59 lnj has joined
17:03:40 Ge0rG Kev: accidentally candidated for the wrong panel?
17:05:40 dwd I hope not, otherwise Council's short.
17:05:49 daniel has left
17:06:22 peter even if the Council were short, it could presumably nominate another member after the election, no?
17:06:28 Kev Yeah.
17:06:40 Kev I think we've entered silly territory now.
17:06:41 Kev "now".
17:08:56 Ge0rG I thought the Council is allowed to be short.
17:09:06 jonas’ tallism!
17:09:14 jonas’ heightism!
17:12:05 ralphm has left
17:15:00 peter :-)
17:15:20 dwd has left
17:15:20 Zash xnyphs for new ED?
17:15:39 Zash xnyhps for new ED?
17:16:31 moparisthebest has left
17:16:45 Link Mauve Re the discussion about XEP-0359 here, what you actually want is to revive https://github.com/xsf/xeps/pull/689 right?
17:17:05 moparisthebest has joined
17:19:59 Kev Without reading and just going on the title, maybe :)
17:24:01 Ge0rG Discussion on the editor issue tracker.
17:24:11 jonas’ nooo
17:24:25 Ge0rG > XEP-0359: Replace tabs with spaces. WHY?!
17:24:53 Holger has left
17:26:03 Ge0rG I like #689, except the implementation note says "to be set by the emitting client on every message to a MUC" - I don't see <origin-id/> as a MUC-only thing.
17:28:44 Zash has left
17:36:22 Ge0rG Link Mauve: you could have confused the Council by bringing up #689 right in time for today's Agenda.
17:36:55 Kev Council don't need to be more connfused than usual :p
17:38:02 jonas’ next week, he might be able to confuse himself with that
17:39:42 moparisthebest has left
17:40:07 moparisthebest has joined
17:50:58 vanitasvitae has left
18:20:34 Syndace has joined
18:38:05 labdsf has left
18:38:31 moparisthebest has joined
18:39:09 moparisthebest has joined
19:12:48 Syndace has joined
19:16:41 lnj has left
19:35:34 labdsf has joined
19:41:10 pep. has left
19:43:18 pep. has left
19:46:56 peter has left
19:47:36 labdsf has left
19:48:54 labdsf has joined
19:59:04 moparisthebest has left
19:59:37 moparisthebest has joined
20:22:22 peter has joined
20:31:16 lnj has left
20:44:25 SamWhited has left
20:51:09 Remko has left
21:05:33 lnj has left
21:24:28 Holger has left
21:37:27 Holger has left
21:41:33 moparisthebest has left
21:42:19 moparisthebest has joined
22:04:04 Tobias has joined
22:16:08 labdsf has left
22:18:34 labdsf has joined
22:18:56 peter has left
22:51:15 vanitasvitae has left
23:51:47 Zash has left