XMPP Council - 2021-09-08

Oh, it's almost time, and I'm so excited to be the standin-chair today!

It's Meeting Time!

1) Roll Call

Hi

Hello

Jonas is excused.

Do we have a dwd?

Sorry, yes!

Awesome!

2) Agenda Bashing

It's not my fault, so feel free to fire at will!

Surprise MAM vote!

It's on the agenda, so not so much of a surprise.

Maybe surprise MAM PR?

I suggest we can discuss the PR ahead of voting.

3) Editor’s Update - Last Call for XEP-0459, Compliance Suites 2022

I'm not sure if the author of CS'22 actually asked for the LC or if it was warranted by the remaining time for Old Council.

But thank you very much to jonas’ the Editor.

4) Items for voting

4a) PR#1064: XEP-0227: New revision 1.1 URL: https://github.com/xsf/xeps/pull/1064

+1

+1

+1

+1

I'm sure that jonas’ will on-list.

4b) Advance XEP-0313 to Stable as-is

There was a surprise PR update to this in https://github.com/xsf/xeps/pull/1104

So I suggest to instead vote on: - accept PR#1104 - include CVE-2019-16235 and CVE-2020-26547 blocks from 0280 - accept the resulting XEP as Stable

Yeah, so wait for that PR to go in, and the security considerations you wanted?

Well, we can't really vote on anything given that.

dwd: that PR is an author update based on LC feedback.

and the CVE inclusion is viewed as Editorial.

Oh, is it? Either way, I'd like to vote once we have those merged.

> Oh, is it? Either way, I'd like to vote once we have those merged. +1

I'm not sure that writing a load of security considerations really can be Editorial.

Okay, so we wait for jonas’-the-Editor to push the merge button and to perform the respective boilerplate tasks.

dwd: the security considerations are LC feeback ;)

Yes... But that doesn't make them editorial.

dwd: no

the question is: do we need another LC for feedback integrated from a previous LC?

I think not

If not, then the next step would be to apply the PR and to vote for advancement into Stable.

Yes, sounds right to me.

Or to vote for advancement based on the pre-condition of the PR being applied.

As in, no need for another LC.

But we can't vote on a XEP not in front of us.

That's a tough point indeed.

Technically we have in the past I think

But there is absolutely no rush

So let's have the Editor merge the PR and then we will re-elect.

daniel: I'm actually not sure why there is sudden activity on this XEP after half a year of silence, but I'm very glad that it *is* happening.

That said, I still have a long list of issues that weren't addressed in this PR, given that they were not blocking the advancement.

5) Pending Votes None.

Good job, everyone :)

6) Date of Next

+1W WFM

+1w wfm

+1WFM2

Zash?

+1w wfm

Awesome. Let's hope that jonas’ comes back well after the party.

7) AOB

Non here

daniel, Bit French, that.

dwd: even if PR#1104 fixes the blockers for me, I'd still love to see some more discussion of the usefulness and treatment of type=groupchat in user's MAM. It would be great if you could follow-up on list.

Yes. And I will.

Tldr It makes no sense with plain xep45 but can be very useful with muc light, muc/sub and stuff?

Thanks!

daniel: looks like that.

And maybe or maybe not with MIX

But in that case I'd say that 0313 should say "don't do that" and the other specs define how and when to store

the only reason we get the include-groupchat query var is not breaking legacy systems.

Well, that's my fringe opinion at least.

AAOB?

Alright, then.

8) EOM

Thanks, everyone.

Thanks Ge0rG

Thanks Ge0rG

I don’t agree it makes no sense with 45, FWIW.

If you want the user to be able to search their archive for messages they’ve seen, it’s the only choice you’ve got.

Not as straight-forward at least

Kev: I'd love to see a response from you on-list :)

There are assorted problems with it, and I’m ok (obviously) with the patch that makes it optional, but we simply don’t have another mechanism for it.

