XMPP Council - 2019-04-10

I should be back for Council today, but there's a chance of lateness or missing, depending on traffic etc.

'Tis time.

Good morning. :)

oh hai

The times they are a-changin'!

Come gather 'round, people.

dwd?

Ge0rG: Did you see https://github.com/xsf/xeps/pull/781 ?

Kev: sorry, no.

There seems to have been a bit of a lack of agenda.

We seem to be missing a Dave, so ...

1) Roll call

I'm here.

o/

here

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?

I think that’s true

This is the PR to try to address the metadata/content during LMC thing, as promised.

As it's a 30 second review, I suggest people just do that now, if they've not seen it yet.

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.

Kev, my problem with that proposal is that "metadata" isn’t really clearly defined

Kev: that essentially boils down to the philosophical question dwd brought up last time

what jonas’ said

Ge0rG: I'm not keen, as that drastically increases complexity everywhere.

What was this XEP saying that you shouldn’t bloat a stanza with many unrelated payloads?

Ge0rG, yeah, I don’t want to track multiple IDs to merge corrections, and neither will an archive want to

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.

Kev: I'm +0 for the sake of not dying on hills.

it makes me think we should’ve defined a metadata block in stanzas at the beginning

but I guess we can’t

and I think the text makes things clearer

so +1

jonas’: When we next get to 1999, we can consider that :D

Thanks.

Kev: due to the current GPS week rollover, we _are_ technically in 1999.

(one way out would be to spell out correctable payloads)

ha!

Ge0rG, but we’re also in 1979, aren’t we?

https://twitter.com/ChinaAvReview/status/1114802018919411712

Link Mauve ?

+1 as for the previous version.

Ta.

(xep-0308: and go ahead and patch all the other xeps with explicit mention when they can be corrected)

3) Date of next

(but yeah, current text is fine)

SBTSBC?

Kev, I think you wanted to start a discusison about compliance suites, didn’t you?

+1W WFM

+1wwfm

I do, I think it's AOBish, rather than a voting item, though.

There are many XEPs which I’d like to revisit to mention that they are metadata, and how it should behave. For FSE especially.

+1W wfm.

https://xmpp.org/extensions/xep-0226.html comes to mind

4) AOB. Anyone else got any before I do mine?

Zash, right, this one.

I don’t have any

Yeah, two of them

Me neither.

AOB-a: https://github.com/xsf/xeps/pull/779

AOB-b: https://github.com/xsf/xeps/pull/778

the former is for a Draft XEP so needs to be voted on, sooner or later.

The latter is essentially what I brought up back in 2017, but without the reliance on Hints.

Also I'm not sure whether we are going to hear back from the nominal author, so bringing this up before Council

I'm not ready to express opinions on either yet - can we schedule them as full items for next week?

AOB-a +1 for me.

Or we can reschedule.

I've waited for two years now, can't you see how urgent the 0280 issue is?

Ge0rG, would you want to become a shepherd for AOB-b?

*squint*

> BTW, I volunteer to take over 0280 authorship if the need arises.

Link Mauve: ^ from the PR

Great. :)

https://github.com/xsf/xeps/pull/779 is surely a five-minute review thing.

You'd think, yes.

But I'm not going to push anyone into anything, so +1W is fine with me.

I’m +1 on that one

I'm just struggling to decide on an opinion about making existing implementations non-compliant, which the MUC block surely does.

Kev, it doesn’t matter, because sending type="groupchat" to full jid is an error already

And that's a good reason for me to do a proper review, I suspect.

Unless you are responding to a MUC request with a PM receipt.

Which is also a possible way to do things.

Anyway, I think everyone else is +1 on 779, so we may as well treat that as item 2b rather than AOB.

And suggest we put 778 in for proper discussion next week.

I think that’s sane

Afternoon, sorry, meeting overrun.

And I'll on-list 779. ✏

oh, welcome dwd ✏

Welcome.

You're not taking my gavel ;D

