-
Ge0rG
Oh, it's almost time, and I'm so excited to be the standin-chair today!
-
Ge0rG
It's Meeting Time!
-
Ge0rG
1) Roll Call
-
daniel
Hi
-
Zash
Hello
-
Ge0rG
Jonas is excused.
-
Ge0rG
Do we have a dwd?
-
dwd
Sorry, yes!
-
Ge0rG
Awesome!
-
Ge0rG
2) Agenda Bashing
-
Ge0rG
It's not my fault, so feel free to fire at will!
-
Zash
Surprise MAM vote!
-
Ge0rG
It's on the agenda, so not so much of a surprise.
-
Ge0rG
Maybe surprise MAM PR?
-
Ge0rG
I suggest we can discuss the PR ahead of voting.
-
Ge0rG
3) Editor’s Update - Last Call for XEP-0459, Compliance Suites 2022
-
Ge0rG
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.
-
Ge0rG
But thank you very much to jonas’ the Editor.
-
Ge0rG
4) Items for voting
-
Ge0rG
4a) PR#1064: XEP-0227: New revision 1.1 URL: https://github.com/xsf/xeps/pull/1064
-
Zash
+1
-
daniel
+1
-
dwd
+1
-
Ge0rG
+1
-
Ge0rG
I'm sure that jonas’ will on-list.
-
Ge0rG
4b) Advance XEP-0313 to Stable as-is
-
Ge0rG
There was a surprise PR update to this in https://github.com/xsf/xeps/pull/1104
-
Ge0rG
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
-
dwd
Yeah, so wait for that PR to go in, and the security considerations you wanted?
-
dwd
Well, we can't really vote on anything given that.
-
Ge0rG
dwd: that PR is an author update based on LC feedback.
-
Ge0rG
and the CVE inclusion is viewed as Editorial.
-
dwd
Oh, is it? Either way, I'd like to vote once we have those merged.
-
daniel
> Oh, is it? Either way, I'd like to vote once we have those merged. +1
-
dwd
I'm not sure that writing a load of security considerations really can be Editorial.
-
Ge0rG
Okay, so we wait for jonas’-the-Editor to push the merge button and to perform the respective boilerplate tasks.
-
Ge0rG
dwd: the security considerations are LC feeback ;)
-
dwd
Yes... But that doesn't make them editorial.
-
Ge0rG
dwd: no
-
Ge0rG
the question is: do we need another LC for feedback integrated from a previous LC?
-
Zash
I think not
-
Ge0rG
If not, then the next step would be to apply the PR and to vote for advancement into Stable.
-
dwd
Yes, sounds right to me.
-
Ge0rG
Or to vote for advancement based on the pre-condition of the PR being applied.
-
dwd
As in, no need for another LC.
-
dwd
But we can't vote on a XEP not in front of us.
-
Ge0rG
That's a tough point indeed.
-
daniel
Technically we have in the past I think
-
daniel
But there is absolutely no rush
-
Ge0rG
So let's have the Editor merge the PR and then we will re-elect.
-
Ge0rG
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.
-
Ge0rG
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.
-
Ge0rG
5) Pending Votes None.
-
Ge0rG
Good job, everyone :)
-
Ge0rG
6) Date of Next
-
Ge0rG
+1W WFM
-
daniel
+1w wfm
-
dwd
+1WFM2
-
Ge0rG
Zash?
-
Zash
+1w wfm
-
Ge0rG
Awesome. Let's hope that jonas’ comes back well after the party.
-
Ge0rG
7) AOB
-
daniel
Non here
-
dwd
daniel, Bit French, that.
-
Ge0rG
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.
-
dwd
Yes. And I will.
-
daniel
Tldr It makes no sense with plain xep45 but can be very useful with muc light, muc/sub and stuff?
-
Ge0rG
Thanks!
-
Ge0rG
daniel: looks like that.
-
daniel
And maybe or maybe not with MIX
-
Ge0rG
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
-
Ge0rG
the only reason we get the include-groupchat query var is not breaking legacy systems.
-
Ge0rG
Well, that's my fringe opinion at least.
-
Ge0rG
AAOB?
-
Ge0rG
Alright, then.
-
Ge0rG
8) EOM
-
Ge0rG
Thanks, everyone.
-
Zash
Thanks Ge0rG
-
dwd
Thanks Ge0rG
-
Kev
I don’t agree it makes no sense with 45, FWIW.
-
Kev
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.
-
Zash
Not as straight-forward at least
-
Ge0rG
Kev: I'd love to see a response from you on-list :)
-
Kev
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.
-
dwd
I mean, it's a bit crappy with XEP-0045, but then, everything is if what you really wanted was persistent groupchats.
-
Kev
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.
-
Ge0rG
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"
-
Kev
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.
-
Ge0rG
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.
-
Kev
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.
-
Ge0rG
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.
-
Ge0rG
Normally, Experimental is the phase in which we convert an ugly hack into a sort of viable long-term solution.
-
Ge0rG
0045 logs in user MAM still fall into the "ugly hack" category for me, so please convince me it's not.
-
Kev
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.
-
dwd
Ge0rG, How would you address the user requirements without a local on-disk archive?
-
Kev
Or even with an on-disk archive, if you have multiple clients.
-
dwd
Kev, That's easy, you just make MAM queries to the client you keep continuously online...
-
Ge0rG
Again, I'm not saying that your problem is invalid, I'm questioning the non-solution that is "stuff all groupchat into user MAM"
-
Ge0rG
full-text-search is not even part of MAM.
-
dwd
Ge0rG, Yes, but my assertion would be that it's not MAM that's the issue, but MUC.
-
dwd
Ge0rG, Also, not in the core, but it is an enabler for it.
-
Kev
That somewhat depends what you mean by ‘part of MAM’ - 313 as-written allows arbitrary form fields, and those can be used for search.
-
Ge0rG
dwd: yes, but having "stuff all groupchat into MAM" makes it a MAM issue, too.
-
Ge0rG
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"
-
Ge0rG
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.
-
dwd
Ge0rG, Which is quite useful with MUCSUB, Muclight, or MIX. :-)
-
Kev
You will always have to expect that as a client.
-
Ge0rG
dwd: none of which are MUC
-
dwd
Ge0rG, Well, MUCSUB is, kinda-sorta.
-
Kev
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).
-
dwd
Ge0rG, Also I think the Tigase people have something around groupchat to offline members.
-
Kev
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.
-
Ge0rG
Kev: yes, you convinced me of that much. But I still don't see why or how it could make sense.
-
Ge0rG
And if namespace bumps weren't that expensive, I'd rather have suggested to remove gc and to bump.
-
Kev
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.
-
Ge0rG
Kev: you can't rely on a full gc history in the user archive, so you must ask the MUC for gc history anyway.
-
Kev
If your server includes gc in the archive you can rely on it returning the full history of what you’ve seen.
-
Ge0rG
Kev: so a full sync is to ask the user archive for non-gc and then each relevant MUC for its respective gc history.
-
Kev
Searching a full MUC history is different to searching your chats you’ve been in.
-
Ge0rG
the full history of what I've seen is not the full history.
-
Kev
And your client has no way of knowing what MUCs you’ve been in in the past.
-
Ge0rG
Yes.
-
Kev
(Unless it queries MAM for it)
-
Wojtek
> 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
-
Kev
None of this is nice, but it is where we are.
-
Ge0rG
Kev: But now you've promoted a technical service interruption to a permanent message loss.
-
Kev
If we were writing XMPP from scratch there are many things we wouldn’t do this way.
-
dwd
It's nice that everyone has a non-interoperable solution to avoiding using MIX. :-)
-
Ge0rG
Kev: we have written MAM from scratch
-
dwd
(Though I think Tigase's is perhaps the neatest)
-
Kev
Indeed, and MAM isn’t the problem, MUC is.
-
Ge0rG
Kev: and once again, storing MUC messages in MAM makes it a MAM problem.
-
Kev
MAM storing group chat messages is absolutely fine in the face of MIX or whatever that doesn’t do fan-out.
-
Ge0rG
Kev: yes, and that's preconditioned on the MIX feature, and clients will use a MIX signal to obtain that history
-
dwd
(And good luck if you want servers to figure out what sort of GC it is)
-
Ge0rG
Even though MIX also didn't solve the s2s interruption message loss problem.
-
Ge0rG
dwd: do it based on the <x> element.
-
Zash
Isn't that something XEP-0198 is supposed to solve?
-
Kev
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.
-
Ge0rG
Zash: s2s 0198 when?
-
Zash
We already have it
-
Ge0rG
Kev: I wasn't there and I didn't hear it, so I need to read it to say if it works.
-
dwd
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.
-
Zash
s2s-198 might be a touch underspecified tho, but it seems to at least not horribly break stuff
-
Ge0rG
I'd *love* to see answers to all that questions, and it might even be possible to learn from them to improve MUC.
-
Zash
dwd, did you say Blockchain?
-
dwd
Zash, No, I didn't. I said Merkel tree.
-
Ge0rG
s2s-0198 won't easily work over server restarts.
-
Ge0rG
please get Merkel out of my head.
-
dwd
Ge0rG, As I said, you can't prevent message loss.
-
dwd
Ge0rG, And she'll be gone soon enough.
-
Ge0rG
dwd: thanks for reminding me that the alternatives are all worse.
-
Kev
Youdon’t need a merkel tree to detect loss, it’s sufficient to be sequenced.
-
dwd
Kev, If you assume a sequencing point, yes.
-
Zash
Pointer to previous message?
-
Zash
Linked list?
-
Ge0rG
dwd: you can prevent message loss with a client that directly queries the MUC MAM archive.
-
Kev
Zash: That was the unit proposl, yes.✎ - Kev
-
Kev
Zash: That was the summit proposal, yes ✏
-
dwd
Ge0rG, You can if the remote server's down.
-
Ge0rG
dwd: the remote server is not going to remain down forever, right?
-
dwd
Ge0rG, Whyever not?
-
Ge0rG
(well, if it is, at least we know that it is down and that we are somewhere near the end of the room history)
-
Ge0rG
I think the probabilities of "server gets disconnected" and "server goes down forever" are multiple orders of magnitude apart.
-
Ge0rG
It might make sense to optimize for the frequent event.
-
dwd
Ge0rG, Sure.
-
dwd
Ge0rG, I'm just saying you can't eliminate the problem, just mitigate.
-
Ge0rG
And the flaky network infrastructure that I live on causes more than one MUC disconnect per day, on average.
-
Ge0rG
dwd: but you can't paper over the problem by pretending that "all the user has seen" = "all there is"
-
dwd
Ge0rG, No, you can't. But if you wan tto search for a message you've seen, that's enough.
-
Ge0rG
and now we have completed the circle :)
-
Ge0rG
I wonder if it would be feasible to add all discussed XEP numbers into the title of council meeting minutes, for easier mailbox search.
-
Ge0rG
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
-
Ge0rG
Rendered version at https://ge0rg.gitlab.io/-/xeps/-/jobs/1573759155/artifacts/rendered-changes/xep-0280.html
-
Ge0rG
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.