Re: Proposed XMPP Extension: New MUC
Matthew Wild <[email protected]> Wed, 29 Apr 2026 18:27:59 +0100
| Newsgroups | gmane.network.jabber.standards-jig |
|---|---|
| Message-ID | <CAJt9-x7RY7ZA9B2uCXQnjZjWKrSeb-usfuUEYX6_eLjEKgGU2A@mail.gmail.com> |
On Wed, 29 Apr 2026 at 17:48, Dave Cridland <[email protected]> wrote: > On Wed, 29 Apr 2026 at 15:20, Matthew Wild <[email protected]> wrote: >> >> On Wed, 29 Apr 2026 at 14:31, Dave Cridland <[email protected]> wrote: >> > As far as I know, GC3 has no published specification and is not an XSF activity; I've avoided that name to (hopefully) avoid confusion with it. >> >> Okay, I'll take the bait... :) >> >> Apart from being hashed out by multiple XSF members, including at a >> sprint, and presented and discussed at an XSF summit... >> > > I don't think that's the right definition of an XSF activity, is it? > > By that set of metrics, other XSF activities include Modern XMPP and the Jabber.org XMPP service. In fact, that even suggests Prosody is an XSF activity, doesn't it? Clearly that cannot be the case. I think this is a pointless debate because the line can be drawn wherever someone wants it to be drawn, and you've demonstrated it can be taken to extremes. I would argue that your classification of GC3 as not an XSF activity was taking it to the opposite extreme. > An XSF activity has various factors attached, most notably the Code of Conduct and the IPR Policy - the latter includes copyright assignment as well as change control - and ultimate control by the membership (usually via the Board or Council). The Summits are an XSF Activity, but they often discuss things that are not (this year, the IETF work for example). Meanwhile, our XEPs are often submitted and worked on by people who aren't XSF members, and the code worked on at Sprints is certainly not owned by the XSF. So I think your definition is flawed on every count. I don't see how the IPR policy is relevant in determining whether something is an XSF activity - it applies to documents entered into the standards process, but I think anyone would reasonably agree the XSF has activities beyond that (including discussion and collaboration on documents prior to their initial submission). > This ProtoXEP is offered to the XSF, no strings attached, with copyright assigned to the XSF and change control surrendered as per XEP-0001 upon publication. That's definitely an XSF activity, I think we can agree. I don't know... you as an individual just submitted it without (as far as I know) any of the XSF being involved at all. > And I do think this is extremely important. A newcomer to the XSF would be entirely unaware of GC3 except in occasional passing references, and would be unable to participate. I'm only aware of it at all because I happened to make the 2025 Summit, and I'm not exactly a newcomer. That's not how an Open Standards organisation should work, surely? I agree, it would be hard for a newcomer to discover. But if they are interested in a MUC successor, ideally they would say so and people could help them out. Ideally they wouldn't just invent a group chat protocol and submit it without researching existing efforts or bringing it up at a summit. I get the impression that you think GC3 is some specification that is being withheld from the XSF standards process. The only reason "the GC3 XEP" hasn't been submitted is because it doesn't exist. To make it exist, someone needs to collate the notes from the discussions at the sprint, summit and online and write it up in XEP syntax. There are still some unsolved questions about the approach (but, from a skim, probably fewer than the document you have submitted). Personally I'm not a fan of submitting unimplemented/unimplementable protocols (I've fixed up so many "TODO"-ridden XEPs in recent years), and that's partly why I haven't prioritized this work above getting some basic prototype code to prove it out a bit. But I'm not saying a XEP absolutely cannot come first, just explaining my personal time prioritization. If someone wants to help with the XEP side of things, I'm not going to complain. > No, I'm not ignoring anything, I'm simply unaware of them. Please do post them to the list, I'd welcome the discussion. If I don't respond, *then* you can tell me I'm ignoring them. The only thing I remember from the GC3 presentation at the 2025 Summit was the addressing, and I think I captured that. > I have some bandwidth available. If I get busy, there's a large number of very clever people on the mailing list who can take over and probably do a better job then I can - and you're certainly included in that. Honestly, everyone should be hoping I get busy. I'd have liked to say the same about the GC3 work, but the clever people are preferring to start their own thing from scratch :) > But if you're saying that I should not have submitted a ProtoXEP because of GC3, or that everyone should ignore this because of GC3, then I must disagree very strongly indeed. I'm not saying that at all. I don't think any unrealized XEP (such as GC3) should prevent someone from submitting an actual XEP. That would hinder progress and wouldn't be good for anyone. However, progress is also hindered if work is done in the community and then completely ignored. >> So to answer Nicolas's question: they seem, needlessly, to be >> different things at the moment. > > > Please do take the time to explain why, and why your approach is better. I don't especially have time right now (I literally have a child pulling my arm as I type this). However I can dig up the relevant links from the summit notes and post a new thread about GC3 shortly (I don't particularly want to hijack this thread, which is probably best reserved for feedback on the submission itself). Regards, Matthew _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]