- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- debacle has left
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- Zash has joined
- daniel has joined
- daniel has left
- lnj has joined
- daniel has joined
- moparisthebest has left
- moparisthebest has joined
- lnj has left
- lnj has joined
- daniel has left
- daniel has joined
- debacle has joined
-
Link Mauve
Just a reminder that I’ll be in another meeting this afternoon, and thus not here.
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- vanitasvitae has left
- vanitasvitae has joined
- Ge0rG has joined
-
dwd
Are we sitting comfortably?
-
jonas’
I am
-
Kev
Then let's begin. Only not quite yet because it's not 4 yet.
-
Ge0rG
Good morning, ladies.
-
dwd
OK.
-
dwd
1) Roll Call
-
Kev
Here.
-
jonas’
here
- Ge0rG
-
dwd
Missing Link Mauve as expected - he sent apologies last week.
-
dwd
2) Agenda Bashing
-
dwd
We've four items this week, all PRs.
-
Kev
I've been busy all day and not in a position to bash, sadly.
-
dwd
#736, #778, #784, and #785
-
dwd
Any others?
-
dwd
Assuming not.
-
dwd
3) Items for a vote (or discussion):
-
dwd
a) https://github.com/xsf/xeps/pull/736 XEP-0308: Allow message correction in MUC
-
Kev
I'm concerned about this one.
-
dwd
I commented on the PR, my feeling is that this is asking for the right things, but not in the right way - language is a bit wooly.
-
Kev
Mostly about the idea of servers needing to store data on every past occupant.
-
jonas’
yeah, I don’t think that’s sane
-
Kev
As the current text doesn't seem to have any sort of time limit on corrections.
-
jonas’
clients cannot rely on the feature unless we impose O(+infty) amount of work on servers
-
Ge0rG
isn't it sufficient to store the real bare JID on all messages in the history log?
-
jonas’
the history log may be +infty long
-
jonas’
and you need to do a search for the corrected message
-
jonas’
for each correction
-
jonas’
that sounds like a very easy DoS vector to me
- peter has joined
-
dwd
The way it's currently written, it merely says that where the correcting entity is definitely not the same, the correction should (I think) be rejected. It doesn't say that if the entity is the same it should/must be accepted.
-
jonas’
-> no server right in their minds is going to implement this.
-
Ge0rG
right. unless you have... an index!
-
jonas’
even then it’s complex✎ -
Kev
Ge0rG: No, because you need to know what message the client might be correcting, which requires you to know the most recent message from that client, no matter how long ago it was.
-
jonas’
even then it’s computationally complex ✏
-
Kev
" If it does so, the receiver can trust any message correction received through this room, be it live or from history."
-
dwd
That is, a server saying Nope every time is, I think, conformant as written.
-
Kev
I think it's clear that the intent is that advertising the feature means that every correction has been checked for validity.
-
Ge0rG
Kev: I agree
-
dwd
Kev, Yes, but not that every correction has been accepted that could have been.
-
Kev
Yes, that is true. But also quite unhelpful.
-
Ge0rG
I think it's a useful feature to have, and I don't know how Link Mauve implemented it.
-
dwd
In any case, the "SHOULD" and "should" and things scare me at the moment.
-
jonas’
I think it’s a useful feature to have, but I also think it’s a trivial DoS vector for servers if clients are to be rely on this
-
dwd
So I'm -1 for now, but I think this can be fixed.
-
Ge0rG
jonas’: because you can flood the server with bare JIDs?
-
jonas’
if clients cannot rely on it (because the server is allowed to age out information), it is not useful
-
Kev
I'd have rathered discussed with Link Mauve here. I think I have to tentatively -1 this until we can discuss what's needed.
-
jonas’
Ge0rG, for example, or simply with messages
-
Ge0rG
dwd: you are -1 because what can be fixed?
-
Kev
jonas’: If a server that has aged out information is allowed to block the corrections it can't verify, clients can trust what they receive. They just can't send as much as they'd like.
-
Kev
Dave is right there, I think.
-
dwd
Ge0rG, Language. I don't think it's actually describing what's normative very well.
-
jonas’
Kev, that needs to be spelt out clearly though
-
Kev
I think so, yes.
-
jonas’
-1 until the DoS vector and how it is to be mitigated and what clients can expect there is clarified
-
dwd
Kev, Ge0rG ?
-
Ge0rG
on-list to see what comes out of your questions.
-
Kev
Already -1d.
-
dwd
Thanks.
-
Ge0rG
I feel like +1, but the raised points are valid as well.
-
dwd
aa) XEP-0308: relax from-full-JID requirement https://github.com/xsf/xeps/pull/784
-
dwd
I feel like this is intimately tied in with #736, myself.
-
jonas’
I’m +1 on that one
-
jonas’
dwd, it’s not necessarily
-
Kev
dwd: Why's that?
-
Ge0rG
dwd: #736 is implying it, but it's not tied in any way.
-
dwd
Or perhaps I misread - is this purely client-side?
-
jonas’
it can be done purely client side
-
jonas’
(and the text suggests that)
-
Ge0rG
dwd: the text is deliberately open about client- or server-side
-
Kev
Oh, you're right, that 'or the MUC service' does imply it. Because a client cannot do the verification itself.
-
Ge0rG
"either the recipient or the MUC service need to ensure that the real bare JID of the sending occupant didn't change in between"
-
Kev
(Unless it's non-anonymous)
-
jonas’
Kev, it can
-
dwd
Ah, yes. OK, in that case it's fine. +1
-
jonas’
if there was a part/join in-between, it might not be the same JID -> discard✎ -
Kev
So that means that where the recipient can't do it, to satisfy that requirement the MUC service must have done it.
-
jonas’
if there was a part/join in-between, it might not be the same s ender -> discard✎ ✏ -
jonas’
if there was a part/join in-between, it might not be the same sender -> reject ✏
-
Kev
Which puts requirements on a MUC service where there were none before.
-
Ge0rG
Kev: the recipient can do it if neither you nor the sending occupant didn't leave the MUC between the original and the correction.✎ -
jonas’
it’s not a requirement -- clients already implement that check, actually.
-
Ge0rG
Kev: the recipient can do it if neither you nor the sending occupant did leave the MUC between the original and the correction. ✏
-
Ge0rG
some clients.
-
jonas’
yeah, other default the check to "not allowed" ;)✎ -
jonas’
yeah, others default the check to "not allowed" ;) ✏
-
Kev
This feels like it'd be more cleanly written in terms of who's expected to do what when based on top of 736.
-
Ge0rG
other clients ignore it altogether because identity of occupants in a semi-anon muc is pointless.
-
jonas’
maybe, but I still think this can stand on its own, so +1
-
dwd
Kev, See, when I said that everyone disagreed. :-)
-
Ge0rG
+1 obviously.
-
Kev
dwd: I didn't. I asked why.
-
Ge0rG
Kev: I could provide a better wording of #784 once #736 is approved. Which it isn't.
-
Ge0rG
as it is now, I think that the wording is sufficient for either outcome of #736.
-
Kev
Ge0rG: That would be my preference. I'm fine with the intent as I understand it, but not with that text about MUC services doing stuff, without some form of explanation - either through 736, or locally.
-
Ge0rG
Kev: we are speaking of a footnote.
-
Kev
Just changing "either the recipient or the MUC service" to "the recipient will" will make it ok by me, I think, until we've got 736.
-
Kev
As without 736 the MUC service doing things doesn't help at all anyway.
-
Ge0rG
Kev: if that is your prerequisite for accepting, I can re-word.
-
dwd
Kev, Or at least, without '736, the recipient has no idea if the MUC service is doing anything.
-
Kev
Ok, +1 after tweaking.
-
Kev
dwd: Indeed.
-
dwd
OK, then.
-
Ge0rG
Thanks!
-
dwd
c) https://github.com/xsf/xeps/pull/785 - XEP-0260: Replace broken link with archive.org
-
Kev
Not a Council voting item, I think, just Editorial.
-
Ge0rG
as a matter of form, I'd not replace the anchor text, just the link.
-
jonas’
I think that’s sensible
-
Kev
That makes more sense.
-
Ge0rG
But I agree with Kev that this is Editorial, so +1.
-
jonas’
will take care of that
-
Kev
I think I'd be inclined for Council to instead decide it's Editorial, rather than voting as if it wasn't.
-
Kev
It affects versioning, for example.
-
Kev
So if we change the vote to be 'is this Editorial?' then I'm +1. Or if we have to treat it as a substantive change, begrudgingly +1.
-
dwd
No, I'm fine with this being Editorial.
-
jonas’
yeah, editorial
-
jonas’
I wouldn’t even have raised this to council
-
dwd
I'm a little concerned with how close to normative behaviour this is, though, being described in an external link that's gone dead.
- peter has left
-
dwd
Is there a better specification for SOCKS5 we could/should be using here?
-
Kev
dwd: Oh, I didn't read it that way. Maybe I've misunderstood.
-
Ge0rG
So let's re-vote on this kind of things being Editorial Changes?
-
Kev
I thought it was saying "And for people who remember this old proposal, this is much the same".
-
jonas’
yeah, it should probably be moved to the XEP, if we can get this sorted out legally
-
Kev
(When I say "Maybe I've misunderstood", I'm actually fairly confident that I haven't)
-
dwd
Kev, Yes, you probably haven't misunderstood. I'm just a little sensitive to external links in the XEPs.
-
Kev
Agreed that this is Editorial, suggest to the Editors to not change the link text, just the link, and move on?
-
dwd
ANyway, the change itself is certainly Editorial. I just wanted to make sure we're happy with the linking at all.
-
Ge0rG
That requires obtaining permission from Justin to incorporate the text as an informational part? as a dedicated informational XEP?
-
Ge0rG
dwd: +1 to that motion.
-
dwd
Ge0rG, You're happy?
-
dwd
Anyway, probably no conclusions to be made here.
-
dwd
4) Outstanding Votes
-
dwd
Please check 'em.
-
Ge0rG
dwd: what about d)
-
dwd
Ge0rG, Oh, I skipped one, didn't I?
-
Ge0rG
no, wait. it was b) which should have preceded your c) but probably was missed due to aa).
-
Ge0rG
b) Discussion: https://github.com/xsf/xeps/pull/778 XEP-0280: Rewrite of the 'Messages Eligible for Carbons Delivery' section
-
dwd
ndeed, that ^^
-
Ge0rG
Somebody noted that it might be a better way to create a new XEP that defines these rules, hide it behind a new feature and only reference it from 0280 so that 0280 does not break.
-
dwd
So I did talk to Ge0rG about this last week, and wondered aloud if it would be better to have these "fixed" rules as a distinct feature that clients would then see and be able to rely upon.
-
Ge0rG
Formally, 0280 is somewhere between Experimental and Abandoned.
-
dwd
Ge0rG, Yeah. XEP-0280 isn't in a happy place, in terms of process.
-
jonas’
dwd, we’re on the road to that, it’s called IM-NG
-
dwd
jonas’, That road is very long and shows no sign of getting shorter.
-
Ge0rG
dwd: it also had a bunch of Last Calls.
-
Kev
I don't think roads typically get shorter, you just move along them :)
-
dwd
Ge0rG, This, too, I'm aware of.
-
Ge0rG
Kev: that road is a kind of moebius strip, apparently.
-
Kev
I would be much happier with the idea of formal rules in a XEP with its own feature.
-
dwd
Kev, Yes, I don't think that's happening either.
-
Kev
Ge0rG: But at least it doesn't change in its infinite length.
-
dwd
Yes, I think these rules as a new XEP which can just be advertised by a server (no negotiation needed since it's within scope for '280) is an ideal solution.
-
Ge0rG
Personally, I'd very much prefer to get these rules into 0280, presumingly breaking it for some, but to have a clean and nice specification that we can LC some time this year.
-
jonas’
from what I can see, this PR mostly clarifies how carbons interact with MUCs
-
jonas’
the other rules seem untouched
-
Ge0rG
jonas’: the other rules move from MAY to BREX^W SHOULD
-
jonas’
ah, right
-
dwd
jonas’, I think there are other rules altered. I forget the details. But most importantly, it switches rules from a "Who knows, maybe" state to a "SHOULD" - and a distinct XEP could easily make them MUST.
-
jonas’
one could advertise this ruleset in a feature if it makes people happy
-
Ge0rG
I have accumulated a large amount of frustration with 0280 and how it is implemented, and I'm not sure I can produce a dedicated new XEP containing just those rules and a feature.
-
jonas’
dwd, it can also be made MUST in the same XEP with a feature
-
jonas’
and I’d prefer that
-
dwd
My personal feeling is that a new feature would improve adoption. I'm somewhat ambivalent as to whether we need a new XEP or not.
-
jonas’
I am a bit wary of the XEP proliferation we have
-
dwd
jonas’, We should write a XEP on that.
-
jonas’
right, so a new feature which advertises this exact ruleset?
-
Ge0rG
As it is now, 0280 is not only in a very sad place process-wise, it is also a very sad specification.
-
Ge0rG
or rather, a very saddening one.
-
dwd
With a new feature, I'd suggest that many of the SHOULDs in Georg's PR could be MUSTs.
-
Kev
I'm going to need to think about this at-length and on-list, in any case, because I'm a bit rubbish.
-
Ge0rG
Kev: please also read up the many discussions of that from the last five years.
-
jonas’
I’m +0 on this without feature, +1 with a feature + MUSTification.
-
Ge0rG
dwd: I can make that a feature-conditioned MUST in 0280.
-
jonas’
(obviously, the error tracking stuff should stay non-MUST)
-
Kev
Ge0rG: I'm confident you don't want me to do that.
-
Ge0rG
> (obviously, the error tracking stuff should stay non-MUST)
-
Ge0rG
I disagree with that, and that makes a good distinct discussion point.
-
Ge0rG
What to do with errors.
-
Ge0rG
Practically, it sucks to not receive errors for carbonated messages.
-
Kev
Ge0rG: Is the sticking point with a separate spec that you don't have the energy for it, or you think it's wrong?
-
dwd
FWIW, I think I'm the same as jonas’ here - +0 but +1 with a feature.
-
jonas’
Ge0rG, but error-tracking is expensive
-
Kev
That is, if I hypothetically decide I don't want it in 280, but offered to do the split, would that work (not saying that'd happen).
-
Ge0rG
Kev: a bit of both. I won't be able to produce a XEP that's not full of sarcasm and insults, and I think we need to fix the rules in 0280.
-
jonas’
I don’t think that a separate XEP is the right tool here
-
Ge0rG
jonas’: error-tracking is expensive. What about fanning out all message errors?
-
jonas’
that would probably work
-
Kev
FWIW, my main arguments for a separate XEP are that if we stripped the rules out of 280, and just left a pointer to the new XEP, we could Draft 280 immediately.
-
Ge0rG
There is also a distinct question of making carbons depend on client-features, i.e. no carbons of CSN if not supported by the client.
-
dwd
OK - I'm going to move on, but we can come back to this after the meeting.
-
Kev
But also that we couldn't sensibly Draft 280 with the rules in for some time.
-
Kev
And this would also let us decide that other rules were better in the future.
-
jonas’
I think other rulesets should be developed in the IM-NG realm of things
-
dwd
5) Next Meeting
-
dwd
Next week?
-
jonas’
wfm
-
Ge0rG
Kev: what is the point of Drafting 0280 without the rules?
-
Ge0rG
+1W WFM
-
Kev
Ge0rG: We don't have rules at the moment, yet Carbons works reasonably well for lots of people. So having that Draft seems not completely without merit.
-
dwd
I'm in the office next week, so might be disrupted - I'll try to make it though.
-
dwd
6) AOB
-
Ge0rG
Oh, there is _yet another_ dimension on Carbons: Transports
-
dwd
Anything other than '280?
-
Ge0rG
No AOB
-
dwd
7) Ite, Meeting Est.
-
dwd
Ge0rG, I'm of the general opinion that transports are often rubbish, but how so in this particular case?
-
Ge0rG
dwd: we should allow a Transport to send sent-carbons when the user sent a message from a native-protocol client.
-
dwd
Ge0rG, Ah. Funnily enough, I do exactly this. Or did.
-
Ge0rG
There was a weirdly worded list inquiry by Владимир.
-
Ge0rG
https://mail.jabber.org/pipermail/standards/2018-January/034224.html
-
dwd
Oh, yeah, I had all those problems.
-
Ge0rG
However, this obviously can be solved by its own XEP that allows something like 0321 to override the carbons-must-be-from-own-JID rule.
-
moparisthebest
my uh, client side transport thing, relies 100% on carbons to work
-
dwd
Ge0rG, Yes. Also, MAM needs to archive those messages.
-
Ge0rG
dwd: yes.
-
Ge0rG
Did I mention yet that we should re-invent MAM and Carbons as a unified session protocol with all the insights from the last 5 years?
-
Ge0rG
But really, _this_ problem of Carbons can be solved most easily outside of 0280.
-
Ge0rG
So please let's get back to getting 0280 done.
-
pep.
Reading the discussion on #778 (0280 changes), what's the point of experimental XEPs if council is afraid changes are going to break things? Isn't that what this stage is for? It's already annoying enough when a XEP reaches Draft (not even Final) and people grump about any changes, but I'm not sure what's the point of experimental if nothing can change
-
dwd
pep., See previous discussion about how broken '280 is wrt process.
-
pep.
Well it's not yet Draft, at least
-
pep.
it's in between Proposed, LC, Experimental
-
pep.
So I'd say "if you have to break or bump, do it while you can".
-
moparisthebest
implementations wait for no one
-
moparisthebest
it doesn't matter if it's experimental or not even submitted, if thousands of devices in the wild implement it
-
pep.
Sure, so what?
-
moparisthebest
a good XMPP related example is aes-256-gcm file encryption with http upload
-
pep.
That's one of the many OMEMO failures indeed
-
pep.
But that's not related to what I'm saying
-
jonas’
for certain definitions of "good" example
-
moparisthebest
it's just, there is a difference between "theoretical" and "practical"
-
moparisthebest
theoretically, sure, not-draft/final means you can change anything, in practice, not so much
-
moparisthebest
there seems to be a lot of that in XMPP land, lots of "in theory, it'd be better done this other-way-no-one-will-ever-do" meanwhile it get's done and deployed the original way
-
Kev
pep.: I have limited concerns about breaking 280. My concerns are breaking it in the wrong way.
-
pep.
Kev, k
-
pep.
I guess my message was mostly directed at people who want another XEP for this
-
jonas’
(which includes Kev to a certain extent)
-
dwd
pep., One issue is that the proposed rules have had push-back from server developers quite consistently. But council(s) have rejected moving the spec to Draft without them. As such, the spec is highly deployed, yet still nominally in Experimental.
-
dwd
pep., Our process is meant to reflect reality, and not try to coerce reality into its own image.
-
pep.
So you'd change a Final XEP that's not used?
-
jonas’
a final xep can’t be not-used
-
jonas’
it can only be not-used-anymore, which would mean deprecation
-
jonas’
(at least two independent implementations are a requirement for moving to Final)
-
pep.
Yeah, not-used-anymore, implementations gone out of existance or sth
-
dwd
pep., Very happy to deprecate existing Final specs that are used if we wouldn't recommend people to implement anymore.
-
pep.
Not what I asked
-
dwd
pep., Stuff that's unused, but proven to work when it's needed, and remains our best idea of how to solve a problem can stay in Final, I think.
-
pep.
implemented != proven to work, but I guess that's up for debate
-
dwd
pep., I don't think there's any dispute that implementing something doesn't automatically mean it works. The converse is more interesting - if people don't implement, it's definitely not proven to work.
-
pep.
I just wanted to take you up on "Our process is meant to reflect reality, and not try to coerce reality into its own image.". Would that mean these stages are useless?
-
Ge0rG
dwd: re push-back from server developers, is that only about error tracking or were there other issues?
-
dwd
Ge0rG, Honestly, i can't remember. '280 just feels like a death march.
-
Ge0rG
I'd rather compare it with quicksand.
-
Ge0rG
Anyway, the unanswered question is: would it have unappreciated (side)effects to carbon-copy all messages of type=error?
-
Ge0rG
I'm pretty sure there is no problem with errors caused in the context of IM.
-
Ge0rG
besides of error messages generally being very ephemeral, which is maybe not what we want for IM-NG.
-
dwd
Ge0rG, We won't need errors in IM-NG, though, because everything will always work flawlessly.
-
Ge0rG
dwd: that is the MIX mindset.
-
dwd
Ge0rG, Every message will eb acrried to its desitnation personally by the magic unicorns riding fairies.
-
dwd
Ge0rG, And the stars! Oh, my the stars. They will be so pretty in IM-NG.
-
Ge0rG
why should unicorns ride fairies?
-
dwd
Ge0rG, IM-NG. It's just like that.
-
Ge0rG
are those rainbow-pooping unicorns?
-
Ge0rG
What is the amount of recreational drugs imported to the island, currently? Will there be a sensible Summit after Brexit?
-
dwd
Ge0rG, What the unicorns poop is currently under-specified.
- debacle has left
-
Kev
Ok, Carbons: Are people amenable to adding a feature in 280 saying that these are the rules used, and text saying that while these rules might be changed in the future they would result in a bump of the carbons-rules feature advertised, not of the carbons namespaces themselves?
-
Kev
I think that would mostly allow us some vague agility in fixing up the rules as we inevitably find better ones, without tying ourselves in knots if the spec goes to Draft or requiring bumps to the core NS because the rules have changed?
-
Kev
The rules themselves do seem reasonable enough to me on review.
-
Kev
Ge0rG: ^
-
Kev
If we can do that, I'm +1, else I need to think further.
-
Kev
I'm a tentative -1 without something like that because I think it needs consideration, but can possibly be talked up to a -0 on discussion.
-
jonas’
Kev, yes, I think that’s sane
-
jonas’
I think that’d be the best way forward indeed
- debacle has joined
-
Ge0rG
Kev: personally, I don't think that there is any benefit in versioning the rules. My client certainly won't use that to influence behavior. But I think that your proposal is sufficiently sane to not die on that hill.
-
Kev
Compromise, and all that :)
-
Ge0rG
Shall I amend to the XEP
- peter has joined
- peter has left
-
Kev
Amend to the XEP?
-
Ge0rG
Kev: I mean, shall I add another commit to the PR containing what you suggested?
-
Ge0rG
And will that be sufficient to satisfy the other Council members?
-
Kev
Works for me, thanks.
- peter has joined
- moparisthebest has left
- moparisthebest has joined
- debacle has left
- lnj has left
- peter has left
- daniel has left
- daniel has joined
- daniel has left
-
moparisthebest
Industry standard advice there is to have 1 joint and keep it well oiled, adding another joint is the opposite https://www.imperialviolet.org/2016/05/16/agility.html
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- debacle has left
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- Zash has joined
- daniel has joined
- daniel has left
- lnj has joined
- daniel has joined
- moparisthebest has left
- moparisthebest has joined
- lnj has left
- lnj has joined
- daniel has left
- daniel has joined
- debacle has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- vanitasvitae has left
- vanitasvitae has joined
- Ge0rG has joined
- peter has joined
- peter has left
- debacle has left
- debacle has joined
- peter has joined
- peter has left
- peter has joined
- moparisthebest has left
- moparisthebest has joined
- debacle has left
- lnj has left
- peter has left
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined