XMPP Council - 2019-04-17

Just a reminder that I’ll be in another meeting this afternoon, and thus not here.

Are we sitting comfortably?

I am

Then let's begin. Only not quite yet because it's not 4 yet.

Good morning, ladies.

OK.

1) Roll Call

Here.

here

Missing Link Mauve as expected - he sent apologies last week.

2) Agenda Bashing

We've four items this week, all PRs.

I've been busy all day and not in a position to bash, sadly.

#736, #778, #784, and #785

Any others?

Assuming not.

3) Items for a vote (or discussion):

a) https://github.com/xsf/xeps/pull/736 XEP-0308: Allow message correction in MUC

I'm concerned about this one.

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.

Mostly about the idea of servers needing to store data on every past occupant.

yeah, I don’t think that’s sane

As the current text doesn't seem to have any sort of time limit on corrections.

clients cannot rely on the feature unless we impose O(+infty) amount of work on servers

isn't it sufficient to store the real bare JID on all messages in the history log?

the history log may be +infty long

and you need to do a search for the corrected message

for each correction

that sounds like a very easy DoS vector to me

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.

-> no server right in their minds is going to implement this.

right. unless you have... an index!

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.

even then it’s computationally complex ✏

" If it does so, the receiver can trust any message correction received through this room, be it live or from history."

That is, a server saying Nope every time is, I think, conformant as written.

I think it's clear that the intent is that advertising the feature means that every correction has been checked for validity.

Kev: I agree

Kev, Yes, but not that every correction has been accepted that could have been.

Yes, that is true. But also quite unhelpful.

I think it's a useful feature to have, and I don't know how Link Mauve implemented it.

In any case, the "SHOULD" and "should" and things scare me at the moment.

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

So I'm -1 for now, but I think this can be fixed.

jonas’: because you can flood the server with bare JIDs?

if clients cannot rely on it (because the server is allowed to age out information), it is not useful

I'd have rathered discussed with Link Mauve here. I think I have to tentatively -1 this until we can discuss what's needed.

Ge0rG, for example, or simply with messages

dwd: you are -1 because what can be fixed?

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.

Dave is right there, I think.

Ge0rG, Language. I don't think it's actually describing what's normative very well.

Kev, that needs to be spelt out clearly though

I think so, yes.

-1 until the DoS vector and how it is to be mitigated and what clients can expect there is clarified

Kev, Ge0rG ?

on-list to see what comes out of your questions.

Already -1d.

Thanks.

I feel like +1, but the raised points are valid as well.

aa) XEP-0308: relax from-full-JID requirement https://github.com/xsf/xeps/pull/784

I feel like this is intimately tied in with #736, myself.

I’m +1 on that one

dwd, it’s not necessarily

dwd: Why's that?

dwd: #736 is implying it, but it's not tied in any way.

Or perhaps I misread - is this purely client-side?

it can be done purely client side

(and the text suggests that)

dwd: the text is deliberately open about client- or server-side

Oh, you're right, that 'or the MUC service' does imply it. Because a client cannot do the verification itself.

"either the recipient or the MUC service need to ensure that the real bare JID of the sending occupant didn't change in between"

(Unless it's non-anonymous)

Kev, it can

Ah, yes. OK, in that case it's fine. +1

So that means that where the recipient can't do it, to satisfy that requirement the MUC service must have done it.

if there was a part/join in-between, it might not be the same sender -> reject ✏

Which puts requirements on a MUC service where there were none before.

it’s not a requirement -- clients already implement that check, actually.

Kev: the recipient can do it if neither you nor the sending occupant did leave the MUC between the original and the correction. ✏

some clients.

yeah, others default the check to "not allowed" ;) ✏

This feels like it'd be more cleanly written in terms of who's expected to do what when based on top of 736.

other clients ignore it altogether because identity of occupants in a semi-anon muc is pointless.

maybe, but I still think this can stand on its own, so +1

Kev, See, when I said that everyone disagreed. :-)

+1 obviously.

dwd: I didn't. I asked why.

Kev: I could provide a better wording of #784 once #736 is approved. Which it isn't.

as it is now, I think that the wording is sufficient for either outcome of #736.

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.

Kev: we are speaking of a footnote.

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.

As without 736 the MUC service doing things doesn't help at all anyway.

Kev: if that is your prerequisite for accepting, I can re-word.