AOB3, then. Compliance suites.

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

Kev, You're welcome to it.

small note re next meetings: I'm going to be gone on three of the May Council meetings

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.

Kev, I think that’s a very sensible idea

Kev: this is a great idea.

Kev, The general idea seems fine. But are these living documents XEPs?

Oh indeed, next week I am away during this meeting, I will be back the week after.

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.

Kev, excellent idea.

(I think they're Informational, rather than Standards-Track, at least)

they could easily be Informational XEPs in Active status, maintained by Council ✏

although arguably XEP-0001 explicitly states compliance suites-like things to be Standards Track ;) ✏

Indeed, but these aren't compliance suites :)

then again, if it isn’t about compliance but about a "what to implement" it’s not that

^5 again

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?

So a "how XMPP works now" and a "how we want XMPP to look in the future" documents? I approve.

"XMPP Core XEPs version X"

that works nicely with the badge system, too

jonas’: I propose X to be mapped to time periods of sufficient length.

i.e. years.

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.

Ge0rG, versions can easily be YYYYMM.x

jonas’: They can't, actually, given xep1.

XEP-0001 has some opinions about version numbers, but I think we can get an override from board for that ;)

One of the things I'm fairly keen we do is not have dates involved in this.

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.

Kev: what's your rationale for that?

Kev, not at all?

And for technical people, Conversations’s website does a much better work at that.

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.

Kev: does that argument have any merit?

And that leads us to trying to rush through new versions without (I think) due consideration.

And ISTM the cost of not having the date in the version is approximately zero.

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.

jonas’: If these are updated more often than every year, I'll be pleasantly surprised.

Can't we call it after animals? Seems to work well for Ubuntu.

I also point to XEP-0045 1.31.2

Kev: I think that the year is a much better indicator of up-to-date-ness than an arbitrary version number

dwd, no, with my editor hat on, I require version numbers to be numeric and totally ordered

as long as XEP-0001 permits me to require that

Ge0rG: I think my argument is that using versions to give an idea of up-to-dateness isn't helpful here.

Kev, but do you point to '45 1.13.2 for marketing purposes?

jonas’: No, for an example of a XEP with a daft number of revisions without the sky falling :)

I'd be happier with versions of XEPs if we could also reliably point to them, but I'm not entirely sure how.

point is, it looks weird to me, and it will look weird to folks outside the XSF when used for marketing

dwd: We could make a point of including the changelog fully in these XEPs, if we wanted.

I’d like to throw in that I started tagging things on github and I’m looking into automating that kind of stuff more

even though that might mean, in the long run, that I run my own infrastructure next to the XSF’s

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.

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.

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?

Kev, yes

I think what dwd says is good

Kev, indeed.

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

Kev, Yes, but it'd be nice to have some idea of what constitutes success.

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?

Kev, If only to determine that we have failed once more.

Kev, Sounds sensible.

Kev, do we have long-term agenda planning techniques? ;)

(other than open PRs against xeps)

jonas’: I call it Dave.

AOAOB?

not from me

I think that with our current tooling, the current form of CS is the least failed way to do it.

Thanks all.

Kev, Thanks for stepping up there.

dwd: You've got two votes from today, I believe, to on-list (and I've got one).

I'm actually unconvinced of everything proposed above except for the general idea.

Ge0rG, Was there more than a general idea?

And that general idea can easily be mapped onto yearly CS XEPs.

...provided somebody does the actual work.

Ge0rG, Aye, there's the rub.

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

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

Ge0rG, Ah. So *some* of that neatly fits onto Compliance Suites.

Ge0rG, Mostly the first document.

dwd: yes.

Now would be a good time to start a proto-CS-2020, or maybe a proto-future-CS

Ge0rG, The key change is a single mutating document instead of multiple documents.

dwd: and due to tooling reasons, I actually object to _that_ change.

why?

Because XEP versioning is an ugly business.

Ge0rG, And one I noted.

I find non-obvious XEP numbers for CS worse

