- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- lnj has joined
- daniel has left
- daniel has joined
- moparisthebest has left
- lnj has left
- lnj has joined
- lnj has left
- lnj has joined
- lnj has left
- lnj has joined
- lnj has left
- lnj has joined
- debacle has joined
- lnj has left
- lnj has joined
- lnj has left
- debacle has left
- lnj has joined
- lnj has left
- lnj has joined
- lnj has left
- lnj has joined
- lnj has left
- lnj has joined
- debacle has joined
- daniel has left
- Zash has left
- Zash has joined
- moparisthebest has joined
- moparisthebest has left
- moparisthebest has joined
-
Kev
I should be back for Council today, but there's a chance of lateness or missing, depending on traffic etc.
- moparisthebest has left
- moparisthebest has joined
- dos has left
- jonas’ has left
- jonas’ has joined
- Ge0rG has joined
-
Kev
'Tis time.
-
Link Mauve
Good morning. :)
-
jonas’
oh hai
-
Ge0rG
The times they are a-changin'!
-
Kev
Come gather 'round, people.
-
Kev
dwd?
-
Kev
Ge0rG: Did you see https://github.com/xsf/xeps/pull/781 ?
-
Ge0rG
Kev: sorry, no.
-
Ge0rG
There seems to have been a bit of a lack of agenda.
-
Kev
We seem to be missing a Dave, so ...
-
Kev
1) Roll call
-
Kev
I'm here.
-
Link Mauve
o/
- Ge0rG .o/
-
jonas’
here
-
Kev
2) I think there's been nothing on the published agenda, other than me mentioning https://github.com/xsf/xeps/pull/781 yesterday morning, right?
-
jonas’
I think that’s true
-
Kev
This is the PR to try to address the metadata/content during LMC thing, as promised.
-
Kev
As it's a 30 second review, I suggest people just do that now, if they've not seen it yet.
-
Ge0rG
Kev: I have another interesting proposal in that context to make. A receiving entity should accept a correction both to the original ID and to intermediate correction IDs.
- debacle has left
-
jonas’
Kev, my problem with that proposal is that "metadata" isn’t really clearly defined
-
Ge0rG
Kev: that essentially boils down to the philosophical question dwd brought up last time
-
Ge0rG
what jonas’ said
-
Kev
Ge0rG: I'm not keen, as that drastically increases complexity everywhere.
-
Link Mauve
What was this XEP saying that you shouldn’t bloat a stanza with many unrelated payloads?
-
jonas’
Ge0rG, yeah, I don’t want to track multiple IDs to merge corrections, and neither will an archive want to
-
Kev
We'll never manage to fully define it, but I think at least the idea is clear enough here. Welcome to further text tweaks, obviously.
-
Ge0rG
Kev: I'm +0 for the sake of not dying on hills.
-
jonas’
it makes me think we should’ve defined a metadata block in stanzas at the beginning
-
jonas’
but I guess we can’t
-
jonas’
and I think the text makes things clearer
-
jonas’
so +1
-
Kev
jonas’: When we next get to 1999, we can consider that :D
-
Kev
Thanks.
-
Ge0rG
Kev: due to the current GPS week rollover, we _are_ technically in 1999.
-
jonas’
(one way out would be to spell out correctable payloads)
-
jonas’
ha!
-
jonas’
Ge0rG, but we’re also in 1979, aren’t we?
-
Ge0rG
https://twitter.com/ChinaAvReview/status/1114802018919411712
-
Kev
Link Mauve ?
-
Link Mauve
+1 as for the previous version.
-
Kev
Ta.
-
jonas’
(xep-0308: and go ahead and patch all the other xeps with explicit mention when they can be corrected)
-
Kev
3) Date of next
-
jonas’
(but yeah, current text is fine)
-
Kev
SBTSBC?
-
jonas’
Kev, I think you wanted to start a discusison about compliance suites, didn’t you?
-
Ge0rG
+1W WFM
-
jonas’
+1wwfm
-
Kev
I do, I think it's AOBish, rather than a voting item, though.
-
Link Mauve
There are many XEPs which I’d like to revisit to mention that they are metadata, and how it should behave. For FSE especially.
-
Link Mauve
+1W wfm.
-
Zash
https://xmpp.org/extensions/xep-0226.html comes to mind
-
Kev
4) AOB. Anyone else got any before I do mine?
-
Link Mauve
Zash, right, this one.
-
jonas’
I don’t have any
-
Ge0rG
Yeah, two of them
-
Link Mauve
Me neither.
-
Ge0rG
AOB-a: https://github.com/xsf/xeps/pull/779
-
Ge0rG
AOB-b: https://github.com/xsf/xeps/pull/778
-
Ge0rG
the former is for a Draft XEP so needs to be voted on, sooner or later.
-
Ge0rG
The latter is essentially what I brought up back in 2017, but without the reliance on Hints.
-
Ge0rG
Also I'm not sure whether we are going to hear back from the nominal author, so bringing this up before Council
-
Kev
I'm not ready to express opinions on either yet - can we schedule them as full items for next week?
-
Link Mauve
AOB-a +1 for me.
-
Link Mauve
Or we can reschedule.
-
Ge0rG
I've waited for two years now, can't you see how urgent the 0280 issue is?
-
Link Mauve
Ge0rG, would you want to become a shepherd for AOB-b?
-
jonas’
*squint*
-
Ge0rG
> BTW, I volunteer to take over 0280 authorship if the need arises.
-
Ge0rG
Link Mauve: ^ from the PR
-
Link Mauve
Great. :)
-
Ge0rG
https://github.com/xsf/xeps/pull/779 is surely a five-minute review thing.
-
Kev
You'd think, yes.
-
Ge0rG
But I'm not going to push anyone into anything, so +1W is fine with me.
-
jonas’
I’m +1 on that one
-
Kev
I'm just struggling to decide on an opinion about making existing implementations non-compliant, which the MUC block surely does.
-
jonas’
Kev, it doesn’t matter, because sending type="groupchat" to full jid is an error already
-
Kev
And that's a good reason for me to do a proper review, I suspect.
-
Ge0rG
Unless you are responding to a MUC request with a PM receipt.
-
Ge0rG
Which is also a possible way to do things.
-
Kev
Anyway, I think everyone else is +1 on 779, so we may as well treat that as item 2b rather than AOB.
-
Kev
And suggest we put 778 in for proper discussion next week.
-
Kev
And I'll on-list 799.✎ -
jonas’
I think that’s sane
-
dwd
Afternoon, sorry, meeting overrun.
-
Kev
And I'll on-list 779. ✏
-
jonas’
oh, wb dwd✎ -
jonas’
oh, welcome dwd ✏
-
Kev
Welcome.
-
Kev
You're not taking my gavel ;D
-
Kev
AOB3, then. Compliance suites.
-
Kev
I suggested that we move away from yearly compliance suites that try to encapsulate everything, and frequently lead to heat in trying to update them on time, and instead move to a pair of 'living documents'.
-
dwd
Kev, You're welcome to it.
-
Ge0rG
small note re next meetings: I'm going to be gone on three of the May Council meetings
-
Kev
The intention being that one defines where we think the network is, and the other where we see it going. So it's a bit easier to look at Current and see what's needed for interop right now, and Future to see what would be a good idea to do for future interop.
-
jonas’
Kev, I think that’s a very sensible idea
-
Ge0rG
Kev: this is a great idea.
-
dwd
Kev, The general idea seems fine. But are these living documents XEPs?
-
Link Mauve
Oh indeed, next week I am away during this meeting, I will be back the week after.
-
Kev
dwd: I think that's the sensible next question. For my money, I think they are, yes, but I think that detail less important than the direction of travel.
-
Link Mauve
Kev, excellent idea.
-
Kev
(I think they're Informational, rather than Standards-Track, at least)
-
jonas’
they could easily be Informational XEPs in Active mode✎ -
jonas’
they could easily be Informational XEPs in Active status, maintained by Council ✏
- Kev ^5s jonas’.
-
jonas’
although arguably XEP-0001 explicitly states compliance suites-like things to be Standards Trak ;)✎ -
jonas’
although arguably XEP-0001 explicitly states compliance suites-like things to be Standards Track ;) ✏
-
Kev
Indeed, but these aren't compliance suites :)
-
jonas’
then again, if it isn’t about compliance but about a "what to implement" it’s not that
-
jonas’
^5 again
-
dwd
One of the reasons we named the existing compliance suites the way they are is to encourage implementors to use them as marketing terms. What do implementations say they're compliant to, in this brave new world?
-
Zash
So a "how XMPP works now" and a "how we want XMPP to look in the future" documents? I approve.
-
jonas’
"XMPP Core XEPs version X"
-
jonas’
that works nicely with the badge system, too
-
Ge0rG
jonas’: I propose X to be mapped to time periods of sufficient length.
-
Ge0rG
i.e. years.
-
Kev
Assuming (and this is a significant assumption, based on behaviour I've seen) that the need to announce you're compliant to something is important, XEP-0467 version 1.1 would be fine, I think.
-
jonas’
Ge0rG, versions can easily be YYYYMM.x
-
Kev
jonas’: They can't, actually, given xep1.
-
jonas’
XEP-0001 has some opinions about version numbers, but I think we can get an override from board for that ;)
-
Kev
One of the things I'm fairly keen we do is not have dates involved in this.
-
Link Mauve
dwd, from what I’ve gathered, people would very much prefer things like “XMPP 2019” for marketing purposes, compliance suites don’t fit that role very well except for technical people.
-
Ge0rG
Kev: what's your rationale for that?
-
jonas’
Kev, not at all?
-
Link Mauve
And for technical people, Conversations’s website does a much better work at that.
-
Kev
The argument keeps getting presented that having a suite with a date in it that isn't the current year makes us look unprofessional and the sky falls in.
-
Ge0rG
Kev: does that argument have any merit?
-
Kev
And that leads us to trying to rush through new versions without (I think) due consideration.
-
Kev
And ISTM the cost of not having the date in the version is approximately zero.
-
jonas’
that’s a good point, but independent of that, I don’t think we can stay with the vanilla XEP-1 version schema for those documents, because version "1.234" looks stupid.
-
Kev
jonas’: If these are updated more often than every year, I'll be pleasantly surprised.
-
dwd
Can't we call it after animals? Seems to work well for Ubuntu.
-
Kev
I also point to XEP-0045 1.31.2
-
Ge0rG
Kev: I think that the year is a much better indicator of up-to-date-ness than an arbitrary version number
-
jonas’
dwd, no, with my editor hat on, I require version numbers to be numeric and totally ordered
-
jonas’
as long as XEP-0001 permits me to require that
-
Kev
Ge0rG: I think my argument is that using versions to give an idea of up-to-dateness isn't helpful here.
-
jonas’
Kev, but do you point to '45 1.13.2 for marketing purposes?
-
Kev
jonas’: No, for an example of a XEP with a daft number of revisions without the sky falling :)
-
dwd
I'd be happier with versions of XEPs if we could also reliably point to them, but I'm not entirely sure how.
-
jonas’
point is, it looks weird to me, and it will look weird to folks outside the XSF when used for marketing
-
Kev
dwd: We could make a point of including the changelog fully in these XEPs, if we wanted.
-
jonas’
I’d like to throw in that I started tagging things on github and I’m looking into automating that kind of stuff more
-
jonas’
even though that might mean, in the long run, that I run my own infrastructure next to the XSF’s
-
Ge0rG
Kev: I think that having an immediate idea of up-to-dateness outweighs the drawback of us not having a 2019 suite by April 2019 being doomsday.
-
dwd
Otherwise, I'm fine with running a year-long experiment on "living" documents of this form, with an expectation that we define what success looks like and revisit after 6 and 12 months.
-
Kev
Anyway, it sounds to me like people think this is a sensible direction of travel, and we're mostly discussing versioning details, does that sound fair?
-
jonas’
Kev, yes
-
jonas’
I think what dwd says is good
-
Link Mauve
Kev, indeed.
-
Kev
dwd: Although I note we never defined what success looks like for the Compliance Suites, and I've considered them a failure for many years :)
-
dwd
Kev, Yes, but it'd be nice to have some idea of what constitutes success.
-
Kev
But we've gotten out of this discussion what I was hoping to get out of it at this point. Can we Agendaify another discussion on the topic for, say, the start of June, please?
-
dwd
Kev, If only to determine that we have failed once more.
-
dwd
Kev, Sounds sensible.
-
jonas’
Kev, do we have long-term agenda planning techniques? ;)
-
jonas’
(other than open PRs against xeps)
-
Kev
jonas’: I call it Dave.
-
Kev
AOAOB?
-
jonas’
not from me
-
Ge0rG
I think that with our current tooling, the current form of CS is the least failed way to do it.
- Kev bangs the gavel and hands it back to Dave.
-
Kev
Thanks all.
-
dwd
Kev, Thanks for stepping up there.
-
Kev
dwd: You've got two votes from today, I believe, to on-list (and I've got one).
- Kev goes back to his day off.
-
Ge0rG
I'm actually unconvinced of everything proposed above except for the general idea.
-
dwd
Ge0rG, Was there more than a general idea?
-
Ge0rG
And that general idea can easily be mapped onto yearly CS XEPs.
-
Ge0rG
...provided somebody does the actual work.
-
dwd
Ge0rG, Aye, there's the rub.
-
Ge0rG
dwd: > I suggested that we move away from yearly compliance suites that try to encapsulate everything, and frequently lead to heat in trying to update them on time, and instead move to a pair of 'livingdocuments'.
-
Ge0rG
> The intention being that one defines where we think the network is, and the other where we see it going. So it's a bit easier to look at Current and see what's needed for interop right now, and Future to see what would be a good idea to do for future interop.
-
dwd
Ge0rG, Ah. So *some* of that neatly fits onto Compliance Suites.
-
dwd
Ge0rG, Mostly the first document.
-
Ge0rG
dwd: yes.
-
Ge0rG
Now would be a good time to start a proto-CS-2020, or maybe a proto-future-CS
-
dwd
Ge0rG, The key change is a single mutating document instead of multiple documents.
-
Ge0rG
dwd: and due to tooling reasons, I actually object to _that_ change.
-
jonas’
why?
-
Ge0rG
Because XEP versioning is an ugly business.
-
dwd
Ge0rG, And one I noted.
-
jonas’
I find non-obvious XEP numbers for CS worse
-
jonas’
we can fix the versioning
-
Zash
BCP-0001
-
Ge0rG
We don't have good link-ability to old versions, and we don't have good diff views.
-
jonas’
the diff views are an argument, but that doesn’t get fixed with separate documents at all
-
Ge0rG
can has xep-2019.xml
-
Ge0rG
jonas’: touché
-
jonas’
if anything, it is worse, because in the future, we might get diff tools back, but those will work between versions, not xeps
-
dwd
Ge0rG, Link-ability would be interesting. We could link to old versions via the changelog, too.
-
jonas’
and link-ability to old versions can be fixed, too
-
jonas’
for those which are built, that is
-
Ge0rG
dwd: the changelog is just a muddy reflection
-
jonas’
that’s the authors fault though
-
jonas’
or maybe the editors, but the author can do something about it
-
Ge0rG
so let's mandate *proper* changelog maintenance for Compliance Suites, whatever "proper" means.
-
Ge0rG
If we have link-ability to past versions, we could have the Compliance Badges link to a specific (currently latest) version of the XEP
-
Ge0rG
and change the year each year.
-
Ge0rG
And have a Future-Extensions pseudo-CS XEP that gets updated with nice-to-have things like MIX, bind2 etc. And once a year, we make a campfire and decide which ones to move from FE to CS.
-
dwd
Ge0rG, So #778. What's the rationale here?
-
dwd
For the CS Date, we can of cours ejust change the title on the new version.
-
Ge0rG
dwd: the overall high-level rationale, the specific rationale of individual commits or ... ?
-
dwd
Ge0rG, High level, to begin with.
-
Zash
Have a persistent item at Summit?
-
Ge0rG
dwd: Carbons have many broken corner cases
-
dwd
Zash, Hush now.
-
Ge0rG
dwd: we had a very long time to fix the weasel-words out of the XEP by collecting experience. Mostly nobody cared about it.
-
dwd
Ge0rG, Right, but is that because it doesn't matter?
-
Zash
dwd? :(
-
Ge0rG
dwd: I'm running into ugly corner cases of Carbons every some months, and then spend half a day reading XML logs from multiple entities to determine that it was just one of the corner cases, again.
-
dwd
Zash, It's hardly the only repetitive topic at Summits.
-
Ge0rG
dwd: is that a trick question?
-
dwd
Ge0rG, No, I'm trying to figure out the rationale, and thereby decide on the best way to progress this work.
-
Ge0rG
dwd: let's say the rationale is to have a set of rules that can be applied at the border of a routing2 IM-NG domain.
-
dwd
Ge0rG, To what end?
-
Ge0rG
dwd: to fix the user experience
-
Ge0rG
dwd: the rules written down in the PR are the "collective wisdom" that I have collected over the years that isn't actually written down anywhere.
-
Ge0rG
Also improvements to the rules to make them more consistent
-
dwd
Ge0rG, OK, this seems more useful. So what happens if a server doesn't follow these rules?
-
Ge0rG
like carbons of errors.
-
Ge0rG
dwd: the corner cases remain unfixed
-
dwd
Ge0rG, Yes, but at a high level?
-
dwd
Ge0rG, And if a server doesn't follow these rules, can a client do anything about it? Can it make assumptions if the server does?
-
Ge0rG
dwd: I'm not sure where you are aiming
-
dwd
Sorry, not trying to be difficult here. Trying to get a better feel for how these rules change what a client and/or user can/should do.
-
Zash
Hm. https://xmpp.org/extensions/xep-0001.xml
-
Ge0rG
dwd: yeah, not feeling offended, just not sure how to answer
-
dwd
Ge0rG, OK, let me ask a different question. If these rules were in a different XEP, and servers advertised their compliance, would this be better?
-
Ge0rG
dwd: I don't think so. The "old" rules are very much weasel-worded, so servers are free to bend them in any conceivable way.
-
Ge0rG
dwd: thus clients typically don't rely on anything working
-
dwd
Ge0rG, I'm thinking that they could then be made MUST instead of SHOULD, and clients would know if they were in operation. The result is, I think, more stability and awareness.
-
Ge0rG
dwd: this leads to interesting effects, like Conversations not actually making use of 0184 because sometimes it's not reliable and thus users might question why there is no checkmark
-
Ge0rG
dwd: now you are talking!
-
dwd
Ge0rG, I'm also aware that server implementations tend to adopt things faster if they can advertise their support.
-
Ge0rG
dwd: the reasons why I didn't go for MUST are essentially: - I only know of IM, not of IoT, VoIP and all the other shiny use cases of XMPP - with the current weasel-wording, I think what I PRed is the maximum I can bend the XEP to without a namespace bump - I might have overseen something
-
Ge0rG
Also 0280 as it is now is a VERY BAD XEP.
-
dwd
Ge0rG, I think, also, that then as the rules get more refined - and I think they probably will - servers can advertise potentially multiple levels as long as the new rules are a superset.
-
Ge0rG
dwd: I'm still not sure it makes _technical_ sense to advertise some kind of support level for 0280 rules
-
dwd
Ge0rG, I honestly don't know. For diagnostics, it probably does.
-
dwd
Ge0rG, But I'm not sure that clients would alter behaviour.
-
Ge0rG
I wouldn't in mine.
-
Ge0rG
And I'm not often looking into disco#info when diagnosing things.
-
Ge0rG
dwd: also what would happen if the rules get extended? namespace-bump them? Have all versions that are still complied to in disco#info?
-
dwd
Ge0rG, The latter I imagine.
-
dwd
Ge0rG, But also, I think working on it in a separate XEP might prove more politically viable.
-
Ge0rG
I'm not opposing, just wondering if it actually has value.
-
Ge0rG
dwd: see above. > Also 0280 as it is now is a VERY BAD XEP.
-
dwd
Well, you'd eventually have a patch which removes the rules from '280 and points at ${NEWXEP}
-
Ge0rG
not only because the wording is very cumbersome and confusing, but also because the core point of a XEP is to define interop, and you can't define interop by making everything MAY.
-
Ge0rG
(insert Brexit pun)
-
Ge0rG
dwd: how is that formally different from having the rules in 0280 and not having another XEP?
-
dwd
Ge0rG, It isn't, but I see an easier path to get there from here.
-
jonas’
do you think council will oppose that change?
-
dwd
Ge0rG, But understand: I'm only throwing ideas out there.
-
Ge0rG
dwd: and once we are there, we merge the two XEPs into one?
-
Ge0rG
dwd: is there some special political meaning to the number 0280, that I don't know about because I'm too young?
-
dwd
jonas’, WHich change? The rules update? Probably less likely to cause problems if the new XEP is mature and well-supported.
- zinid has joined
-
dwd
Ge0rG, No, I don't think so. But it feels odd replacing a lot of MAY rules with a lot of SHOULD [NOT] instead. If we want firm rules, then it feels simpler to get there via another XEP.
-
Ge0rG
dwd: "simpler" in the sense of the XSF Council process?
-
dwd
Ge0rG, I was thinking community more than Council.
-
Ge0rG
So I start out with a new XEP that only defines specific rules, then I bully server implementors until they follow it, then I get it merged into 0280 as the new norm?
-
dwd
Ge0rG, Well, you wouldn't need to bully server implementors to follow it, but it'd make for a compelling argument to incorporate into '280, whether by reference or directly.
-
Ge0rG
dwd: if I didn't need to bully server implementors, they'd have the Good Rules by now.
-
Ge0rG
(making a PR against 0280 was actually my attempt to bully server implementors)
-
dwd
Ge0rG, Yeah. I think a new XEP might be more persuasive than bullying.
-
Zash
Routing 2.0?
-
dwd
Zash, I'm not mad keen on fork-lifts.
-
Zash
XMPP 2.0 !
-
Ge0rG
I think that with the frustration I've built up over the years of coping with 0280, a large amount of heavy editing would be required if I was to write that new XEP.
-
Zash
dwd: Some videos of omniwheel forklifts ough to change your mind :)
-
Ge0rG
(incidentally, the 0184 PR could have happened half a year ago if it wasn't for some curse words in the XML)
-
Ge0rG
also I'm not sure how much a SHOULD is a fork-lift.
-
Ge0rG
Personally, my history with 0280 is comparable to what other people have experienced with Compliance Suites of various years. You can only withstand so much pointless rejection.
-
Ge0rG
(which is also why it took almost two years for me to re-issue #434)
-
Ge0rG
So if Council actually decides to veto this PR, it might well happen that I won't make any progress on the suggested new-XEP route for another year, or two, or longer. Depending on how soon I'll run into the "why the effinf eff are those messages not arriving" situation again
-
zinid
wut, 280 again?
-
zinid
is it meeting now?
-
Ge0rG
zinid: meeting is over, context is https://github.com/xsf/xeps/pull/778
-
zinid
meeting was at 15:00 UTC?
-
zinid
whatever
-
Ge0rG
zinid: https://logs.xmpp.org/council/2019-04-10#2019-04-10-611d9881cd1a08ca
-
dwd
zinid, The '280 thing is basically a tradition now.
-
zinid
meh
-
zinid
booooring
-
dwd
zinid, Do you happen to know what carbon rules ejabberd implements?
-
zinid
dwd, no 🙂
-
zinid
I'm not the author and don't have any desire to touch the code with 19m pole
-
zinid
it is better not to touch the routing in the server, it always ends up with something borked 😀
-
dwd
Yeah it is always the weirdest, hariest code in any server.
-
dwd
No doubt Zash will tell me that Prosody's routing code is perfect about now. :-)
-
Zash
dwd: Yes, it's perfect, so I don't wanna touch it ever again! /me hides
-
Ge0rG
Zash: LIES!
-
dwd
Ge0rG, No, I believe he never wants to touch it again.
-
Zash
Carbons and MAM are in stable releases now, changing anything will probably be massively painful
-
zinid
do we need to change something? From the PR it's not very clear, looks like just wording improvement
-
Ge0rG
zinid: depends on what you do.
-
Ge0rG
I know that prosody lacks with 0184 payloads of type normal and on error responses.
-
dwd
I think errors is a definite change from previous recommendations, isn't it?
-
Zash
Prosody does carbons with (type=chat or (type=normal and has <body>))
-
Zash
modulo hints
-
Ge0rG
Previous recommendations were all MAY, but they contained error handling
-
Ge0rG
> A <message/> is eligible for carbons delivery if it is of type "error" and sent in response to a <message/> that was itself eligible for carbons delivery (Note that as this would require message tracking and correlation on the server, it is unlikely to be generally appropriate for most implementations).
-
dwd
Ge0rG, Ah, indeed. But not '184.
-
Ge0rG
dwd: CSN and Receipts are new, yes.
-
Ge0rG
Unless your receipts are of type=chat, in which case they magically work.
-
dwd
Ge0rG, So basically if we adopt this text, we're declaring all existing implementations to be non-conformant?
-
Ge0rG
But that in itself is kind of a violation of 0184
-
Ge0rG
dwd: you make it sound negative.
-
zinid
> CSN and Receipts are new, yes abstract leakage again
-
zinid
*abstraction
-
Ge0rG
zinid: that kind of leakage is also happening in LMC currently.
-
zinid
well, maybe, that's client devs problems, I don't care 😀
-
Ge0rG
dwd: the PR consists of a set of patches with varying degrees of controversy. If you feel better about our backward compatibility, I can regroup them into a set of patches that doesn't violate the weasel words, and another one doing substantial improvements.
-
dwd
Ge0rG, I think I like the changes. Just trying to figure out the most effective way of getting them deployed.
-
Ge0rG
But I'm more interested in moving xmpp forward than in fighting process debates.
-
Ge0rG
(at least in this specific case)
-
dwd
Ge0rG, Not so much process as trying to get the server devs to actually implement.
-
Ge0rG
dwd: I'm not sure there is an elegant solution to *that* problem.
-
dwd
Ge0rG, No, but there may be multiple solutions with differeing levels of friction.
-
zinid
and this would require namespace bump?
-
zinid
or you want to avoid it thus the hassle?
-
dwd
zinid, Well, there's no hard and fast rules that Ge0rG's new rules are breaking, so it's not clear that it does.
-
Ge0rG
dwd: that might be true. It's well possible that the many threads on standards@ over the years all just were following the wrong approach to motivate server developers.
-
zinid
so bump the namespace and introduce all this new fancy stuff, what's the problem?
-
Ge0rG
Namespace bumps are one of the most inelegant ways to move forward.
-
zinid
Ge0rG, anyway, would be great if you formed a list of changes the server devs need to make, you can publish it anywhere in whatever format you like
-
Ge0rG
zinid: great idea. Is it sufficient to amend the PR?
-
Ge0rG
As the old rules are all MAY, it would technically suffice to introduce a new feature code.
-
dwd
zinid, https://github.com/xsf/xeps/pull/778 FYI
-
zinid
dwd, yeah, I briefly looked at it
-
zinid
Ge0rG, heh, everything is complicated
-
zinid
anyway, virtually impossible to understand anything from the diff 😀
-
zinid
> it contains payload elements typically used in IM wut?
-
zinid
> it is of type "error" and it was sent in response to a &MESSAGE; that was eligible for carbons delivery this one I will not implement, because tracking responses in clustering is _hard_
-
Ge0rG
Weasel words!
-
Ge0rG
zinid: can't you just forward _all_ error messages?
-
dwd
zinid, Possible if the error includes the original.
-
dwd
Ge0rG, Is that... Good?
-
Ge0rG
dwd: does it ever, in reality?
-
Ge0rG
dwd: it's better than not, in IM
-
dwd
Ge0rG, Sometimes. But it really does vary a lot, even within implementations.
-
zinid
dwd, a better solution would be attaching some "route state" to stanzas, but XMPP doesn't allow this
-
Ge0rG
Except that error generation is broken with some 0198 implementations.
-
zinid
SIP has Record-Route header for this
-
Ge0rG
zinid: IM-NG was supposed to solve that
-
zinid
Ge0rG, what? attaching routing states?
-
zinid
to where?
-
zinid
resource, lmao? 😀
-
Ge0rG
But I suppose it doesn't properly cover error responses.
-
Ge0rG
If you send a message to bare and receive an error from full, what does it even mean?
-
zinid
I don't know
-
Ge0rG
dwd: do you see problems with carbon copying all message errors?
-
dwd
Ge0rG, A bit, yes. I wonder if the right approach would be to manage the state elsewhere, if that's the aim.
-
dwd
Ge0rG, The intent is to ascertain which messages are in what state - so if another client sends a message and that gets bounced, we want to have all clients aware of both the original message and the fact it failed, right?
-
zinid
Ge0rG, ah, all those are MAYs and SHOULDs, I'm okay then 😀
-
dwd
zinid, You know SHOULDs aren't actually optional, right?
-
zinid
dwd, I can always ask you, yeah
-
Ge0rG
dwd: exactly!
-
zinid
like, "hey Dave, is this SHOULD a MUST?"
-
Ge0rG
dwd: I could live with some MAM related hack, because this is all about synchronizing a chat history database
-
zinid
(mastodon approach)
-
dwd
Ge0rG, I wonder if these (like receipts, actually) - yeah, you're thinking the same thing.
-
dwd
zinid, If you have to ask, yes, the SHOULD is a MUST.
-
Ge0rG
dwd: I also want multi receipts
-
Ge0rG
zinid: are error messages stored in mam?
-
zinid
Ge0rG, no
-
Ge0rG
Why not?
-
dwd
Ge0rG, That's a similar thing, right?
-
zinid
Ge0rG, I don't know/
-
dwd
Ge0rG, Better off storing a flag or something, anyway, in MAM.
-
Ge0rG
dwd: yes, slightly related
-
Ge0rG
Let's use the existing wire format to synchronize a message history database
- zinid reading the mam code
-
zinid
https://github.com/processone/ejabberd/blob/master/src/mod_mam.erl#L703-L741
-
zinid
hell
-
zinid
seems like errors are stored
-
zinid
ah, no, first line actually 😀
-
zinid
let's just archive everything
-
Ge0rG
zinid [19:24]: > let's just archive everything Awesome idea! Just replay all the CSN changes on each login!
-
Zash
Maybe what MattJ said about doing CSN over presence instead is better
-
Ge0rG
Zash: yes. Do it! Now!
-
zinid
yeah, we are in the situation where we need a special semantics on what should be retained
-
Ge0rG
IM-NG!
-
zinid
how about jingle calls? anyone?
-
zinid
you want to know who called you
-
zinid
should we add jingle calls to 280?
-
Ge0rG
Yeah, just don't start ringing when receiving a call from mam
-
zinid
since we allow abstraction leakage anyways
-
zinid
Ge0rG, how to fork the jingle call?
-
Ge0rG
Do you jungle call a bare JID or a full JID? What if there are multiple capable devices?
-
zinid
Ge0rG, SIP!
-
Ge0rG
zinid: serious question
-
Zash
Ge0rG: Do what?
-
Ge0rG
Zash [19:34]: > Maybe what MattJ said about doing CSN over presence instead is better > Zash: yes. Do it! Now!
-
zinid
Ge0rG, I have actually the serious answer, don't you know my stance on Jingle yet? 😉
-
zinid
Jingle doesn't even have basic functionality like forking, which SIP had since day 1
-
Ge0rG
zinid: what about this: Carbon copy each message payload for which a Carbons-enabled client advertises support.
-
zinid
each message payload?
-
zinid
and how to advertise it?
-
zinid
not sure I understand this
-
Ge0rG
If a client supports Carbons and 0184, send receipt Carbons. If it supports jingle, send call Carbons!
-
Zash
Ge0rG: Is there a map of features to xmlns?
-
zinid
Zash, carbons#foo?
-
Ge0rG
Zash: most features carry a namespace
-
Zash
Features (in disco#info) are not the same as xmlns
-
zinid
Ge0rG, so the server should inspect the cached disco response? Never liked the idea since there are races
-
Ge0rG
Zash [19:47]: > Features (in disco#info) are not the same as xmlns One of the bigger design failures of xmpp
-
Ge0rG
We had that in the context of MAM I think
-
Zash
Ge0rG: Useful in case there are more than one feature per spec
-
Ge0rG
zinid: do you want to get an explicit list of namespaces in Carbons enable iq?
-
Ge0rG
Zash: those should be suffixes to the xmlns
-
zinid
Ge0rG, not sure... the server must understand them all, right?
-
Ge0rG
zinid: can't it just make a set of all namespaces contained in the message?
-
zinid
Ge0rG, probably, but what about errors?
-
zinid
I mean message type=error
-
Ge0rG
zinid: what about them?
-
zinid
Ge0rG, how to know a client wants to receive them?
-
zinid
or is it supposed to be by default?
-
Ge0rG
Yes, by default. Unless you can track the original and determine whether it was copied
-
zinid
all solutions are ugly as hell 🙂
-
Ge0rG
zinid: is there a way to make an elegant solution by fixing other places?
-
zinid
I don't have any solution
- daniel has joined
-
zinid
btw, SIP requires in every document to specify forking rules for new messages
-
Ge0rG
That's not bad.
-
Ge0rG
We could require error messages to contain the original type, from and to.
-
zinid
well, that's maybe not a requirement, but I frequently saw "Forking" section here in there in SIP RFCs
-
Ge0rG
That doesn't solve 0184 of course. But it helps a little.
-
Ge0rG
And it will be sufficient with IM-NG
-
zinid
you see, as a server dev I see very little problems with carbons, so I don't think I'm competent enough in the carbons "problem"
-
zinid
I can only say what is hard or easy to implement in the server
-
zinid
which boils down "shared state" is evil
-
Zash
I'm more concerned about unclear rules and different sets of people having different requirements that are not written down anywhere
-
Zash
Like here, XEP-0280 says one thing. Ge0rG wants something else. Other client devs want yet something else.
-
zinid
even if you write them down not everyone will be happy
-
zinid
like some clients don't want to receive bounced CSN when a contact is offline
-
Ge0rG
I've written them down. Many times. Still waiting for client developers to comment.
-
zinid
(which is basic RFC requriement)
-
Ge0rG
zinid: bounced CSN = errors?
-
zinid
Ge0rG, yes, service-unavailable
-
Zash
In the words of https://tools.ietf.org/html/rfc7282 > Rough consensus is achieved when all issues are addressed, but not necessarily accommodated
-
zinid
Ge0rG, we even have mod_bounce_something for some customers! the very loud ones
-
Zash
Writing things down is a prerequisite of that
-
Ge0rG
zinid: what does it bounce?
-
dwd
Also, we should really look at the whole "Inbox" concept again. I think both ESL and Xabber have such a concept live, these days.
-
zinid
Ge0rG, everything that wasn't put in mam or offline in transit
-
zinid
actually it supresses the bouncing, I don't recall how the module is called exactly
-
Ge0rG
Yeah, not bounce anything that's in mam is a good thing!
-
Zash
dwd: Problem statement?
-
dwd
Zash, That'd be nice, yes.
-
zinid
Ge0rG, it's the opposite, when something is not not stored in mam/offline, it gets bounced with a service-unavailble (as per RFC), but the module supresses this behaviour and it just gets silently dropped
-
zinid
Ge0rG, the point is go figure what client devs want
-
Zash
I'd be careful with giving people what they want.
-
Zash
It's not always the same as what they need.
-
zinid
dwd, yeah, ESL introduced recently some inbox protocol
-
dwd
This had some stuff in it: https://twitter.com/miquido/status/1115270391176552450
-
dwd
Quite interesting, that article - really showed XMPP from an outsider's perspective.
-
zinid
Zash, you typically don't want to debate with customers, that's the problem
-
dwd
FWIW, Instagram also works using an inbox concept. It's pretty effective from a protocol standpoint, it just moves a lot of state management to the server (which is where we want it, I think).
-
Ge0rG
dwd: I had a "told you so" feeling for large parts of that post...
-
dwd
Ge0rG, Yeah, I can see that.
-
zinid
we want to put more state on the server?
-
Ge0rG
zinid: yes, smart server, dumb client.
-
Ge0rG
We've moved very far from that design principle.
-
zinid
Ge0rG, show me a dumb client (not to be confused with dumb client dev)
-
dwd
zinid, Yeah, it was one of the original design principles. The key here is that we don't really want clients acting as a heterogeneous distributed system for every operation...
-
dwd
zinid, Look on the plus side - it means us server devs get to show off how smart we are.
-
zinid
dwd, seems like this ends up with smart/complex servers and smart/complex clients
-
dwd
zinid, Yes, but in different ways.
-
zinid
that's why I always prefered SIP over XMPP
-
Ge0rG
To differentiate on features, as somebody once said...
-
zinid
web is also smart client dumb server btw
-
Ge0rG
zinid: web used to be the other way
-
Ge0rG
Some time in the middle
-
zinid
Ge0rG, all complexity in web is revolving around database management
-
zinid
while http servers are dumb as fuck
-
zinid
and that's why they are so efficient
-
Ge0rG
HTTP File servers.
-
Ge0rG
Have a look at rest api implementations
-
zinid
Ge0rG, the current trend is "serverless" (yeah, ugly term), where http server is a database front-end
-
Ge0rG
zinid: we've had that with odata. It was horrible.
-
dwd
zinid, Hmmm? You don't want to do database interaction within an AWS lambda. You want CPU-bound stuff there, not I/O-bound.
-
zinid
dwd, I don't understand the dichotomy, in XMPP you quickly faces I/O problems (database) and 50% of CPU is TLS, lol
-
zinid
and more state means more I/O bound
-
dwd
zinid, Meh. Non-blocking database access and hardware crypto accelerator, problem solved.
-
zinid
so easy, indeed 🙂
-
zinid
whatever, protocol wise (HTTP+JS+HTML+CSS) current web is smart client, if you disagree go write a browser and a http server, compare the results 😀
-
Zash
Writing a browser is impossible.
-
Zash
HTTP/2 haven't given me the impression of being simple tho
-
zinid
HTTP/2 is outdated
-
Zash
True
-
Zash
Gopher is where it's at!
-
zinid
oh, just arrived on Twitter, you will like it: > Google has a 20 year history of building completely open ecosystems
- dwd chokes
-
zinid
not sure if trolling
-
jonas’
what
-
zinid
that's target audience of twitter 🙂
-
Zash
People who like to yell into the void
-
zinid
isn't that any social network about? 🙂
-
zinid
unless you somehow get a million of subscribers
-
Zash
Yup
- lnj has left
-
zinid
GoogleNext19 is a wonderful stream of bullshit from Google
-
zinid
"we believe in an open cloud"
-
zinid
where open cloud means you run open source databases in the google cloud of course
- lnj has joined
- lnj has left
- lnj has joined
-
dwd
Presumably forks of open source databases they haven't released the changes to?
- lnj has left
- lnj has joined
-
zinid
it's all unclear from their dumb marketing presentations
-
zinid
> multiple clouds and hybrid clouds is the future
-
zinid
okay, enough for today 😀
-
Ge0rG
https://twitter.com/QuinnyPig/status/1115647859980943360 is the best commentary on the Google self promotion shitshow
-
zinid
Ge0rG: lol, yeah
-
zinid
> we will not compete with your business wow, why would they say that? businesses started to understand something is wrong with using Google?
-
moparisthebest
> "Thank you for coming, enjoy #GoogleNext19!" and the keynote is over as they begin the process of deprecating everything they just announced.
-
moparisthebest
nailed it!
- lnj has left
- debacle 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
- lnj has joined
- daniel has left
- daniel has joined
- moparisthebest has left
- lnj has left
- lnj has joined
- lnj has left
- lnj has joined
- lnj has left
- lnj has joined
- lnj has left
- lnj has joined
- debacle has joined
- lnj has left
- lnj has joined
- lnj has left
- debacle has left
- lnj has joined
- lnj has left
- lnj has joined
- lnj has left
- lnj has joined
- lnj has left
- lnj has joined
- debacle has joined
- daniel has left
- Zash has left
- Zash has joined
- moparisthebest has joined
- moparisthebest has left
- moparisthebest has joined
- moparisthebest has left
- moparisthebest has joined
- dos has left
- jonas’ has left
- jonas’ has joined
- Ge0rG has joined
- debacle has left
- zinid has joined
- daniel has joined
- lnj has left
- lnj has joined
- lnj has left
- lnj has joined
- lnj has left
- lnj has joined
- lnj has left
- debacle has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- debacle has left