Ejabberd: Mark a MUC as destroyed and block access

[zuglufttier]

What version of ejabberd are you using?

18.06

What operating system (version) are you using?

FreeBSD

How did you install ejabberd (source, package, distribution)?

From ports

What did not work as expected? Are there error messages in the log? What
was the unexpected behavior? What was the expected result?

If you destroy a MUC many clients will ignore that if they are not online at that time and recreate the MUC because of a bookmark.

So, it would be nice if a destroyed MUC would be marked somehow so that it will not be recreated by users that join by bookmark.

A config setting might block the recreation forever or for a given time.

[badlop]

You can use access_create to dsallow normal users create rooms.

access_create: AccessName: To configure who is allowed to create new rooms at the Multi-User Chat service, this option can be used. By default any account in the local ejabberd server is allowed to create rooms.

Or, instead of destroying a room, set a password so nobody can join it, then send a room message indicating that the room will not be used anymore, then kick the existing occupants, and finally set the room name to "Room blocked".

[zinid]

@badlop we already discussed this in ejabberd@ room, the feature request makes sense.

[zuglufttier]

@badlop, you are right, I told someone that he could do these things to block a room because some clients would always reconnect to the room. But it's far from transparent for a user and considering the amount of different clients, which may or may not listen to a destroy event, I think, it's better to provide a solution that will work automatically across all clients.

Also, prosody has it :D https://issues.prosody.im/1182

[badlop]

I've comitted a proposed implementation. Try it and let's see if it provides the mentioned featured.

[zuglufttier]

Looking good so far! @weiss and me tested with gajim and conversations. The user gets notified that he is not a member of that room anymore if he tries to join or create that room.

[zinid]

The patch is terrible. Synchronous calls to room processes is evil.

[zinid]

Also, this is clearly an abstraction leakage: mod_muc now knows about mod_muc_room internal state, wtf?

[badlop]

Two more things I don't like about that implementation is that it reuses the room password configuration field to store the tombstone expiry, and that it reuses the room title to determine if it's a tombstone. The benefit is that it doesn't require changes in data structures and naturaly works clustered.

Any alternative ideas are welcomed.

[licaon-kter]

I've got these in my logs:

[error] <0.392.0>@mod_muc:handle_info:325 {timeout,{p1_fsm,sync_send_all_state_event,[<0.396.0>,check_tombstone]}}
[error] <0.392.0>@mod_muc:handle_info:336 unexpected info: {#Ref<0.xxxxxxxxxxxxxxxxxxxxxxxx.xxxx>,not_tombstone}

[zinid]

@licaon-kter this is expected, because, as I said above, the code is lame.

[zinid]

I would prefer not to release it in 18.09 by the way.

[lovetox]

Very useful feature, please consider adding this

[weiss]

You can emulate the desired behavior by enabling (and optionally enforcing) MAM archiving for new rooms, and then configuring mod_mam to keep the archive on room destruction (by setting clear_archive_on_room_destroy: false). ejabberd will then forbid (non service admins) room creation as long as the archive is non-empty.