we can fix the versioning

BCP-0001

We don't have good link-ability to old versions, and we don't have good diff views.

the diff views are an argument, but that doesn’t get fixed with separate documents at all

can has xep-2019.xml

jonas’: touché

if anything, it is worse, because in the future, we might get diff tools back, but those will work between versions, not xeps

Ge0rG, Link-ability would be interesting. We could link to old versions via the changelog, too.

and link-ability to old versions can be fixed, too

for those which are built, that is

dwd: the changelog is just a muddy reflection

that’s the authors fault though

or maybe the editors, but the author can do something about it

so let's mandate *proper* changelog maintenance for Compliance Suites, whatever "proper" means.

If we have link-ability to past versions, we could have the Compliance Badges link to a specific (currently latest) version of the XEP

and change the year each year.

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.

Ge0rG, So #778. What's the rationale here?

For the CS Date, we can of cours ejust change the title on the new version.

dwd: the overall high-level rationale, the specific rationale of individual commits or ... ?

Ge0rG, High level, to begin with.

Have a persistent item at Summit?

dwd: Carbons have many broken corner cases

Zash, Hush now.

dwd: we had a very long time to fix the weasel-words out of the XEP by collecting experience. Mostly nobody cared about it.

Ge0rG, Right, but is that because it doesn't matter?

dwd? :(

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.

Zash, It's hardly the only repetitive topic at Summits.

dwd: is that a trick question?

Ge0rG, No, I'm trying to figure out the rationale, and thereby decide on the best way to progress this work.

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.

Ge0rG, To what end?

dwd: to fix the user experience

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.

Also improvements to the rules to make them more consistent

Ge0rG, OK, this seems more useful. So what happens if a server doesn't follow these rules?

like carbons of errors.

dwd: the corner cases remain unfixed

Ge0rG, Yes, but at a high level?

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?

dwd: I'm not sure where you are aiming

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.

Hm. https://xmpp.org/extensions/xep-0001.xml

dwd: yeah, not feeling offended, just not sure how to answer

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?

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.

dwd: thus clients typically don't rely on anything working

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.

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

dwd: now you are talking!

Ge0rG, I'm also aware that server implementations tend to adopt things faster if they can advertise their support.

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

Also 0280 as it is now is a VERY BAD XEP.

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.

dwd: I'm still not sure it makes _technical_ sense to advertise some kind of support level for 0280 rules

Ge0rG, I honestly don't know. For diagnostics, it probably does.

Ge0rG, But I'm not sure that clients would alter behaviour.

I wouldn't in mine.

And I'm not often looking into disco#info when diagnosing things.

dwd: also what would happen if the rules get extended? namespace-bump them? Have all versions that are still complied to in disco#info?

Ge0rG, The latter I imagine.

Ge0rG, But also, I think working on it in a separate XEP might prove more politically viable.

I'm not opposing, just wondering if it actually has value.

dwd: see above. > Also 0280 as it is now is a VERY BAD XEP.

Well, you'd eventually have a patch which removes the rules from '280 and points at ${NEWXEP}

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.

(insert Brexit pun)

dwd: how is that formally different from having the rules in 0280 and not having another XEP?

Ge0rG, It isn't, but I see an easier path to get there from here.

do you think council will oppose that change?

Ge0rG, But understand: I'm only throwing ideas out there.

dwd: and once we are there, we merge the two XEPs into one?

dwd: is there some special political meaning to the number 0280, that I don't know about because I'm too young?

jonas’, WHich change? The rules update? Probably less likely to cause problems if the new XEP is mature and well-supported.

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.

dwd: "simpler" in the sense of the XSF Council process?

Ge0rG, I was thinking community more than Council.

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?

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.

dwd: if I didn't need to bully server implementors, they'd have the Good Rules by now.

(making a PR against 0280 was actually my attempt to bully server implementors)

Ge0rG, Yeah. I think a new XEP might be more persuasive than bullying.

Routing 2.0?

Zash, I'm not mad keen on fork-lifts.

XMPP 2.0 !

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.

dwd: Some videos of omniwheel forklifts ough to change your mind :)

