jonas’shall handle it together with that message moderation protoxep
Link MauveOn-list too.
dwdI'm +1. But willing to be told I'm wrong later. :-)
Ge0rGreaction, retraction, attach-to-fastening
dwdGe0rG, Retracting reactions is perfectly fine.
Ge0rGdwd: what about correcting retracted reactions?
Ge0rGWe could probaby go on with this forever.
jonas’let’s move on.
Ge0rGDid I mention I still have some more AOBs pending?
dwdOK, we'll move to:
dwdb) https://github.com/xsf/xeps/pull/840
jonas’I’m not sure if that needs a feature
pep.context: https://mail.jabber.org/pipermail/standards/2019-October/036502.html as it's not mentioned in the PR
dwdIs this suggesting that we has an infinity symbol as a legal value?
jonas’dwd, I think so
ZashAn "max_items=current + 1 plz" option would be handy
Wojtekhas joined
pep.dwd, I assume it's just a placeholder, council can of course bikeshed on what to put as a value :P
Ge0rGI'm not sure whether "∞" is supposed to be a verbatim value for that field, or just some elaborate joke.
Ge0rGOh, what dwd said.
Syndacehas joined
Ge0rGIs the value to be transmitted by the server or by the client?
dwdWell, I'll -1 this then. Having "-1" or empty seems sane for unlimited, but not novel unicode glyphs.
Ge0rGI'm with dwd here.
Ge0rGAlso I don't understand the implied semantics of that value.
daniel> Is the value to be transmitted by the server or by the client?
both; depending on context
Link Mauve-1 would be bad imo.
jonas’In any case, the text needs to be clearer on what the actual value on the wire for "the server limit" is.
dwdpep., It's really not for Council to do stuff like that.
KevHere, sorry.
Link MauveHaving it mean arbitrarily-high value wouldn’t be nice.
pep.dwd, you mean it's not for council to provide feedback?
jonas’Link Mauve, but it does that when you cast it to uint ;-)
jonas’(* on some platforms)
Link Mauvejonas’, so with an example?
Ge0rGjonas’: don't get me started about the semantics of 0198 stanza counter overflow.
jonas’Ge0rG, :-)
Ge0rGjonas’: it's NOT funny
dwdpep., Sure, we can provide feedback that a symbol I can't remember how to type isn't going to work.
dwdAnyone else voting?
KevI'd have thought "" would be better than ∞.
KevBut then so would anything I can type.
jonas’I meant to say -1
Ge0rGwe need a value that is a distinct "explicitly set to unlimited", which "" maybe is not.
Kev-1 for untypable glyphs in particular.
KevGe0rG: It's not actually unlimited, is it? It's 'largest server-allowed value'.
Ge0rGit could be just "-"
Kev"", "-", "unlimited", "max", all are better than "∞", I think.
dwdI could go along with "". That probably works on servers now. I doubt they all mandate an integer value here.
Ge0rGKev: "∞" is better than ""
jonas’this discussion reminds me of:
> APL apparently used +.× [as infix matrix multiplication operator], which by combining a multi-character token, confusing attribute-access-like . syntax, and a unicode character, ranks somewhere below U+2603 SNOWMAN on our candidate list.
jonas’dwd, servers may easily default to 1 for ""
jonas’I wouldn’t trust that
Ge0rGalso there is ambiguity between "" and unset
jonas’especially PEP implementaitons.
dwdPerhaps. Either way, the proposal is an infinity symbol, so the point it moot.
Kev"max" sounds good to me, but anything typable beats untypable, I think.
Zashdwd: Wrong. Prosody has some limited support for the dataforms datatypes XEP.
dwd4) Outstanding Votes
Ge0rGWe have two votes expire today
dwdI'll get to those votes after this meeting.
dwdI know I have outstanding.
Link MauveThe value must be something current servers won’t understand imo, otherwise we’re exposing ourselves to implementation details.
dwdI'm sure others do as well.
dwd5) Next Meeting
pep.Kev, "max" sounds good indeed
danielcould council provide me with some clear direction on how to fix the PR instead of just saying no?
dwdSame time next week?
jonas’dwd, +1wwfm
Ge0rG+1W WFM
jonas’daniel, I think we did. Don’t use "∞", use some text value instead. In addition, make it clear what is the magic value.
Ge0rGdaniel: replace ∞ with "max"?
Ge0rGdaniel: also it would be nice to have an explanation of the semantics of that value when sent by the client vs. by the server
dwddaniel, You'll almost certainly need a feature if you're doing something existing servers don't understand.
dwd6) AOB
a) Georg wishes to thrash out CS-2020, please review https://github.com/xsf/xeps/pull/841
Ge0rGI've modified the XEP with a new intro text, added some more XEPs
Ge0rGmore XEPs to be added are asked for
jonas’oh, I forgot about that PR; luckily, judging from the summary, my feedback is still valid
Ge0rGAlso the "future work" section
daniel> daniel: also it would be nice to have an explanation of the semantics of that value when sent by the client vs. by the server
where. in the label?
dwddaniel, Not now, please.
Link MauveGe0rG, I’ll be on-list for that.
dwdGe0rG, I think everything you've got in #841 looks good.
Link MauveI wasn’t aware of this PR until now.
Ge0rGjonas’ was so kind to propose some more XEPs for CS-2020
Ge0rG...on list
Link MauveBut it looks nice.
Ge0rGplease also comment on jonas’ suggested XEPs
dwdjonas’, Ge0rG - do you have an archive link to the email?
Ge0rGoh, yeah: important detail: I want this XEP to get through Council before the Council re-election, so feedback closes on November 5th
dwdThanks. That was of course for the record and not because I'd completely forgotten it.
jonas’dwd, the email I sent 4 minutes before this meeting started? ;)
jonas’good thing you didn’t forget about it, that would indicate very bad memory ;)
dwdOh, OK. So I'd just not seen it yet. :-)
Ge0rGApparently everybody is on-list to this AOB?
dwdGe0rG, Do you want a formal vote?
Ge0rGdwd: on the PR? No.
jonas’Ge0rG, I think #841 looks good, but I didn’t review the yes/no changes if any because they’re hard to read in the diff.
Ge0rGI'm the owner of the XEP, so I can do whatever I want.
dwdGe0rG, Indeed you can.
Ge0rGjonas’: it was just a `s/#10005/no/g` kind of change
jonas’okay
jonas’Ge0rG, then only the feedback I already sent to the list standrs
jonas’Ge0rG, then only the feedback I already sent to the list stands
Ge0rGjonas’: it was very good, thank you
jonas’you’re welcome :)
Ge0rGI feel slightly inclined to abuse my power to add XEP-0379 to Advanced Mobile.
dwdGe0rG, I think it all looks good. I'm inclined to agree with Evgeny, too - ditching BOSH sounds like a plan.
Ge0rGdwd: see my response on-list
KevI would be more inclined to keep BOSH with a note that where possible WSS is better.
Kev(But am not vetoing anything that happens based on either outcome)
jonas’Ge0rG, something about tokens ;)
jonas’(would be an excellent response to evgeny)
Ge0rGjonas’: something about rejected and/or abandoned protoXEPs
jonas’Ge0rG, something about SASL-HT something
dwdGe0rG, Something about client-key.
jonas’Ge0rG, something about Instant Stream Resumption (which is Experimental)
jonas’dwd, that’s what I meant
Ge0rGjonas’: are you sure it's not Deferred?
jonas’Deferred \subset Experimental in my book
Link MauveDeprecating BOSH might be a plan, but it sounds like it’s still worth it to have it supported by servers.
dwdCould we deprecate BOSH in clients but not in servers?
Ge0rGLink Mauve: this is exactly what jonas’ suggested in the first mail
jonas’Ge0rG, not exactly
Ge0rGdwd: we could in CS-2020
jonas’Ge0rG, I said clients can pick one
jonas’which isn’t deprecating BOSH
dwdGe0rG, RIght, what I meant.
jonas’oh wait, I said something about phasing out
Ge0rGjonas’: but you also suggested to phase out BOSH ;)
jonas’but that was an "maybe even" because what do I know about web
dwdAs we're coming toward close, can I ask people to keep an eye on Georg's work on CS-2020, and suggest we revisit this every meeting until it ships?
jonas’+1
pep.jonas’, is it 114 you want to remove? I'm curious why. Do you want to push for 225? :p
dwdAnyone want to raise anything else before we close the meeting?
Link MauveDo we have any data about how usable/blocked WebSocket is in the wild, compared to BOSH?
Ge0rGdwd: yes.
Ge0rGI forgot a tiny little thing.
jonas’pep., no, and only removing for Core Server. You can host a Component on a standalone piece of software, no need to have support for this in every server.
Ge0rGWe need to LC CS-2020 two weeks in advance to the final vote.
Ge0rGThat would mean we have to LC it next week
Ge0rG...latest.
jonas’Ge0rG, SGTM
jonas’I’d like to call everyone on council ( Kev, dwd, Link Mauve, Ge0rG and me) to try to make this work for once.
jonas’I.e. vote on list quickly to let it enter LC
Ge0rGWhich is why I'd like to vote for LC now, and use the LC phase to sort out "Future Development"
Link MauveSame, I will propose changes before next week if I have any.
jonas’I don’t think we can technically still vote.
Ge0rGcan't we vote in AOB?
dwdGe0rG, Ah, rather renders my suggestion a waste of time.
jonas’I’m +1 on LC after #841 has been included. My feedback shall be counted as LC feedback then.
Ge0rGdwd: your suggestion of revisiting it each meeting? It's sound.
dwdGe0rG, No, I suggest we Last Call it next week, and this week we ensure we've helped get it to the right shape.
Ge0rGIt's still in urgent and dire need of content for "Future Development", though
Ge0rGdwd: well, let's go on with that, then.
dwdBut please, let's make sure we're in a position to vote on this within the meeting - otherwise we will run out of time.
Ge0rGYes.
dwdSound good to everyone?
Link MauveYes.
jonas’yes
Ge0rGI have a gut feeling that we will run out of time, so I'll pester everybody delaying the vote with messages.
dwdOK. With that, I think we're done.
Ge0rGIf we vote LC now, we still have roughly enough time in the worst case.
Ge0rGBecause surely somebody will on-list the LC vote until October 23rd.
dwd7) Ite, Meeting Est
jonas’Thanks everyone.
Ge0rGThanks Dave, thanks everybody else.
Link MauveThanks. :)
dwdGe0rG, I hope not.
KevOn-list.
Ge0rGdwd: ^
KevDid I do that right?
jonas’squints at Kev
Ge0rGDon't make me sad, Council comrades.
jonas’☭
Ge0rGjonas’: do you want me to pile up more changes into #841?
jonas’Ge0rG, asking me as editor?
Ge0rGjonas’: yes
jonas’Ge0rG, I have no strong opinion one way or the other.
Ge0rGjonas’: I'd like to have a single revision block for everything between CS-2019 and Final CS-2020.
jonas’Ge0rG, if you do, remind me at least 24h before the next meeting about merging it
jonas’Ge0rG, that’s not going to be possible
jonas’we need to make a release prior to LC
jonas’and there will be feedback during LC which needs a separate revision block
dwdGe0rG, I'd rather we merged and published on a release early/often kind of style.
Ge0rGDoes that ask for a "Changes since 2019" sub-section?
dwdGe0rG, Might nudge people to make more comments that way.
Ge0rGdwd: I'm not talking about not releasing, I'm talking about having a history block that's useful in 2020, and not just in November 2019.
dwdGe0rG, I don't hugely care about changes. People can figure those out by comparing the docs, they're not radically different in layout etc.
jonas’dwd, I don’t agree
jonas’strongly disagree even
Ge0rGdwd: using out awesome xep-diff infrastructure?
Ge0rGdwd: using our awesome xep-diff infrastructure?
Ge0rGdwd: as a developer, I want to have all the changes at a glance, so that I can evaluate what needs to be dump to bump my CS level..
pep.figuring out xep changes is a pita indeed
danieli still would like some clear consultation on how to resolve #840; since this is something that council will have to decide i'm not sure that brute force trying different version only to be told -1 every week is a productive method
jonas’daniel, I gave you clear advice which I think will be accepted by all members if I read this meeting correctly.
danielunless council doesn’t feel that this is important in that case i'll just stop
jonas’daniel, do you even read what I’m writing?
pep.jonas’, there was another question
pep.daniel> > daniel: also it would be nice to have an explanation of the semantics of that value when sent by the client vs. by the server
where. in the label?
jonas’to that my answer is: find a suitable location in the prose of the document and insert it there.
jonas’maybe around publish-options or the disco#info example
Ge0rGdaniel: I don't much care about the where. It should be readable, so "in the label" is probably not the smartest place to put it
jonas’probably publish-options
jonas’or that
jonas’I don’t care too much either way
Ge0rGwhat jonas’ said
danielthe thing is that none of the other node configs are explained anywhere
jonas’yeah
danielfeels weird to randomly start explaining max
jonas’which isn’t great
Ge0rGdaniel: PRs welcome.
KevPersonally, I will un--1 it as soon as it's "max" instead of <glyph>, and would accept probably a large number of other typeable strings too
KevDescriptions desirable but not required in this case, for me.
debaclehas left
Ge0rGI would +0 or +1 it without a description, but not without a feature flag
jonas’Ge0rG, that’s new.
dwddaniel, ASCII character set value, and probably a feature.
danielmax and feature flag have been added fwiw
Ge0rGjonas’: what's new?
jonas’Ge0rG, your requirement
KevGe0rG did mention it earlier.
jonas’I missed it
KevAnyway, +1 on the current version (having just seen Daniel's changes).
jonas’+1, too
danielalso dwd Bookmarks2 should probably explain what to do when node-config-max is not available as a feature
danielmaybe introduce a magic number :-/
pep.Or just require node-config-max?
Ge0rGdaniel: the backticks might be less understandable than "" </bikeshed>
danielwe currently decideded on 128 which ~4 implementations use
KevI thought that and thought it wasn't worth mentioning :)
Kev(backticks)
Ge0rGbut +0 now
Ge0rGbut 128 is too small for power users!
jonas’I’m going to detach myself from this bikeshedding now.
danielwhat is the current number of channels listed on search.jabber.network
daniellet that be our magic number
dwd+1 on #840 now. And FWIW, I'm totally fine with backticks - Markdown, innit?
jonas’daniel, 7453
Ge0rGdwd: consistency over markdown.
pep.Ge0rG, I agree. I'd go with a full u8 at least :p
Ge0rGpep.: 256 would force implementations to use at least an int16
pep.I'm missing why
Ge0rGbecause 256 doesn't fit into an uint8
pep.I didn't say 256 :-°
dwdAs for Bookmarks2, I'm not sure this isn't orthogonal. You need the maximum to be set to at least as many bookmarks as you want to store.
Ge0rGpep.: I did
pep.(*trying to escape*)
dwdGe0rG, What about with compression?
Ge0rGsummons waqas
Ge0rGdwd: my gut feeling is that compression will be harder to abuse on mobile, while providing significant benefits
Ge0rGI have only disabled compression in my client because the compressor wasn't thread-safe
KevI think Dave was suggesting that 256 will fit in a uint8 with compression.
Ge0rGKev: maybe.
dwdRLE the bits, I reckon. What could go wrong?
Ge0rGit's only one bit.
Ge0rGjonas’: I'd like to group 0245 and 0392 into one category. Is "Message display" too broad / too narrow?
danieldwd, the 'problem' is that to use Bookmarks2 correctly you really want to put max_items in publish_options; and then you need to put some number in there.
jonas’Ge0rG, I disagree on that grouping
jonas’Ge0rG, because '392 also makes sense in the roster
danieland when mulitple implementations disagree on that number you end up having to reconfigure on every publish
dwddaniel, Not if the number is high enough, surely?
danielyes. but then you need to agree on one
ZashProsody defaults to 256 fwiw
Ge0rGjonas’: right. That was also a request for a better name.
dwddaniel, Not really. I mean, I see it's simpler if you can just say "max", but I don't see it matters much if the number is smaller.
jonas’dwd, publishing with publish-options would reject your publish if your max_items request is different from the one already set on the node.
dwdjonas’, Yes.
jonas’Ge0rG, "User handle coloring" maybe?
dwdjonas’, But we know if the node exists at the start, so we're not publishing blindly.
Link Mauve“17:48:52 daniel> we currently decideded on 128 which ~4 implementations use”, I’m awfully close to this limit already myself. :/
jonas’dwd, but then you need extra round trips
dwdjonas’, You do, yes. My point is that if the server supports max, that's great. If it doesn't, the client has to do more work, but it'll still function.
dwdjonas’, So I'd see this as a SHOULD at best.
Ge0rGThis discussion clearly shows that we are piling workarounds on top of workarounds. Can we step back a step or two and fix the design?
Ge0rGand by "we" I mean somebody else than me ;)
dwdGe0rG, If you want to ship a free forklift with every client.
danielso to summarize if a server doesn’t support max i need to download the node config; see if the value currently set is "high enough" and if so omit my own value from publish_options?
danielthat should probably be documented in the XEP so people who are not in the chat right now know that
dwddaniel, Sure. And yes, we should encourage/recommend/etc that `max` is supported and used.
KevOr just don't do BM2 unless max.
KevActually, in the absence of max, what really is the harm in reconfiguring on every push?
KevAt the point you push you already know what 'big enough' is, and can just set it to enough plus a few, or something.
dwdCould even pipline the configure, right?
KevThat's what I was thinking, yes.
jonas’also very relevant: https://mail.jabber.org/pipermail/standards/2019-October/036506.html
danielbut pubsub is just a cache
pep.> jonas’> Ge0rG, because '392 also makes sense in the roster
And in other places.. OMEMO fingerprint has been mentioned in the past, I'm sure there's lots of other places it could be useful
XMPP Council - 2019-10-09