I mean, it's a bit crappy with XEP-0045, but then, everything is if what you really wanted was persistent groupchats.

And FWIW, I think requiring people to restate their arguments over and over and treat them eventually getting bored of repeating themselves as a sign that their arguments don’t need to be considered to be distinctly suboptimal.

Kev: I'm sorry for leaving such an impression. I'm guilty of deriving "this doesn't make sense" from "this doesn't make sense for me"

I get that lots of people don’t care about being able to have complete archives of chats they’ve been in, and that’s fine, and making this optional means whole deployments can not have to care about it, but some people do care about that, and we shouldn’t be pointlessly changing protocol to prohibit servers from addressing that use case.

Kev: it's a very valid use case, and I'm using a dedicated client with a local on-disk archive to solve that problem in a different way.

Storing MUC history in MAM sucks royally. But if you want to have access to chat history for all chats you’ve been in, it’s the only thing we’ve got, and it sucking is better (for some people) than not having it.

Kev: what I'm saying is that as written, 0313 is not well suited to solve this problem, but opens a large number of 0045ities instead.

Normally, Experimental is the phase in which we convert an ugly hack into a sort of viable long-term solution.

0045 logs in user MAM still fall into the "ugly hack" category for me, so please convince me it's not.

Protocol-wise, I think 313 as-written (at least after the patch that makes it optional) is fine. It defines what’s needed for interop. But the onus is definitely on the server to somehow make the presented archive not suck. I can add some additional words explaining some of the ways that gc in user archives sucks, if that helps.

Ge0rG, How would you address the user requirements without a local on-disk archive?

Or even with an on-disk archive, if you have multiple clients.

Kev, That's easy, you just make MAM queries to the client you keep continuously online...

Again, I'm not saying that your problem is invalid, I'm questioning the non-solution that is "stuff all groupchat into user MAM"

full-text-search is not even part of MAM.

Ge0rG, Yes, but my assertion would be that it's not MAM that's the issue, but MUC.

Ge0rG, Also, not in the core, but it is an enabler for it.

That somewhat depends what you mean by ‘part of MAM’ - 313 as-written allows arbitrary form fields, and those can be used for search.

dwd: yes, but having "stuff all groupchat into MAM" makes it a MAM issue, too.

Kev: yes, and I'd love to see a dedicated FTS XEP on top of MAM, and that one could cover "store all groupchat messages in the user's archive, and search them for FTS queries"

But as written now, as a client developer I must expect random subsets of past MUC histories from unrelated clients to fall upon me during initial startup sync.

Ge0rG, Which is quite useful with MUCSUB, Muclight, or MIX. :-)

You will always have to expect that as a client.

dwd: none of which are MUC

Ge0rG, Well, MUCSUB is, kinda-sorta.

MAM is out there with gc results in it, you can’t change that. So the option is to disallow that with a namespace bump, or make it optional as in Dave’s proposal and my text (or to fix any non-compliant implementation currently out there that *doesn’t* do that).

Ge0rG, Also I think the Tigase people have something around groupchat to offline members.

There’s no way out of this that doesn’t involve clients written against this namespace of MAM having to accept gc messages if presented them.

Kev: yes, you convinced me of that much. But I still don't see why or how it could make sense.

And if namespace bumps weren't that expensive, I'd rather have suggested to remove gc and to bump.

Ignoring MAM search, what if you’re a full-sync client that wants to be able to search local archives? The only way to do that full sync is MAM, and that would also rely on gc messages in a full-sync query in order to build the local archive.

Kev: you can't rely on a full gc history in the user archive, so you must ask the MUC for gc history anyway.

If your server includes gc in the archive you can rely on it returning the full history of what you’ve seen.

Kev: so a full sync is to ask the user archive for non-gc and then each relevant MUC for its respective gc history.

Searching a full MUC history is different to searching your chats you’ve been in.

the full history of what I've seen is not the full history.

