XMPP Council - 2021-04-14

1) Roll Call

Here

Cheese today please.

cheeese .... sounds great

good morning

Hi

full house \o/

2) Agenda Bashing

dwd: no cheese for you, https://www.bleepingcomputer.com/news/security/dutch-supermarkets-run-out-of-cheese-after-ransomware-attack/

I'd like to AOB my 0280 LC

OK

I’m hungry now

so expect that I rush through the meeting :P

Ge0rG, I am not Dutch though, so I still get cheese I think.

(only to sit here waiting until dinnertime...)

dwd: something something global logistics

3) Editor’s Update

we now have BibLaTeX, citations in XEPs, so that’s nice

Ge0rG, Brexit means Brexit, we have no global logistics anymore anyway.

4) Items for Voting

jonas’: great!

none I think?

yep, none

5) Pending Votes

dwd, any update on the '13 deprecation from you?

should we construct an elaborate algorithm for the pre-conditions on which to +1 either 0280 or 0313?

Yes, I'll vote +1, acknowledging that there are bits that are useful and not present in Simple Blocking and Invisibility.

dwd, thanks!

now for '280 and '313, a bunch of people (including me) are pending on those

Sam: you need to fix the breakage of 0013 first :P

Ge0rG: we should talk afterwards in xsf@ about that

Still no server developer feedback on urn:xmpp:carbons:rules:0

So after I dashed off last week, I see Ge0rG suggested having strict rules on what gets archived in '313. Equally, these exist in '280 and there is, as Ge0rG says, no server dev feedback on these.

Is Zash the only server developer in the XSF?

I've probably written that feedback in some Prosody issue comment.

He's not even the only server dev on Council...

Should those rules really be enshrined into '280 and '313?

They will inevitably need to be updated to account for new payloads in the future.

dwd: I'd love to hear feedback on urn:xmpp:carbons:rules:0 from *all* server developers, but *especially* from those on Council

Zash: that's why they got their own namespace version that can be bumped.

That's actually an outcome of the last LC discussion that I consider as elegant in retrospect

as elegant as is possible with the hack that Carbons is.

Apply the same thing with '313 then?

So we could fish them out into their own XEP, advance '280 and '313, and have ${NEW_XEP} reference the two and add the strict rules in?

+ the cloud notify stuff

dwd: I'm sure we could fish them out after advancing 0280

But I suspect there's a core of people who would be unhappy with Carbons advancing without them.

> It's unclear to me what messages would have IM payloads but are not be type = chat|normal|groupchat. We don't want to carbon type=groupchat that happens to have chatstates for example. from https://issues.prosody.im/1486

And I'm not going to advance 0313 until these rules are written down *somewhere*

I also don’t see an issue with breaking them out of carbons as they’re "scoped" with their own namespace already

I'm not sure they are going to have the same rules ✏

daniel, nobody said that the rules XEP has to define the same rules for both

Cloud? Who said cloud?

sorry, clown notify

a.k.a. GSPEWS (Global Surprise Party Early Warning System) ✏

jonas’: bringing in clowns is the opposite of your stated goal of rushing through this meeting. ✏

I didn’t say it was a goal, I said it would happen ;P

Bringing in clowns is what the AGM is for, anyway.

I'm not convinced that the processing rules for all these things need to be identical.

and I think that having a central place to look at routing rules in the pre-2.0 world is a good thing™

I'm convinced they must not be identical.

Doesn't even make sense in some cases, as they apply to different subsets of stanzas.

There will be overlap tho

And subtle differences

But we are not going to know until somebody writes them down

User MAM vs MUC MAM for example

which kind of requires server developer feedback.

What kind of feedback tho?

I can repeat what Prosody (trunk) does, which I think is sensible at this time.

Zash: can you repeat it in a way that's clearly understandable in the context of XEP-0280, instead of in the context of #1486?

...on list

Presumably server devs don't care about the rules. It's the client devs who should know what messages they want under which circumstances

Maybe the clients should upload a firewall script to the server? 😀

My limited experience so far of clients trying to say what they want stored is that it’s a disaster :)

daniel, I'm not sure that's true either. There are different considerations, perhaps, but both sides very much care.

daniel: don't remind me of the nights I've spent debugging corner cases of "that message didn't arrive on this device - why?"

