-
jonas’
1) Roll Call
- Zash here
- jonas’
-
daniel
Hi
- Ge0rG
-
jonas’
no dwd?
-
jonas’
2) Agenda Bashing
-
jonas’
crickets!
-
jonas’
3) Editor’s Update
-
jonas’
nothing unusual
-
jonas’
4) Items for Voting
-
jonas’
No new items
-
jonas’
5) Pending Votes
-
jonas’
we need to handle the LCs now
-
Zash
Carbons and MAM eh
-
jonas’
yep
-
Kev
I think MAM needs at least one round of changes, given my review yesterday, but they’re not major.
-
Kev
(Jumping ahead because I might not notice when (5) comes up)
-
Ge0rG
I think MAM needs at least one round of changes, given my review three weeks ago, but they're rather significant.
-
jonas’
Kev, we are already at (5) :)
-
dwd
Ah. Sorry, I've been dragged into a meeting.
-
Zash
I've looked at past LCs and there's been a lot of back and forth on things
-
Ge0rG
The agenda items 2 to 5 all arrived in the same second at my end. Some lag might be involved.
-
Zash
<private> vs xep-0334 and whatnot
-
Ge0rG
Should we have some separate discussion of the open points of 0280 and of 0313 before casting final votes?
-
jonas’
so IMO we should factor out the rules in a standards track document which defines disco#info features. The rules should be called "general routing rules" and versioning should go across all of them, but they may be different for the different "routing" protocols (MAM, Carbons, CSI, Push…)
-
Zash
Sounds good.
-
jonas’
we can think about the issue that such a living document can never advance beyond Draft later.
-
Ge0rG
jonas’: so one namespace for all the routing rules, instead of one namespace per task?
-
jonas’
ideally that issue resolves itself with IM-NG
-
jonas’
Ge0rG, yes
-
jonas’
but I’m not hard-sold on that
-
Zash
The base wire protocols are probably good enough and certainly well-deployed by now,..
-
jonas’
Zash, exactly
-
Ge0rG
What do we do with urn:xmpp:carbons:rules:0?
-
jonas’
Ge0rG, make it implicit in urn:xmpp:routing-rules:0
-
jonas’
and advertise it for up to routing-rules:N, where N is the revision where the rules for carbons are first changed
-
Kev
FWIW, nothing needs factoring out of either 313 or 280 in order for later rules to be defined elsewhere.
-
Ge0rG
well, the feature version was just a quirk to get around bumping carbons, so I'm not fighting to death over it
-
Kev
(At least, the intention when writing the text in 313 was that a later external feature could be advertised for a concrete set of rules, same as 280)
-
jonas’
but again, not hard sold on unifying them; it seemed sensible to me on a quick thought to have that all under a single version umbrella, but especially when we have to adapt (e.g. only) push rules and then have to forklift all features, it seems a bit overkill
-
jonas’
yep, separated features are probably waaay better
-
Zash
And then compliance suites that point to recommended versions?
-
Ge0rG
I'm torn on whether to use my 0313 vote to extort somebody to write down those rules for 0313
-
jonas’
Zash, yes
-
jonas’
Ge0rG, I get the impression that '313 may be blocked anyway
-
Kev
I don’t think 313 is blocked otherwise in a meaningful sense. I.e. I don’t think any changes need another LC.
-
Ge0rG
Indeed, even if I were to retract my storage rules requirement, there are still the open questions around MUC in personal MAM and client business rules
-
Ge0rG
and of course the bind2 / MAM subscription topic that probably needs to be postponed anyway.
-
Zash
Myeah, recommending against storing MUC messages without additional negotiation would probably be good.
-
Zash
"additional negotiation" something something MIX I guess
-
Ge0rG
against *delivering*
-
Ge0rG
backfilling of MIX history on the personal MAM is still an unsolved problem.
-
Ge0rG
Given that, I'm solidly -1 on 0313.
-
jonas’
noted
-
jonas’
how about '280?
-
Zash
The <private> thing seems unresolved.
-
Ge0rG
Kev addressed the "stripping <private> parts" point and I'd like to get a discussion of Hints
-
Ge0rG
My desired way forward would be to remove the stripping requirement, to completely remove Hints, and to Convince Council to go on without a namespace bump.
-
daniel
you'd need to convince the authors. not council
-
Ge0rG
I'd also rewrite the Mobile Considerations to say the opposite of what it does now, but that's the non-normative part.
-
Ge0rG
daniel: given that I'm one of the authors, you can consider it done.
-
jonas’
my problem with not bumping the namespace there would be, on a theoretical level, that a client relying on <private/> not being stripped may be owned in one way or another by an old server
-
Ge0rG
Still, I've heard some objections from Council members about this suggestion last week
-
Zash
Does anything really bad happen in that case?
-
Ge0rG
jonas’: you mean by a client relying on <private/> *being* stripped?
-
jonas’
Ge0rG, no
-
Ge0rG
jonas’: ah, now I get you
-
jonas’
if we don’t bump and a new implementation comes along, relying for $importantFeature on <private/> being there, it will be confused when <private/> is *not* there because the server is on old carbons
-
Ge0rG
So I'd also add an implementation note.
-
jonas’
and then what?
-
Ge0rG
jonas’: also there used to be different semantics for stripping <private/> before 2013, https://xmpp.org/extensions/xep-0280.html#revision-history-v0.9
-
Kev
urn:xmpp:carbons:doesn't-fuck-with-private:0
-
Kev
Is that a pragmatic compromise?
-
Zash
Would work I guess?
-
jonas’
Kev, would’ve been my next suggestion :)
-
dwd
Not a valid URN?
-
Zash
doesn"t‽
-
jonas’
Ge0rG, wait what
-
Kev
It’s in pre-encoded form.
-
jonas’
it was changed again?✎ -
jonas’
it was changed already back and forth? ✏
-
Ge0rG
jonas’: as I read the log, it was stripped by the *sending* server before
-
Zash
<server author hat> I think it does that still?
-
jonas’
huh.
-
Zash
or what
-
jonas’
okay
-
jonas’
that makes me think that we should not at all rely on <private/> being there or not being there
-
jonas’
too many versions
-
jonas’
and adding another change is not going to make it any better
-
Ge0rG
So can I move forward with my grand plan?
-
jonas’
Ge0rG, no, I think that you should leave <private/> alone
-
Ge0rG
jonas’: is that an opinion or a foreshadowed Council vote?
-
jonas’
that is an opinion
-
jonas’
because I don’t see what good it brings
-
Ge0rG`
Sorry, my prosody is stalled
-
jonas’
I hope this wasn’t me
-
Ge0rG`
Only if you suddenly took over VaxBot
-
Ge0rG
jonas’: I think that Kev has a great point about letting the receiving client know that it received a Carbon that won't get delivered to any other resource.
-
Kev
I think it’s a not-insignificant security consideration to strip private.
-
Ge0rG`
> jonas’: I think that Kev has a great point about letting the receiving client know that it received a Carbon that won't get delivered to any other resource.
-
Kev
Letting another user modify my server’s routing rules without telling me does not seem at all safe.
-
jonas’
Kev, I agree, but just removing that rule doesn’t mean that anyone can rely on it
-
Kev
Thus feature.
-
jonas’
Ge0rG`, so you could do it with a feature flag IMO
-
Kev
But this isn’t a case of clients relying on it.
-
Kev
It’s a case of a user of a server relying on the server not doing questionable things without trace.
-
Ge0rG`
But we are also still in Experimental, so it's all not so bad from a protocol point of view. Right?
-
Ge0rG`
(from a Council protocol...)
-
jonas’
Ge0rG`, yes
-
Kev
I would be ok (not that my opinion matters) with removing that (or rather, flipping that to a must not) rule without adding the feature. But adding the feature is cheap, and not without value, so why not.
-
jonas’
what Kev says tho
-
Ge0rG
Alright, I can live with what Kev says.
-
jonas’
then do that please
-
Ge0rG
Now what about stripping Hints from the XEP?
-
jonas’
do we know how widely implementations rely on that?
-
Zash
Do we not like Hints anymore?
-
Ge0rG
Ironically, current-0280 requires to strip <private/> but doesn't mention strpping the Hint.
-
Kev
I would probably form an opinion on that given time to think, but don’t currently have one on the hop.
-
jonas’
Ge0rG, what is the harm of keeping it?
-
Ge0rG
jonas’: we are enshrining a protocol that we don't want to keep.
-
Zash
We don't?
-
Ge0rG
jonas’: there was a version of 0280 that only required adding <private/> and later a version that required adding both <private/> and the Hint.
-
Ge0rG
Thus, removing the Hint requirement won't break any compliant implementations.
-
Ge0rG
I dislike the inconsistency of https://xmpp.org/extensions/xep-0280.html#avoiding
-
jonas’
section 9 reads very confusing
-
jonas’
> The sending client MAY exclude a <message/> from being forwarded to other Carbons-enabled resources, by adding a <private/> element qualified by the namespace "urn:xmpp:carbons:2" and a <no-copy/> hint as described in Message Processing Hints (XEP-0334) [8] as child elements of the <message/> stanza.
-
jonas’
the sending client is not excluding anything, protocol wise
-
jonas’
and then the enumeration just goes on as if it was on the same side of the contract ... very weird
-
jonas’
Ge0rG, put that on your list of things to fix please
-
Ge0rG
jonas’: I'd improve the wording while removing Hints.
-
jonas’
if
-
jonas’
if *both* are currently required, we can remove hints without damage indeed
-
Ge0rG
jonas’: that's what the XEP says, right?
-
jonas’
yep
-
jonas’
I think
-
jonas’
I mean I think the XEP makes no statement at all about that in the text as written because of that wording weirdness, but the intent is clear
-
Ge0rG
Yes, that's also my reading of it
-
daniel
The concept of private messages is out dated anyway. I think a variant version of carbons todo wouldn't even have it
-
Ge0rG
daniel: what about OTR?
-
daniel
Yes
-
jonas’
"out dated"
-
daniel
My point exactly
-
Kev
Private goes away in IMNG, I think, but I’m not sure until then.
-
daniel
Otr was the only thing that used it
-
Ge0rG
Kev: but it goes away because we introduce a different mechanism to route a message just to a single specific resource, right?
-
daniel
And even otrv3 technically didn't event need it
-
Kev
Ge0rG: Right.
-
Ge0rG
So just the XML element goes away, not the semantics.
-
Kev
The new syntax for sending just to one resource becomes to=‘fulljid’ :D
-
Ge0rG
Unless we decide that we do not have any more need to route messages just to a single resource.
-
jonas’
okay
-
jonas’
we’re a bit over time at this point
-
jonas’
Ge0rG, do you need any further input?
-
Ge0rG
But I'm pretty sure we will have some use for that in IOT or PubSub events
-
Ge0rG
jonas’: no.
-
jonas’
excellent
-
jonas’
6) Date of Next
-
jonas’
+1w wfm
-
Ge0rG
Is the CVE PR applied already? :D
-
jonas’
(waking up Zash and dwd )
-
daniel
+1w wfm
-
Zash
+1w wfm
-
Ge0rG
+1W WFM, but the following two weeks I'm going to be on vacation (from the computer screen)
-
jonas’
Ge0rG, good for you!
-
jonas’
7) AOB
-
jonas’
skipped because time
-
jonas’
8) Ite Meeting Est
-
Ge0rG
But but but AOB!
-
Zash
no aob for you
-
jonas’
Ge0rG, no, not yet, please bring it to the list because there was controversy around that in xsf@ and I’d like to have some rough consensus
-
Ge0rG
Also nobody cast their votes on 0280
-
jonas’
Thanks everyone
-
Ge0rG
so this makes another failed LC, right?
-
jonas’
Ge0rG, right, forgot, I wanted to ask
-
jonas’
9) Ite Meeting Un-Est
-
jonas’
votes on '280?
-
jonas’
I imagine you’ll want to veto
-
daniel
+0
-
Ge0rG
+1 with all the discussed changes applied.
-
Zash
-1 until the <private> thing has consensus and is resolved
-
jonas’
following Zash here
-
jonas’
(changing my +1)
-
Ge0rG
Zash: how do you imagine consensus happening here?
-
daniel
I don't think it matters what label we put on a very flawed but de facto draft xep
-
jonas’
10) Ite Meeting Est for real
-
jonas’
Thanks everyone
-
jonas’
(gotta run, need to prepare for being reaallly quick in 15 minutes)
-
Zash
Ge0rG: apply the changes discussed. I've ran out of coffee, can't think anymore.
-
Ge0rG
Alright. I'll PR and then ask for another LC.
-
Zash
and ... '313 is ..?
-
jonas’
vetoed
-
Ge0rG
Zash: vetoed by me
-
Zash
check
-
Ge0rG
I've been naughty.
-
Zash
Very well then