On Wed, 29 Apr 2026 at 15:20, Matthew Wild <mwild1@gmail.com> wrote:
On Wed, 29 Apr 2026 at 14:31, Dave Cridland <dave@cridland.net> 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.

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.

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. And I think we also agree that Modern XMPP, jabber.org, and Prosody are definitely not XSF activities. But I don't follow why GC3 would be an XSF activity for more or less the same reasons.

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?
 
But yes, I know you *really* want a XEP even before we figure out what
should go in it. Hence you've submitted something that doesn't seem to
take into account any of the work we've done so far and doesn't seem
implementable (yet). The submission says it is offered "offered as a
discussion point", but we already had discussion points you've
ignored.

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.

Also, I'm pretty sure the ProtoXEP is implementable, or at least nearly so. It's probably not very good, and almost certainly has some rough edges. It's probably missed some great ideas you, Kev, or whoever else is working on GC3 has had. Experimental XEPs are not officially gated on implementation, or even implementability, but if you'd like an implementation I can probably knock out a PoC relatively quickly - I'll undoubtedly find improvements and perhaps outright errors in thespec by doing so. And make Guus have nightmares by the code quality, of course.

And you're right, I would like a XEP, even a rough one, to work on - I think it's useful to focus discussion aside from anything else. I suspect Marvin will end up asking for the XEP to split out various cases, too, so we'll have multiple XEPs - not my choice but it could work. I entirely understand that other people would rather start with the discussion, and again I can live with that - but I do feel very strongly that we are an open standards organisation, and as such that discussion absolutely must occur on our venues (such as this list). This list - or more formally, the Standards SIG - very much is an XSF Activity (if not *the* XSF Activity).
 
I don't currently have the bandwidth for arguing any of these points,
which is why I wasn't saying anything about the XEP submission. If you
actually have time to dedicate to getting a MUC successor over the
finish line, something I want quite badly, then I'm not going to stand
in the way! But I think it's silly to start parallel work. We
certainly don't need multiple new group chat protocols in our
repertoire.

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.

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.
 
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.

Dave.