Modern XMPP project discussion - 2024-12-28

A certain MUC was dissolved, but it still remains in my bookmarks with the auto-join setting enabled. As a result, some people like me mysteriously found themselves in a new group chat. We didn't even know what happened. Some lucky person became the new group owner.

How to deal with this situation?

from a client perspective its impossible

Some servers do not set a cooldown period for MUC addresses, and in the absence of a MUC, joining a group chat is treated as creating a new group chat.

the server should not allow to rejoin a destroyed MUC for some time, and send an error that the groupchat was destroyed

hm i think my previous statement was wrong, clients can disco the MUC before joining and discover that it is not existent anymore

Prosody has a tombstone function, and ejabberd recently added a community module for it

Yes, either you waited a long time and joined the MUC after the cooldown period, or...

For ejabberd it defaults to one year I think.

Conversations does not send disco check for group chats before joining a MUC. ✏

Recently... Well, it's time for the server maintainers to take some action.

I'd like to express my frustration: equating the act of joining a group chat with creating a new one is quite misguided.

saf, the newer GC3 spec that's being worked on does change this

https://pad.nixnet.services/WJm97HA9SJaURGhxNqGOcA?view#

saf, thats a protocol detail, as said your client can disco the muc before joining, to see if it exists

I think that's a poor solution, because it's rather inefficient if you have many MUCs

my point was, the protocol does not need to be changed to provide good UX

of course the protocol can always be made better to be more efficient

Sure, I agree with that, but I think tombstones are already a decent solution that doesn't require protocol changes

Just remove the bookmark on <gone/>

yes. For me it just leaves some edge use cases unsolved

for some reason some users could want to destroy a muc to recreate it

but ok, we dont need a solution if we not yet have problem :)

> I'd like to express my frustration: equating the act of joining a group chat with creating a new one is quite misguided. I think this is a leftover from MUCs being quite explicitly modeled after IRC. ↺

^ this

In (old) IRC it makes sense as channels are pretty transient and quickly joining temporary channels is a nice way to have something like threads or break out rooms.

But it never translated well to XMPP.

This is still entirely dependent on how clients do things.

> I'd like to express my frustration: equating the act of joining a group chat with creating a new one is quite misguided. 💯 ↺