Groupchat 3.0 development - 2025-07-29

I know I'm just a lurker who's interested in GC3 but is any of this substantially pertain the subject of this public chatroom? Even if any of it is true (and, honestly, I can't even find evidence of this slur he's suggesting existing online), wouldn't it best be handled privately?

you have witnessed new xmpp folklore

> I know I'm just a lurker who's interested in GC3 but is any of this substantially pertain the subject of this public chatroom? Even if any of it is true (and, honestly, I can't even find evidence of this slur he's suggesting existing online), wouldn't it best be handled privately? anyways I'm in the same position, doesn't seem like there's been any serious conversation for months at this point after digging through the logs ↺

Other than apparent schizophrenia, has anything interesting happened with GC3 lately?

MattJ is is working on some initial prototype stuff recently

oh awesome

Prosody gained a 'muc_enable_experimental_gc3' option in trunk a few weeks ago

But it's nothing amazing yet, I'm still working on stuff

Any clients doing gc3 stuff?

pep., there is a merge request open for xmpp-parsers.

Yeah it's just for parsers though, nothing is being done with that, at least in the open

Merge request? for what protocol?

There are currently ~3 GC3 proposals, and none of them match what Prosody implements

MattJ, https://gitlab.com/xmpp-rs/xmpp-rs/-/merge_requests/533

Ah, then it will almost certainly be for the proposal jonas’ wrote :)

I am trying to follow stuff that has already been written, but I highly doubt it will match any of the proposals 100%, and I'm currently using a 'tmp' namespace to make that future-proof

Where can we see these proposals?

Yay another tmp namespace :)

The original doc I wrote: https://pad.nixnet.services/s/7xKNOKxxE A doc by Kev: https://github.com/swift/protoxeps/blob/master/gc3.md A doc by jonas’: https://pad.nixnet.services/s/yu7drWpml

fight!

fist fight in front of stpeter's house is the only way to resolve this, clearly.

The 2nd and 3rd docs were both written based on discussions around the first doc (which is more an ideas doc)

I expect the 2nd and 3rd to gradually converge into a XEP as the prototype implementation progresses

It also sounds worse than it is, because the docs don't overlap all that much. And amusingly the first thing I implemented (participant listing) isn't covered in any of them.

MattJ, that's not the first thing you implemented, you implemented create ;-D

Did you test against it?

(asking because if I implemented it, I'm not sure where the code is...)

MattJ, yeah we were testing back & forth

before summit

I think we got create and destroy up

then we got into a discussion about how to map '45 and GC3 participants to one another, then summit happened (where I didn't participate), and we both moved on to different things IIRC.

I can look up the hostnames I was testing against later.

Found it

161 lines I can now merge into Prosody :)

:)

so in fact the xmpp-rs impl does work against Prosody, so there's that.

jonas’, "A Server is an XMPP entity hosts zero or more Group entities. Typically, a Server is identified by a localpart-less domain-only JID." is the idea of reproducing the "a room MUST have a localpart" thing of MUC? Can a server not be identified via its identity rather?

pep., no

you can have a GC3 Chat at the domain

And then the domain is both a chat and a muc service containing that chat?

pep., support for groups on the domain is explicitly mentioned: > If a Server supports Groups on the Server JID itself (for example, if the server is at chats.example, it might support hosting a Group at chats.example (without localpart)), it MUST NOT create such a group in response to a <create/> request. Instead, such groups may only be created through a separate administrative action. A <create/> request would otherwise be ambiguous.

Ok

singpolyma, that's a different issue.

I'm mainly advocating here for letting entities identify themselves instead of arbitrarily putting them into boxes

I don't think it's an issue, I'm just clarifying

(identity-affirming for XMPP :x)

Though I also think this could be nice to have multiple use-cases like that. heck an account is already both an account and a pubsub node

A pubsub service! With many nodes

Indeed

"Implementations MUST support at least 10 levels of redirects.", still reading https://pad.nixnet.services/s/yu7drWpml# Is 10 a common number? That seems overly big. We're not http

Anyway, nits

"Servers SHOULD reply with this error for at least six months after a Group has been destroyed." heh. "admins should continue paying even though they're shutting down their servers" :p