And your client has no way of knowing what MUCs you’ve been in in the past.

Yes.

(Unless it queries MAM for it)

> Ge0rG, Also I think the Tigase people have something around groupchat to offline members. this is just based on "registration" to the room and then sending messages irregardless if someone is in the room or not (with presence); though - this doens't necesarily invovled MAM and can be handled with regular "offline messages" spool

None of this is nice, but it is where we are.

Kev: But now you've promoted a technical service interruption to a permanent message loss.

If we were writing XMPP from scratch there are many things we wouldn’t do this way.

It's nice that everyone has a non-interoperable solution to avoiding using MIX. :-)

Kev: we have written MAM from scratch

(Though I think Tigase's is perhaps the neatest)

Indeed, and MAM isn’t the problem, MUC is.

Kev: and once again, storing MUC messages in MAM makes it a MAM problem.

MAM storing group chat messages is absolutely fine in the face of MIX or whatever that doesn’t do fan-out.

Kev: yes, and that's preconditioned on the MIX feature, and clients will use a MIX signal to obtain that history

(And good luck if you want servers to figure out what sort of GC it is)

Even though MIX also didn't solve the s2s interruption message loss problem.

dwd: do it based on the <x> element.

Isn't that something XEP-0198 is supposed to solve?

Although I don’t think anyone’s written it yet, I haven’t yet heard (that I can remember) why the MIX-sync stuff from the last summit wouldn’t work.

Zash: s2s 0198 when?

We already have it

Kev: I wasn't there and I didn't hear it, so I need to read it to say if it works.

I'm not entirely sure that it's possible to fix entirely. But '198 on S2S should mitigate at least. If you want to detect loss, you'll need a Merkel tree.

s2s-198 might be a touch underspecified tho, but it seems to at least not horribly break stuff

I'd *love* to see answers to all that questions, and it might even be possible to learn from them to improve MUC.

dwd, did you say Blockchain?

Zash, No, I didn't. I said Merkel tree.

s2s-0198 won't easily work over server restarts.

please get Merkel out of my head.

Ge0rG, As I said, you can't prevent message loss.

Ge0rG, And she'll be gone soon enough.

dwd: thanks for reminding me that the alternatives are all worse.

Youdon’t need a merkel tree to detect loss, it’s sufficient to be sequenced.

Kev, If you assume a sequencing point, yes.

Pointer to previous message?

Linked list?

dwd: you can prevent message loss with a client that directly queries the MUC MAM archive.

Zash: That was the summit proposal, yes ✏

Ge0rG, You can if the remote server's down.

dwd: the remote server is not going to remain down forever, right?

Ge0rG, Whyever not?

(well, if it is, at least we know that it is down and that we are somewhere near the end of the room history)

I think the probabilities of "server gets disconnected" and "server goes down forever" are multiple orders of magnitude apart.

It might make sense to optimize for the frequent event.

Ge0rG, Sure.

Ge0rG, I'm just saying you can't eliminate the problem, just mitigate.

And the flaky network infrastructure that I live on causes more than one MUC disconnect per day, on average.

dwd: but you can't paper over the problem by pretending that "all the user has seen" = "all there is"

Ge0rG, No, you can't. But if you wan tto search for a message you've seen, that's enough.

and now we have completed the circle :)

I wonder if it would be feasible to add all discussed XEP numbers into the title of council meeting minutes, for easier mailbox search.

So I've finally worked through the LC feedback on XEP-0280, and created three patches at https://gitlab.com/xsf/xeps/-/merge_requests/42

Rendered version at https://ge0rg.gitlab.io/-/xeps/-/jobs/1573759155/artifacts/rendered-changes/xep-0280.html

I'd like to discuss https://gitlab.com/xsf/xeps/-/merge_requests/42/diffs?commit_id=64f87e1d2ac8c60edd1355bc96ecfda25a603fc8 in next week's meeting, as it looks to me like it would require Council approval.