(incidentally, the 0184 PR could have happened half a year ago if it wasn't for some curse words in the XML)

also I'm not sure how much a SHOULD is a fork-lift.

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.

(which is also why it took almost two years for me to re-issue #434)

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

wut, 280 again?

is it meeting now?

zinid: meeting is over, context is https://github.com/xsf/xeps/pull/778

meeting was at 15:00 UTC?

whatever

zinid: https://logs.xmpp.org/council/2019-04-10#2019-04-10-611d9881cd1a08ca

zinid, The '280 thing is basically a tradition now.

meh

booooring

zinid, Do you happen to know what carbon rules ejabberd implements?

dwd, no 🙂

I'm not the author and don't have any desire to touch the code with 19m pole

it is better not to touch the routing in the server, it always ends up with something borked 😀

Yeah it is always the weirdest, hariest code in any server.

No doubt Zash will tell me that Prosody's routing code is perfect about now. :-)

dwd: Yes, it's perfect, so I don't wanna touch it ever again! /me hides

Zash: LIES!

Ge0rG, No, I believe he never wants to touch it again.

Carbons and MAM are in stable releases now, changing anything will probably be massively painful

do we need to change something? From the PR it's not very clear, looks like just wording improvement

zinid: depends on what you do.

I know that prosody lacks with 0184 payloads of type normal and on error responses.

I think errors is a definite change from previous recommendations, isn't it?

Prosody does carbons with (type=chat or (type=normal and has <body>))

modulo hints

Previous recommendations were all MAY, but they contained error handling

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

Ge0rG, Ah, indeed. But not '184.

dwd: CSN and Receipts are new, yes.

Unless your receipts are of type=chat, in which case they magically work.

Ge0rG, So basically if we adopt this text, we're declaring all existing implementations to be non-conformant?

But that in itself is kind of a violation of 0184

dwd: you make it sound negative.

> CSN and Receipts are new, yes abstract leakage again

*abstraction

zinid: that kind of leakage is also happening in LMC currently.

well, maybe, that's client devs problems, I don't care 😀

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.

Ge0rG, I think I like the changes. Just trying to figure out the most effective way of getting them deployed.

But I'm more interested in moving xmpp forward than in fighting process debates.

(at least in this specific case)

Ge0rG, Not so much process as trying to get the server devs to actually implement.

dwd: I'm not sure there is an elegant solution to *that* problem.

Ge0rG, No, but there may be multiple solutions with differeing levels of friction.

and this would require namespace bump?

or you want to avoid it thus the hassle?

zinid, Well, there's no hard and fast rules that Ge0rG's new rules are breaking, so it's not clear that it does.

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.

so bump the namespace and introduce all this new fancy stuff, what's the problem?

Namespace bumps are one of the most inelegant ways to move forward.

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

zinid: great idea. Is it sufficient to amend the PR?

As the old rules are all MAY, it would technically suffice to introduce a new feature code.

zinid, https://github.com/xsf/xeps/pull/778 FYI

dwd, yeah, I briefly looked at it

Ge0rG, heh, everything is complicated

anyway, virtually impossible to understand anything from the diff 😀

> it contains payload elements typically used in IM wut?

> 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_

Weasel words!

zinid: can't you just forward _all_ error messages?

zinid, Possible if the error includes the original.

Ge0rG, Is that... Good?

dwd: does it ever, in reality?

dwd: it's better than not, in IM

Ge0rG, Sometimes. But it really does vary a lot, even within implementations.

dwd, a better solution would be attaching some "route state" to stanzas, but XMPP doesn't allow this

Except that error generation is broken with some 0198 implementations.

SIP has Record-Route header for this

zinid: IM-NG was supposed to solve that

Ge0rG, what? attaching routing states?

to where?

resource, lmao? 😀

But I suppose it doesn't properly cover error responses.

If you send a message to bare and receive an error from full, what does it even mean?

I don't know

dwd: do you see problems with carbon copying all message errors?

Ge0rG, A bit, yes. I wonder if the right approach would be to manage the state elsewhere, if that's the aim.

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?

Ge0rG, ah, all those are MAYs and SHOULDs, I'm okay then 😀

zinid, You know SHOULDs aren't actually optional, right?

dwd, I can always ask you, yeah

dwd: exactly!

like, "hey Dave, is this SHOULD a MUST?"

dwd: I could live with some MAM related hack, because this is all about synchronizing a chat history database

(mastodon approach)

Ge0rG, I wonder if these (like receipts, actually) - yeah, you're thinking the same thing.

zinid, If you have to ask, yes, the SHOULD is a MUST.

dwd: I also want multi receipts

zinid: are error messages stored in mam?

Ge0rG, no

Why not?

Ge0rG, That's a similar thing, right?

Ge0rG, I don't know/

Ge0rG, Better off storing a flag or something, anyway, in MAM.

dwd: yes, slightly related

Let's use the existing wire format to synchronize a message history database

https://github.com/processone/ejabberd/blob/master/src/mod_mam.erl#L703-L741

hell

seems like errors are stored

ah, no, first line actually 😀

let's just archive everything

zinid [19:24]: > let's just archive everything Awesome idea! Just replay all the CSN changes on each login!

Maybe what MattJ said about doing CSN over presence instead is better

Zash: yes. Do it! Now!

yeah, we are in the situation where we need a special semantics on what should be retained

IM-NG!

how about jingle calls? anyone?

you want to know who called you

should we add jingle calls to 280?

Yeah, just don't start ringing when receiving a call from mam

since we allow abstraction leakage anyways

Ge0rG, how to fork the jingle call?

Do you jungle call a bare JID or a full JID? What if there are multiple capable devices?

Ge0rG, SIP!

zinid: serious question

Ge0rG: Do what?

Zash [19:34]: > Maybe what MattJ said about doing CSN over presence instead is better > Zash: yes. Do it! Now!

Ge0rG, I have actually the serious answer, don't you know my stance on Jingle yet? 😉

Jingle doesn't even have basic functionality like forking, which SIP had since day 1

zinid: what about this: Carbon copy each message payload for which a Carbons-enabled client advertises support.

each message payload?

and how to advertise it?

not sure I understand this

If a client supports Carbons and 0184, send receipt Carbons. If it supports jingle, send call Carbons!

Ge0rG: Is there a map of features to xmlns?

Zash, carbons#foo?

Zash: most features carry a namespace

Features (in disco#info) are not the same as xmlns

Ge0rG, so the server should inspect the cached disco response? Never liked the idea since there are races

Zash [19:47]: > Features (in disco#info) are not the same as xmlns One of the bigger design failures of xmpp

We had that in the context of MAM I think

Ge0rG: Useful in case there are more than one feature per spec

zinid: do you want to get an explicit list of namespaces in Carbons enable iq?

Zash: those should be suffixes to the xmlns

Ge0rG, not sure... the server must understand them all, right?

zinid: can't it just make a set of all namespaces contained in the message?

Ge0rG, probably, but what about errors?

I mean message type=error

zinid: what about them?

Ge0rG, how to know a client wants to receive them?

or is it supposed to be by default?

Yes, by default. Unless you can track the original and determine whether it was copied

all solutions are ugly as hell 🙂

zinid: is there a way to make an elegant solution by fixing other places?

I don't have any solution

btw, SIP requires in every document to specify forking rules for new messages

That's not bad.

We could require error messages to contain the original type, from and to.

well, that's maybe not a requirement, but I frequently saw "Forking" section here in there in SIP RFCs

That doesn't solve 0184 of course. But it helps a little.

And it will be sufficient with IM-NG

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"

I can only say what is hard or easy to implement in the server

which boils down "shared state" is evil

I'm more concerned about unclear rules and different sets of people having different requirements that are not written down anywhere

Like here, XEP-0280 says one thing. Ge0rG wants something else. Other client devs want yet something else.

even if you write them down not everyone will be happy

like some clients don't want to receive bounced CSN when a contact is offline

I've written them down. Many times. Still waiting for client developers to comment.

(which is basic RFC requriement)

zinid: bounced CSN = errors?

Ge0rG, yes, service-unavailable

In the words of https://tools.ietf.org/html/rfc7282 > Rough consensus is achieved when all issues are addressed, but not necessarily accommodated

Ge0rG, we even have mod_bounce_something for some customers! the very loud ones

Writing things down is a prerequisite of that

zinid: what does it bounce?

Also, we should really look at the whole "Inbox" concept again. I think both ESL and Xabber have such a concept live, these days.

Ge0rG, everything that wasn't put in mam or offline in transit

actually it supresses the bouncing, I don't recall how the module is called exactly

Yeah, not bounce anything that's in mam is a good thing!

dwd: Problem statement?

Zash, That'd be nice, yes.

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

Ge0rG, the point is go figure what client devs want

I'd be careful with giving people what they want.

It's not always the same as what they need.

dwd, yeah, ESL introduced recently some inbox protocol

This had some stuff in it: https://twitter.com/miquido/status/1115270391176552450

Quite interesting, that article - really showed XMPP from an outsider's perspective.

Zash, you typically don't want to debate with customers, that's the problem

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

dwd: I had a "told you so" feeling for large parts of that post...

Ge0rG, Yeah, I can see that.

we want to put more state on the server?

zinid: yes, smart server, dumb client.

We've moved very far from that design principle.

Ge0rG, show me a dumb client (not to be confused with dumb client dev)

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

zinid, Look on the plus side - it means us server devs get to show off how smart we are.

dwd, seems like this ends up with smart/complex servers and smart/complex clients

zinid, Yes, but in different ways.

that's why I always prefered SIP over XMPP

To differentiate on features, as somebody once said...

web is also smart client dumb server btw

zinid: web used to be the other way

Some time in the middle

Ge0rG, all complexity in web is revolving around database management

while http servers are dumb as fuck

and that's why they are so efficient

HTTP File servers.

Have a look at rest api implementations

Ge0rG, the current trend is "serverless" (yeah, ugly term), where http server is a database front-end

zinid: we've had that with odata. It was horrible.

zinid, Hmmm? You don't want to do database interaction within an AWS lambda. You want CPU-bound stuff there, not I/O-bound.

dwd, I don't understand the dichotomy, in XMPP you quickly faces I/O problems (database) and 50% of CPU is TLS, lol

and more state means more I/O bound

zinid, Meh. Non-blocking database access and hardware crypto accelerator, problem solved.

so easy, indeed 🙂

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 😀

Writing a browser is impossible.

HTTP/2 haven't given me the impression of being simple tho

HTTP/2 is outdated

True

Gopher is where it's at!

oh, just arrived on Twitter, you will like it: > Google has a 20 year history of building completely open ecosystems

not sure if trolling

what

that's target audience of twitter 🙂

People who like to yell into the void

isn't that any social network about? 🙂

unless you somehow get a million of subscribers

Yup

GoogleNext19 is a wonderful stream of bullshit from Google

"we believe in an open cloud"

where open cloud means you run open source databases in the google cloud of course

Presumably forks of open source databases they haven't released the changes to?

it's all unclear from their dumb marketing presentations

> multiple clouds and hybrid clouds is the future

okay, enough for today 😀

https://twitter.com/QuinnyPig/status/1115647859980943360 is the best commentary on the Google self promotion shitshow

Ge0rG: lol, yeah

> we will not compete with your business wow, why would they say that? businesses started to understand something is wrong with using Google?

> "Thank you for coming, enjoy #GoogleNext19!" and the keynote is over as they begin the process of deprecating everything they just announced.

nailed it!