MUC/Sub Persist Roles of a Subscriber

[partikmadan]

Is your feature request related to a problem? Please describe.
Currently roles are not part of subscribers list and not persisted in db.

Describe the solution you'd like
To make the role persistent just like affiliation.

Describe alternatives you've considered
Will look into updating the source code if there is no other way.

Additional context
As to implement a modern chat app i need to distinguish visitor from participants in a muc-sub enabled muc room. Currently i am not able to think of any solution for that.

[badlop]

Currently roles are not part of subscribers list and not persisted in db.

Right, that's exactly the definition of "role", it's like affiliation but non-persistent:

Role
A temporary position or privilege level within a room, distinct from a user's long-lived affiliation with the room; the possible roles are "moderator", "participant", and "visitor" (it is also possible to have no defined role). A role lasts only for the duration of an occupant's visit to a room
https://xmpp.org/extensions/xep-0045.html#terms-general

Then you propose:

To make the role persistent just like affiliation.

If I understand this correctly, this would go against the XEP, right? That is perfectly acceptable if you control both the server and the clients... But I doubt that would be acceptable for an open XMPP server.

[alepeino]

hi @badlop . According to the XEP

Roles are temporary in that they do not necessarily persist across a user's visits to the room and MAY change during the course of an occupant's visit to the room. An implementation MAY persist roles across visits and SHOULD do so for moderated rooms (since the distinction between visitor and participant is critical to the functioning of a moderated room).

Do you know if there are plans to implement the persistence of roles in Ejabberd? Currently if a moderator revokes voice from a user and the user leaves and re-joins the room, the role is back at "participant". Do you know of any other way to implement this as to honor the moderator's decission?

[badlop]

Just for curiosity, I've implemented it in badlop@58ca0a4 so you can apply that and try it

[alepeino]

thanks! I will give it a look

[badlop]

This feature goes against the XEP, and only one person asked for it, so it will not be included in ejabberd. Anybody interested, can find the patch in badlop@58ca0a4

[alepeino]

I really can't see how this goes against the XEP, given it says that the implementation "SHOULD" persist them for moderated rooms, which is critical to their expected behaviour. (https://xmpp.org/extensions/xep-0045.html#roles and quoted in my previous comment).

I do see if this is not a priority for Ejabberd right now.

[weiss]

Out of curiosity:

As to implement a modern chat app i need to distinguish visitor from participants in a muc-sub enabled muc room.

Why? Basically everyone else I've seen implementing modern group chat based on MUC doesn't care about roles but just uses affiliations, which are clearly meant to be persistent, without ambiguity/weirdness in the spec.

[alepeino]

hi @weiss ,

I can't speak for @partikmadan 's use case, but I can tell you about mine:

I'm developing a multi-user chat application targeted at education. Each class has a chat room, and in it the teacher acts as moderator. As such they can "mute" a student by revoking their "voice" (updating their role to "Visitor"). In that case the student should remain able to join the room and receive messages; it's only the sending of messages that becomes disallowed. That means the affiliation of the student remains as "Member". (Our rooms are members-only and only valid enrolled students can join them).

Since the privilege of sending messages is tied to the role and not to the affiliation I realized I needed a way to have the role change persisted between different user visits to the room, until the moderator decides to grant them "voice" back.

[badlop]

I really can't see how this goes against the XEP

Ah, right, I quick-read this thread again, and the term "temporary" always confuses me.

This issue got closed after several months awaiting feedback about the patch, and awaiting somebody else showing interest.

So, were you able to test the patch? What inconveniences did you find? Weird behaviour, etc.

[alepeino]

Thanks @badlop for getting back to this. No, I'm afraid I haven't been able to test it yet (and I lack the expertise to do so easily).

I'll probably get back to you in a few weeks. Until then feel free to dismiss the issue, given that no one else has shown interest in it so far. Thanks again!

[Neustradamus]

@badlop: Maybe good to reopen this ticket?

[based-a-tron]

I would like to second the request for this feature to be (re?)implemented. I found out the hard way that roles were not persisted for moderated rooms when a user was muted and subsequently rejoined, leading to a somewhat nasty argument. I think this is in line with the spec, going off of the SHOULD persist clause.

[badlop]

I'll quote myself:

This issue got closed after several months awaiting feedback about the patch, and awaiting somebody else showing interest.

So, were you able to test the patch? What inconveniences did you find? Weird behaviour, etc.

[based-a-tron]

I'll quote myself:

This issue got closed after several months awaiting feedback about the patch, and awaiting somebody else showing interest.

So, were you able to test the patch? What inconveniences did you find? Weird behaviour, etc.

I wasn't sure if you still needed feedback on the patch. We've been using it for a couple of days and the patch seems to work fine, thank you. We ran into one minor issue, and I'm really pretty sure it was totally unrelated to the patch, but in the spirit of honestly I'll disclose it: We had a user who was kicked from a room, invited back, and despite being present in the member list, was not able to join and was rejected with a "registration required" error. He had to be re-kicked and re-added. This is on ejabberd version 22.05 with erlang/OTP 24, with only badlop@8ca02f7 merged into the build.
My best judgement tells me this is an unrelated issue, but I can't be 100% certain.

[based-a-tron]

Ok, I see what's happening here. I'm not quite sure how to proceed.
When a user's role is set to None, they are kicked from the room, as expected.
But now this role persists, despite their membership status being kept after reinvite.
I don't think this is a bug, per se, this does seem to be in line with the expected behavior of the patch.
But it is slightly tedious for clients to deal with. The spec recommends kicking be done by only setting the user's role to None. This usually allows for them to rejoin immediately and be given the default role, as their membership is not changed.
Clients which kick by revoking membership continue to work fine, though this may be out of line with what the spec calls a kick?
I suppose clients could choose their own default roles to assign a user when inviting them, but I don't know, this might be kind of tricky. We could also not persist None roles. Let me know what you think @badlop

[based-a-tron]

We decided to just not persist none roles.
It seems to work well enough for us, even though its adherence with the spec is questionable.
I, personally, as well as my users, agree that this is the most sensible default behavior users of a chatroom application would expect when muting/kicking/etc.
I just changed

    Roles = maps:put(jid:remove_resource(LJID), Role, StateData#state.roles),
    StateData#state{users = Users, nicks = Nicks, roles = Roles}.

in set_role to

    Roles = case Role of
        % We don't persist none roles, so if someone is kicked from a MUC
        % they will maintain the same role they had *before* they were kicked
        none -> StateData#state.roles;
        NewRole -> maps:put(jid:remove_resource(LJID), NewRole, StateData#state.roles)
    end,
    StateData#state{users = Users, nicks = Nicks, roles = Roles}.

[weiss]

We decided to just not persist none roles.

Sounds sane to me. For persistent banning, affiliations should be updated.

[badlop]

Ok, then those two commits implement the feature, avoid the problematic cases, and are ready to merge right?

[based-a-tron]

Ok, then those two commits implement the feature, avoid the problematic cases, and are ready to merge right?

I believe so. I don't know if anybody else has been testing this, but we are having no issues with it on our service. 👍

[badlop]

Ok, I've committed those changes in ejabberd.