Ge0rGOh, it's almost time, and I'm so excited to be the standin-chair today!
Ge0rGIt's Meeting Time!
Ge0rG1) Roll Call
Ge0rGJonas is excused.
Ge0rGDo we have a dwd?
Ge0rG2) Agenda Bashing
Ge0rGIt's not my fault, so feel free to fire at will!
ZashSurprise MAM vote!
Ge0rGIt's on the agenda, so not so much of a surprise.
Ge0rGMaybe surprise MAM PR?
Ge0rGI suggest we can discuss the PR ahead of voting.
Ge0rG3) Editor’s Update
- Last Call for XEP-0459, Compliance Suites 2022
Ge0rGI'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.
Ge0rGBut thank you very much to jonas’ the Editor.
Ge0rG4) Items for voting
Ge0rG4a) PR#1064: XEP-0227: New revision 1.1
Ge0rGI'm sure that jonas’ will on-list.
Ge0rG4b) Advance XEP-0313 to Stable as-is
Ge0rGThere was a surprise PR update to this in https://github.com/xsf/xeps/pull/1104
Ge0rGSo 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
dwdYeah, so wait for that PR to go in, and the security considerations you wanted?
dwdWell, we can't really vote on anything given that.
Ge0rGdwd: that PR is an author update based on LC feedback.
Ge0rGand the CVE inclusion is viewed as Editorial.
dwdOh, 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.
dwdI'm not sure that writing a load of security considerations really can be Editorial.
Ge0rGOkay, so we wait for jonas’-the-Editor to push the merge button and to perform the respective boilerplate tasks.
Ge0rGdwd: the security considerations are LC feeback ;)
dwdYes... But that doesn't make them editorial.
Ge0rGthe question is: do we need another LC for feedback integrated from a previous LC?
ZashI think not
Ge0rGIf not, then the next step would be to apply the PR and to vote for advancement into Stable.
dwdYes, sounds right to me.
Ge0rGOr to vote for advancement based on the pre-condition of the PR being applied.
dwdAs in, no need for another LC.
dwdBut we can't vote on a XEP not in front of us.
Ge0rGThat's a tough point indeed.
danielTechnically we have in the past I think
danielBut there is absolutely no rush
Ge0rGSo let's have the Editor merge the PR and then we will re-elect.
Ge0rGdaniel: 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.
Ge0rGThat said, I still have a long list of issues that weren't addressed in this PR, given that they were not blocking the advancement.
Ge0rG5) Pending Votes
Ge0rGGood job, everyone :)
Ge0rG6) Date of Next
Ge0rGAwesome. Let's hope that jonas’ comes back well after the party.
dwddaniel, Bit French, that.
Ge0rGdwd: 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.
dwdYes. And I will.
danielTldr It makes no sense with plain xep45 but can be very useful with muc light, muc/sub and stuff?
Ge0rGdaniel: looks like that.
danielAnd maybe or maybe not with MIX
Ge0rGBut in that case I'd say that 0313 should say "don't do that" and the other specs define how and when to store
Ge0rGthe only reason we get the include-groupchat query var is not breaking legacy systems.
Ge0rGWell, that's my fringe opinion at least.
KevI don’t agree it makes no sense with 45, FWIW.
KevIf you want the user to be able to search their archive for messages they’ve seen, it’s the only choice you’ve got.
ZashNot as straight-forward at least
Ge0rGKev: I'd love to see a response from you on-list :)
KevThere 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.
dwdI mean, it's a bit crappy with XEP-0045, but then, everything is if what you really wanted was persistent groupchats.
KevAnd 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.
Ge0rGKev: 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"
KevI 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.
Ge0rGKev: 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.
KevStoring 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.
Ge0rGKev: 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.
Ge0rGNormally, Experimental is the phase in which we convert an ugly hack into a sort of viable long-term solution.
Ge0rG0045 logs in user MAM still fall into the "ugly hack" category for me, so please convince me it's not.
KevProtocol-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.
dwdGe0rG, How would you address the user requirements without a local on-disk archive?
KevOr even with an on-disk archive, if you have multiple clients.
dwdKev, That's easy, you just make MAM queries to the client you keep continuously online...
Ge0rGAgain, I'm not saying that your problem is invalid, I'm questioning the non-solution that is "stuff all groupchat into user MAM"
Ge0rGfull-text-search is not even part of MAM.
dwdGe0rG, Yes, but my assertion would be that it's not MAM that's the issue, but MUC.
dwdGe0rG, Also, not in the core, but it is an enabler for it.
KevThat somewhat depends what you mean by ‘part of MAM’ - 313 as-written allows arbitrary form fields, and those can be used for search.
Ge0rGdwd: yes, but having "stuff all groupchat into MAM" makes it a MAM issue, too.
Ge0rGKev: 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"
Ge0rGBut 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.
dwdGe0rG, Which is quite useful with MUCSUB, Muclight, or MIX. :-)
KevYou will always have to expect that as a client.
Ge0rGdwd: none of which are MUC
dwdGe0rG, Well, MUCSUB is, kinda-sorta.
KevMAM 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).
dwdGe0rG, Also I think the Tigase people have something around groupchat to offline members.
KevThere’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.
Ge0rGKev: yes, you convinced me of that much. But I still don't see why or how it could make sense.
Ge0rGAnd if namespace bumps weren't that expensive, I'd rather have suggested to remove gc and to bump.
KevIgnoring 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.
Ge0rGKev: you can't rely on a full gc history in the user archive, so you must ask the MUC for gc history anyway.
KevIf your server includes gc in the archive you can rely on it returning the full history of what you’ve seen.
Ge0rGKev: so a full sync is to ask the user archive for non-gc and then each relevant MUC for its respective gc history.
KevSearching a full MUC history is different to searching your chats you’ve been in.
Ge0rGthe full history of what I've seen is not the full history.
KevAnd your client has no way of knowing what MUCs you’ve been in in the past.
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
KevNone of this is nice, but it is where we are.
Ge0rGKev: But now you've promoted a technical service interruption to a permanent message loss.
KevIf we were writing XMPP from scratch there are many things we wouldn’t do this way.
dwdIt's nice that everyone has a non-interoperable solution to avoiding using MIX. :-)
Ge0rGKev: we have written MAM from scratch
dwd(Though I think Tigase's is perhaps the neatest)
KevIndeed, and MAM isn’t the problem, MUC is.
Ge0rGKev: and once again, storing MUC messages in MAM makes it a MAM problem.
KevMAM storing group chat messages is absolutely fine in the face of MIX or whatever that doesn’t do fan-out.
Ge0rGKev: 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)
Ge0rGEven though MIX also didn't solve the s2s interruption message loss problem.
Ge0rGdwd: do it based on the <x> element.
ZashIsn't that something XEP-0198 is supposed to solve?
KevAlthough 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.
Ge0rGZash: s2s 0198 when?
ZashWe already have it
Ge0rGKev: I wasn't there and I didn't hear it, so I need to read it to say if it works.
dwdI'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.
Zashs2s-198 might be a touch underspecified tho, but it seems to at least not horribly break stuff
Ge0rGI'd *love* to see answers to all that questions, and it might even be possible to learn from them to improve MUC.
Zashdwd, did you say Blockchain?
dwdZash, No, I didn't. I said Merkel tree.
Ge0rGs2s-0198 won't easily work over server restarts.
Ge0rGplease get Merkel out of my head.
dwdGe0rG, As I said, you can't prevent message loss.
dwdGe0rG, And she'll be gone soon enough.
Ge0rGdwd: thanks for reminding me that the alternatives are all worse.
KevYoudon’t need a merkel tree to detect loss, it’s sufficient to be sequenced.
dwdKev, If you assume a sequencing point, yes.
ZashPointer to previous message?
Ge0rGdwd: you can prevent message loss with a client that directly queries the MUC MAM archive.
Ge0rGdwd: the remote server is not going to remain down forever, right?
dwdGe0rG, 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)
Ge0rGI think the probabilities of "server gets disconnected" and "server goes down forever" are multiple orders of magnitude apart.
Ge0rGIt might make sense to optimize for the frequent event.
dwdGe0rG, I'm just saying you can't eliminate the problem, just mitigate.
Ge0rGAnd the flaky network infrastructure that I live on causes more than one MUC disconnect per day, on average.
Ge0rGdwd: but you can't paper over the problem by pretending that "all the user has seen" = "all there is"
dwdGe0rG, No, you can't. But if you wan tto search for a message you've seen, that's enough.
Ge0rGand now we have completed the circle :)
Ge0rGI wonder if it would be feasible to add all discussed XEP numbers into the title of council meeting minutes, for easier mailbox search.
Ge0rGSo I've finally worked through the LC feedback on XEP-0280, and created three patches at https://gitlab.com/xsf/xeps/-/merge_requests/42
Ge0rGRendered version at https://ge0rg.gitlab.io/-/xeps/-/jobs/1573759155/artifacts/rendered-changes/xep-0280.html
Ge0rGI'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.