Groupchat 3.0 development - 2025-02-24

Is there anything actually happening around here? :)

Or planned to

IIRC there are some drafts around. Main thing that needs to happen is prototypes

For prototypes you'd need the drafts, no? I am kind of interested anyhow

https://pad.nixnet.services/WJm97HA9SJaURGhxNqGOcA?view# that's the last link I know of. Maybe that could be put somewhere in the topic if it's still up-to-date

> For prototypes you'd need the drafts, no? I am kind of interested anyhow No IMO, usually things work better the other way. But I everyone has what works best for them ↺

>> For prototypes you'd need the drafts, no? I am kind of interested anyhow > No IMO, usually things work better the other way. But I everyone has what works best for them I think so too ↺

Well there's no document atm so it's not like people outside of the loop could draft anything

one could go and try to make the counterpart for the available public code ^_^

(not sure I understand)

https://gitlab.com/xmpp-rs/xmpp-rs/-/merge_requests/533 there is draft code in public already, though I'm not sure if it's up-to-date with the recent spec drafts

An implementation doesn't make a spec :P

But that's still nice to see

pep., there’s https://github.com/swift/protoxeps/blob/master/gc3.md from Kev I guess (this was mentioned at summit, not sure what is the current status of everything)

> The channel responds telling the user what room JID they should expect the presence subscription request from. This allows for room aliases (e.g. coven@gc3service.example.com being a friendly alias that a user can join for the channel whose opaque JID is really UHJhaXNlIEtldgo@c3service.example.com). How does this work exactly? Aliases.

It just means that you can have the internal address of the room be service-assigned, but still allow a 'nice' address to join (a nice address that can change over time, or even have more than one, potentially).

And how does it work

I mean.. does the account server or the client ever sees the non-aliased jid? I guess so because that's the jid they join. So where does this alias appear?

(at least that's what the examples show)

Yeah, 'everything' happens based on the canonical JID (the service-generated one), other than that a user can try to join the alias and end up joined to the canonical.

gc3.md clearly isn't ready to go to Final yet :)

Sure

heh, the part about subscribing to messages/presence feels like MIX. Also, what's the thing about "all channels"? "Subscribing to *** on all channels"

It's allowing a client to set a default so they don't have to explicitly sub to messages/presence/whatever on all the channels they join, if they want in on all of them.

Akin to PEP, but obviously not PEP.

Ah that's directed to their account server?

" initial broadcast presence", yeah.

So if you're a client that wants to act like a MUC client (all presence, all messages), you just put two disco entries in your presence, and you never have to touch explicit subs.

Similarly if you want all messages, but never want presence.

As I understand, nicks aren't included in messages anymore right? One needs to query.. occupant / participant lists (one or the other?)

Open question. It *could* include the nick as it was at the time the message was sent in a <nick/> element, but that has both technical (desync of state) and social (e.g. deadnaming) concerns, I think.

I see. Maybe that's alright yeah.

How is a nick change then broadcast to all participant? And are clients supposed to update the displayed nick of previous messages to avoid the deadnaming?

Through the participants node. I don't think I've written any words about that yet.

Ah, ok.

Retroactively changing the display of nicks seems like a bad idea as it would break all the mentions.

Kris: would it though, if we handle mentions properly, that is, the displayed nickname can be changed, the thing that's transfered on the wire as a mention is the unique id.

well, I guess it could be handled somehow with additional complexity

We do need mentions anyway so we can stop using regex finally :)

(So I can stop getting mentioned for nothing)

Am I missing something? I thought that was already a thing

In conversejs and renga yeah, ish

Oh, I didn't realise the XEP was still experimental.

And the renga implementation said it is not completely compliant because jids can be hidden in mucs :) ✏

And the renga implementation sais it is not completely compliant because jids can be hidden in mucs :) ✏