[Standards] GC3 in 2026

Hi folks, As promised in another thread, I'm posting a round-up of "GC3" resources. But first, I'll summarize what this is about for people who missed the summits/sprints where it was discussed. The idea grew, from discussions with a few people, that it would be good to level up group chats in XMPP, without breaking significantly with the extremely entrenched MUC protocol. In fact, we have already extended MUC (XEP-0045) in various ways, both by updating XEP-0045 itself and through various add-on XEPs in recent years, some with relatively rapid adoption (XEP-0421), and others not so rapid (yet?). There has been vague occasional talk of "MUC 2" for a very long time (since before MIX), mostly various isolated ideas for improvements. I wanted to try and finally glue some of these ideas together, without necessarily "stealing" the title as an official MUC successor, so "GC3" became a working title. Shortly after I'd started gathering this together, we held a sprint in the UK. A lot of that sprint ended up being reviewing the GC3 wishlist, priorities, eliminating some bad ideas, and clarifying some possible approaches. The slides of the GC3 presentation I gave at Summit 27, a few months later, are here: https://matthewwild.co.uk/uploads/xmpp-gc3-jan-2025.pdf The main GC3 notes, including feedback from the sprint and summit, are available here: https://pad.nixnet.services/s/7xKNOKxxE In addition to the notes, there have been a couple of partial attempts at turning it into something more like a specification. This one by Jonas: https://pad.nixnet.services/s/yu7drWpml This one by Kev: https://github.com/swift/protoxeps/blob/master/gc3.md Both these are missing some things, they probably overlap in some areas and conflict in others. But definitely together they form the basis of anything that would become a GC3 XEP. Apart from this, Kev also produced some additional related documents: - https://github.com/swift/protoxeps/blob/master/acl.md - https://github.com/swift/protoxeps/blob/master/related-entities.md These were spawned from GC3 discussions, but could certainly stand as XEPs in their own right. I don't want to speak for Kev, but I assume if there is sufficient interest then he would be willing to work further on these and get them submitted, or have someone else help to do so. Okay, that's the status of documentation. Partly because of the numerous ideas floating around, I also wanted to work on at least a rough prototype implementation of at least some core parts of the code. Just to try out the approach and prove it can work. I know that implementation isn't required by the XSF in order to have an experimental XEP. However, faced with the decision between spending time on writing a GC3 XEP, and figuring out if it can even be implemented, I personally chose to prioritize the latter. This isn't any kind of statement about whether or not there should be a GC3 XEP submitted at this stage, I *personally* just don't want to spend time writing such a broad XEP for a protocol that may need drastic changes as soon as anyone tries to implement it. I won't (and, anyway, can't) stop someone else with time and motivation from doing what they want (implementation or specification) with any of the "GC3" notes we've gathered. I presented them at the summit precisely with the hopes that everyone interested in the topic may do exactly that, so we can move the thing forward. After the summit presentation, I started making some necessary changes to the Prosody MUC code to allow us to accommodate some of the discussed GC3 features. Mainly internal refactoring of some APIs and data structures to make it more extensible and support chats where we have mixed MUC and GC3 clients. The only externally visible change in Prosody so far, is that I began implementing a participant list fetch protocol (behind an experimental feature flag). Ironically, it's one of the parts of the protocol we deemed during the sprint as high priority and yet we don't actually have a protocol for this written anywhere in the several "GC3"-related documents, yet. One of the features of such a protocol would be paging, e.g. using RSM. Prosody's implementation doesn't currently support this. I immediately ran into the problem that to support paging, the participant list needs to be ordered and stable. Currently Prosody stores affiliations and participants in unordered hash tables. Another thing that needs refactoring. Okay, that's the implementation update from me. Now, the status and future of GC3... It appears from discussions that multiple people have come to view me as having some kind of "ownership" over GC3. This was entirely unintended and very unfortunate. It's true (I think?!) that I picked the name, and I wrote the first draft of notes. However I think by now that between various discussions online and offline across and venues (regrettably not this list?), my personal contributions to the whole thing are quite outnumbered by others. Obviously if nobody else beat me to it, at some point writing a GC3 XEP was inevitably on my todo list. So I accept that I'm somehow the "default" person in a way - going to push this forward, eventually, if nobody else can/will. But it seems somehow this appeared as some kind of exclusivity, and this was likely due to poor communication on my part. In that regard, I am glad that Dave ignored this and broke the ice with the MUC2 proposal regardless, surfacing this whole issue. I like collaborating with smart folk, it's why I am here and why I do open-source. But I (and I'm not alone) have far more ideas, wishes and responsibilities than I have time to work on all at once. Sometimes this also means I get rather behind on emails, or that I might miss MUC discussions. If anyone else feels that I am somehow blocking them from doing what they want - I'm always willing to talk it over. And if that fails, please, just go ahead and do it. Now, finally, GC3 future... Realistically, I'm unlikely to change trajectory. I have a long list of stuff to do, and honestly, GC3 is outranked by various other priorities for the coming month or two at least. This means, I see the following possible outcomes: - MUC2 halts and nothing further happens until I finally get around to a GC3 XEP (nobody wants this) - MUC2 continues as a from-scratch parallel effort (not ideal in my opinion, but I can't and won't block such an effort, especially not if others think it's a good path) - MUC2 is at least informed and improved by the prior work on GC3, adopting as much or as little as deemed appropriate. Even if it ultimately adopts none of it, I think this would be a win. What I care about is that we arrive at a good MUC successor XEP with a good path to adoption. I will say it again just to be clear here: I don't care what it's called, or whose name(s) are on the document. Regards, Matthew