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