So what’s our way forward here?

Is this another instance of "the problem is too complex to tackle with our resources"?

contractually oblige server developers to respond to my emails?

Well, my view is that "What should servers store" is actually a different issue to "how should clients obtain what is stored".

Ge0rG, will you pay them? ;)

XEP-0313 concentrates primarily on the latter, and seems to be stable and worthwhile.

dwd, not wrong, but we need someone to write down "what should servers store" in a document

jonas’, But does it need to be this document?

jonas’, And, indeed, now?

dwd: yes and yes.

not having this information inside of 0280 has caused many years of frustration, incompatibility and people missing some messages.

dwd, I don’t think it needs to be in '313

Ge0rG, no, that was "not having the information anywhere" as opposed to "not having the information in '280"

Store *everything* and deliver a subset in queries is also a thing you could do

Zash: but then we need a definition of what subset to deliver.

Some kind of firewall rules you upload...

Ge0rG, Do you think no confusion and frustration has been generated by having Carbons, MAM, etc in Experimental for so long?

(Not serious, actually a Matrix reference)

But deep-stanza matching is something MAM could use.

dwd: my point is that the knowledge is *there*, but not in a document

not writing it down now will just prolong the pain

and I consider "what kind of information will this query return" as a very important part of a protocol.

Ge0rG, but you also think that the rules need to be adapted

I think having that in a separate (maybe Informational?) document makes more sense under that consideration

for either

jonas’: ..by servers?

Each new XEP may need to declare how it should affect carbons/mam/etc and then we summarize that somewhere?

"Routing Considerations"

Zash: not disagreeing in principle.

Except, we need to just make routing an explicit part of... routing.

And we are 70% there with message type and bare/full JID

Ok, I don’t see this going anywhere

IM-NG!

we’ve gone full circle again

😀

So, shall I translate mod_carbons into email and send that?

if it makes Ge0rG happy

Zash: please translate it into a delta on 0280.

with rationale

I am +1 on '313 and '280 based on running code and it works good enough

when does 313 expire?

Ge0rG, it did

oh, the vote

next week I think

we can write down rules in a separate document, and any future changes to such rules should go into a separate "legacy routing rules" document

which we can use as a reference to build a better IM-NG world

okay, I'm going to sit on '313 for another week then, hoping that somebody responds to my LC mail

okay then

My other AOB would be Hints, actually.

everyone cast your votes on-list please

moving on

I still want to do a sweep of previous LCs, but haven't gotten to that yet

6) Date of Next

+1w wfm

+1W WFM

+1w wfm

+1w WfM

ok then

7) AOB

everyone OK if we overrun by 15min or so?

👍

+1

no message is a good message

I can't speak for everyone, but OK.

I'm low on energy

Ge0rG, go ahead

Zash, feel free to say "cancel" at any point and we’ll move it to next week… we can c&p the text into the next meeting :)

Alright, re 0280: bridge carbons probably should go into its own XEP, so doesn't block advancement.

XEP-0334 Message Hints is in a sad state, but still included in 0280

Modern bridge XEP? Why not

Should we get rid of Hints altogether?

Can we realistically, without bumping Carbons?

And can we undo the "stripping of <private/>" without bumping Carbons?

I highly doubt the latter

Well, it's not Draft yet.

Would it break anything?

Ge0rG, getting rid of Hints the concept or Hints the document?

jonas’: the use of Hints in other XEPs

again, Hints the concept or Hints the document?

I think that the concept makes sense, in the context of the respective XEP that's actually affected by them

A hint was always just a hint right, not a requirement? If we add a <do-not-carbon-this/> to carbons, we don't need a namespace bump because it would be ignored by things that don't support it and maybe ignored or maybe not by things that do. No backwards compatibility issues.

getting rid of the hints XML element, not without aborting the LC period and letting the document sit for another $periodOfTestingTime at the very least ✏

I think.

Sam, no, carbons is strict about <private/>

Does anybody remember why Hints the XEP got into a deadlock?

Ge0rG, roughly what you say

("should be in the respective documents")

IIRC

Ge0rG, so I don’t see a problem with using the XML from the Hints XEP and dropping it

because compatibility

I don’t see carbons as a thing which must be 100%