Kev, Or at least, without '736, the recipient has no idea if the MUC service is doing anything.

Ok, +1 after tweaking.

dwd: Indeed.

OK, then.

Thanks!

c) https://github.com/xsf/xeps/pull/785 - XEP-0260: Replace broken link with archive.org

Not a Council voting item, I think, just Editorial.

as a matter of form, I'd not replace the anchor text, just the link.

I think that’s sensible

That makes more sense.

But I agree with Kev that this is Editorial, so +1.

will take care of that

I think I'd be inclined for Council to instead decide it's Editorial, rather than voting as if it wasn't.

It affects versioning, for example.

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.

No, I'm fine with this being Editorial.

yeah, editorial

I wouldn’t even have raised this to council

I'm a little concerned with how close to normative behaviour this is, though, being described in an external link that's gone dead.

Is there a better specification for SOCKS5 we could/should be using here?

dwd: Oh, I didn't read it that way. Maybe I've misunderstood.

So let's re-vote on this kind of things being Editorial Changes?

I thought it was saying "And for people who remember this old proposal, this is much the same".

yeah, it should probably be moved to the XEP, if we can get this sorted out legally

(When I say "Maybe I've misunderstood", I'm actually fairly confident that I haven't)

Kev, Yes, you probably haven't misunderstood. I'm just a little sensitive to external links in the XEPs.

Agreed that this is Editorial, suggest to the Editors to not change the link text, just the link, and move on?

ANyway, the change itself is certainly Editorial. I just wanted to make sure we're happy with the linking at all.

That requires obtaining permission from Justin to incorporate the text as an informational part? as a dedicated informational XEP?

dwd: +1 to that motion.

Ge0rG, You're happy?

Anyway, probably no conclusions to be made here.

4) Outstanding Votes

Please check 'em.

dwd: what about d)

Ge0rG, Oh, I skipped one, didn't I?

no, wait. it was b) which should have preceded your c) but probably was missed due to aa).

b) Discussion: https://github.com/xsf/xeps/pull/778 XEP-0280: Rewrite of the 'Messages Eligible for Carbons Delivery' section

ndeed, that ^^

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.

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.

Formally, 0280 is somewhere between Experimental and Abandoned.

Ge0rG, Yeah. XEP-0280 isn't in a happy place, in terms of process.

dwd, we’re on the road to that, it’s called IM-NG

jonas’, That road is very long and shows no sign of getting shorter.

dwd: it also had a bunch of Last Calls.

I don't think roads typically get shorter, you just move along them :)

Ge0rG, This, too, I'm aware of.

Kev: that road is a kind of moebius strip, apparently.

I would be much happier with the idea of formal rules in a XEP with its own feature.

Kev, Yes, I don't think that's happening either.

Ge0rG: But at least it doesn't change in its infinite length.

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.

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.

from what I can see, this PR mostly clarifies how carbons interact with MUCs

the other rules seem untouched

jonas’: the other rules move from MAY to BREX^W SHOULD

ah, right

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.

one could advertise this ruleset in a feature if it makes people happy

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.

dwd, it can also be made MUST in the same XEP with a feature

and I’d prefer that

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.

I am a bit wary of the XEP proliferation we have

jonas’, We should write a XEP on that.

right, so a new feature which advertises this exact ruleset?

As it is now, 0280 is not only in a very sad place process-wise, it is also a very sad specification.

or rather, a very saddening one.

With a new feature, I'd suggest that many of the SHOULDs in Georg's PR could be MUSTs.

I'm going to need to think about this at-length and on-list, in any case, because I'm a bit rubbish.

Kev: please also read up the many discussions of that from the last five years.

I’m +0 on this without feature, +1 with a feature + MUSTification.

dwd: I can make that a feature-conditioned MUST in 0280.

(obviously, the error tracking stuff should stay non-MUST)

Ge0rG: I'm confident you don't want me to do that.

> (obviously, the error tracking stuff should stay non-MUST)

I disagree with that, and that makes a good distinct discussion point.

What to do with errors.

Practically, it sucks to not receive errors for carbonated messages.

Ge0rG: Is the sticking point with a separate spec that you don't have the energy for it, or you think it's wrong?

FWIW, I think I'm the same as jonas’ here - +0 but +1 with a feature.

Ge0rG, but error-tracking is expensive

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).

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.