In the Joinjabber server covenant we say at least 3 months, fwiw. https://joinjabber.org/about/community/covenant/

(Not to a specific room but for a server shutdown)

pep., I probably made that number up on the fly

people need something to bikeshed

and with that number in there, they'll focus on that instead of the things which are important to keep as they are :->

:P

pep., a Server is a software/deployment. If that deployment is gone, all requests the Server gets are automatically correctly answered by that Server.

Iseewhatyoudidthere

(because it gets no requests.)

"Establish a Session", why have the group iq the client? Instead of the client saying it supports the protocol?

"A Group MAY optimize this query using the mechanisms described in XEP-0115, XEP-0390" ok

Included in the session presence then right ✏

But that still means a first roundtrip right?

> Note: A Session is not a requirement in order to be able to send messages to the Group. Any Participant’s resource may send messages to the Group at any time, even if they currently do not have a Session established to receive live messages. Do you also have a use-case in mind for non-announcement messages? (I mean made by owners mostly, service announcements)

I guess these could be made by moderators too

"Send an IQ request to another participant", I wish avatars and stuff were on a pubsub node on the group, so we don't have to relay stuff anymore. _and_ we can have different profiles per group easily

Why would they be on the group??

Right now I can think of avatar and encryption keys

I mean public keys

Why the surprise?

Sending an iq through the MUC has always been a way to get private information from a client/account/person. It's not available everywhere, that's ok for avatars I guess but a lot less for encryption. And yeah I may want to encrypt for non-contacts

Plus, it allows having different profiles per room

Everything that can be in a room's node can be different in another

I get that, and I've seen multiple people suggest such a model, but I don't really like spreading the user data around

Storing avatars and stuff in a room just feels like it's solving stuff at the wrong level

Where would you see that done? Or how else?

and it will add new problems, from keeping it in sync to data hygiene issues (it will remain when a user deletes their account)

hmm.

*if* we do it, it should be done at the user's account (somehow... I don't have a decent proposal)

I still want a pubsub service on MUC fwiw, if not to keep user data then for various feeds related to the topic

other than, you know, "use a different account" which IIRC you don't agree with, but I think it makes a lot of sense

Yeah, sure, you know I've always been in favour of that

That has never needed GC3 and is pretty trivial to achieve with MUC

Just nobody bothered to do stuff that way

Well I end up having 10 different accounts yeah

Sure. I still think having 10 different accounts is better than having one account and hundreds of different channels you have to manage one-by-one

I still have the hundreds channels I need to manage one-by-one :p

They're just spread on various accounts

Yeah, but if you have one persona per account, when you update your avatar/keys/whatever, it is updated everywhere that you joined that account to

If you have it under one account but manage data per room, you have to tell each room to update its copy of the data

Maybe yeah, dunno. I still think there's something in the middle

I am leaning towards having an avatar hash stored by the room, fwiw. That might make a multi-avatar account slightly more feasible.

If you can then solve the discovery/permissions issue at the account level, then it might make it possible for a client to manage things in the way you want

Same as I don't have to have the same nick in all rooms

Reasonable

As for the data hygiene issues "it will remain when a user deletes their account", that's a problem we should try to solve anyway

auto expiry?

That doesn't sound too bad yeah

Quid of service wide bans, btw

Or service-wide things, applied to a specific jid

> I still want a pubsub service on MUC fwiw, if not to keep user data then for various feeds related to the topic Sure yes. For the avatar of the MUC at least ↺

> I am leaning towards having an avatar hash stored by the room, fwiw. That might make a multi-avatar account slightly more feasible. Multi avatar is just an implementation thing right? Server needs to reply to pep requests from different gets with different answers. Just no one has built it ↺

singpolyma, more than "for MUC avatar". I don't know, anything that concerns the MUC could be open for use. May be restricted to moderators. Say roleplay stuff that's done on the MUC, to keep progress state, or more commonly, forge webhook stuff that spams the room and not everyone wants, I'd like for people to be able to opt-in to that ✏

I'm gonna make a big reveal but I couldn't care less about the debian nightly build in the prosody room :p