jonas’: that's also my memory, but maybe dwd or Kev have a better one

we need to get IM-NG 100% right, but we don’t have the concept of hints there so far and we might not even need it

jonas’: dropping what?

Ge0rG, the Hints document

I thought that a previous Council had effectively killed Hints?

I think I -1ed it last time hints came up for advancement. My rationale IIRC was because it would never be able to be finalized because the scope was so vague. We'd want more hints, or want to change one hint that doesn't affect another but couldn't without a namespace bump for both, etc. it just felt like a "util" package that would end up being full of cruft that people stuck in when they weren't sure where else to put it.

Is it just me or were Hints completely removed from 0313

I vaguely thought daniel was a key proponent of killing them entirely.

Ge0rG, that seems realistic

> I vaguely thought daniel was a key proponent of killing them entirely. I don't remember that

Sam: thanks!

So does it make sense to keep hints, that have their semantics defined inside of 0313 and/or 0280 and/or IM-NG, under a common namespace?

daniel, I misremebered - clearly it was Sam.

Ge0rG, not necessarily.

but if we already have them… we should keep them

So does it make sense to keep the `<no-copy xmlns='urn:xmpp:hints'/>` XML inside of Carbons?

not change their namespace/localname pair for whatever sake

yes.

IIRC, there was no version of Carbons that required clients to add <no-copy> without also requiring <private>

But now we have the paradoxical situation that a receiving server will strip <private> and retain <no-copy>

Ge0rG, again, what are you trying to fix here?

is there any practical issue?

excessive XML bloat

also consistency with my next AOB point

I think the better place to work on that is IM-NG

so the answer to my question is "just leave it as is"

yes.

from my side anyway

is that a rational decision or motivated by hunger? ;)

good question!

Cheese.

but I don’t think the time we’ve sunk into this is worth the gain

considering that Carbons is only an intermediate solution

jonas’: those keep running the longest.

A temporary hack? Oh no!

Ge0rG, they do, indeed, nevertheless... piling another layer of compat on it which isn’t solving any real UX problem is not going to make it better ;)

and thinking about the implications of changing carbons at this stage makes my head hurt

Let me rephrase my question: I would like to remove <no-copy> from 0280 and remove the "receiving server SHOULD strip <private>" part. Is there anybody in Council who thinks either would warrant a namespace bump?

yes

In theory, yes. In practice, maybe not.

What breaks if we do that?

We are still in Experimental ;)

Ge0rG, Namespace version was introduced *for* experimental...

Ge0rG, we can delay the advancement of Carbons for another half a year for no real gain, yes

jonas’: I don't see what would break by it.

I'm not even sure if servers are following that SHOULD.

Ge0rG, I don’t either, but I lack domain knowledge here

Oh, it's a SHOULD?

okay, we’ve overrun the overrun

jonas’: maybe we should postpone that to the next week's AOB then

I think everyone has made their opinion clear so far, but we can go on next week

8) Ite Meeting Est

Thanks everyone, Thanks Tedd (I hope you’re ok!)

jonas’, Thanks. Go enjoy food.

jonas’: thanks very much!

What time is it? Cheese time!

Gluasch time!

On to more important decisions, such as what to do with the cheese

put it on bread and then put both in the oven until the cheese has melted

Will I have enough energy to make food to replenish my energy? Tune in next week to find out!

I don't have any bread 🙁

put it in a pan and fry it until the lower side gets slightly hard

I could make bread, but that would take hours

crispy molten cheese!

That doesn't sound like a treatment worthy of Wästerbotten cheese!

what even is that?

Magic

It turns anything into delicious luxury food.

Cheap frozen pizza? Apply västerbottensost and it's the most delicious pizza ever!

Can only be produced in tiny village in the middle of nowhere in northern sweden. Nobody knows why. Magic!

FWIW, I think a client telling the remote server how to process a stanza, which changes which of the recipients clients get it, but stripping the instuction out so the recipient never knows is harmful.

Why was it done anyway?

Kev: I fully agree

No idea why Kev is discussing protocl stuff in the cheese channel. I'd expect a solid mention of Welsh Rabbit by now.

I live to surprise.

Or something.

I need to stop working already and drive to the local dairy to get some fresh milk and cheese.

It puts the cheese in the basket or else