I don’t think that a separate XEP is the right tool here

jonas’: error-tracking is expensive. What about fanning out all message errors?

that would probably work

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.

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.

OK - I'm going to move on, but we can come back to this after the meeting.

But also that we couldn't sensibly Draft 280 with the rules in for some time.

And this would also let us decide that other rules were better in the future.

I think other rulesets should be developed in the IM-NG realm of things

5) Next Meeting

Next week?

wfm

Kev: what is the point of Drafting 0280 without the rules?

+1W WFM

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.

I'm in the office next week, so might be disrupted - I'll try to make it though.

6) AOB

Oh, there is _yet another_ dimension on Carbons: Transports

Anything other than '280?

No AOB

7) Ite, Meeting Est.

Ge0rG, I'm of the general opinion that transports are often rubbish, but how so in this particular case?

dwd: we should allow a Transport to send sent-carbons when the user sent a message from a native-protocol client.

Ge0rG, Ah. Funnily enough, I do exactly this. Or did.

There was a weirdly worded list inquiry by Владимир.

https://mail.jabber.org/pipermail/standards/2018-January/034224.html

Oh, yeah, I had all those problems.

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.

my uh, client side transport thing, relies 100% on carbons to work

Ge0rG, Yes. Also, MAM needs to archive those messages.

dwd: yes.

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?

But really, _this_ problem of Carbons can be solved most easily outside of 0280.

So please let's get back to getting 0280 done.

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

pep., See previous discussion about how broken '280 is wrt process.

Well it's not yet Draft, at least

it's in between Proposed, LC, Experimental

So I'd say "if you have to break or bump, do it while you can".

implementations wait for no one

it doesn't matter if it's experimental or not even submitted, if thousands of devices in the wild implement it

Sure, so what?

a good XMPP related example is aes-256-gcm file encryption with http upload

That's one of the many OMEMO failures indeed

But that's not related to what I'm saying

for certain definitions of "good" example

it's just, there is a difference between "theoretical" and "practical"

theoretically, sure, not-draft/final means you can change anything, in practice, not so much

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

pep.: I have limited concerns about breaking 280. My concerns are breaking it in the wrong way.

Kev, k

I guess my message was mostly directed at people who want another XEP for this

(which includes Kev to a certain extent)

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.

pep., Our process is meant to reflect reality, and not try to coerce reality into its own image.

So you'd change a Final XEP that's not used?

a final xep can’t be not-used

it can only be not-used-anymore, which would mean deprecation

(at least two independent implementations are a requirement for moving to Final)

Yeah, not-used-anymore, implementations gone out of existance or sth

pep., Very happy to deprecate existing Final specs that are used if we wouldn't recommend people to implement anymore.

Not what I asked

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.

implemented != proven to work, but I guess that's up for debate

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.

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?

dwd: re push-back from server developers, is that only about error tracking or were there other issues?

Ge0rG, Honestly, i can't remember. '280 just feels like a death march.

I'd rather compare it with quicksand.

Anyway, the unanswered question is: would it have unappreciated (side)effects to carbon-copy all messages of type=error?

I'm pretty sure there is no problem with errors caused in the context of IM.

besides of error messages generally being very ephemeral, which is maybe not what we want for IM-NG.

Ge0rG, We won't need errors in IM-NG, though, because everything will always work flawlessly.

dwd: that is the MIX mindset.

Ge0rG, Every message will eb acrried to its desitnation personally by the magic unicorns riding fairies.

Ge0rG, And the stars! Oh, my the stars. They will be so pretty in IM-NG.

why should unicorns ride fairies?

Ge0rG, IM-NG. It's just like that.

are those rainbow-pooping unicorns?

What is the amount of recreational drugs imported to the island, currently? Will there be a sensible Summit after Brexit?

Ge0rG, What the unicorns poop is currently under-specified.

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?

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?

The rules themselves do seem reasonable enough to me on review.

Ge0rG: ^

If we can do that, I'm +1, else I need to think further.

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.

Kev, yes, I think that’s sane

I think that’d be the best way forward indeed

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.

Compromise, and all that :)

Shall I amend to the XEP

Amend to the XEP?

Kev: I mean, shall I add another commit to the PR containing what you suggested?

And will that be sufficient to satisfy the other Council members?

Works for me, thanks.

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