Details

    • Type: Improvement Improvement
    • Status: Not Yet Scheduled Not Yet Scheduled
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: ejabberd 2.1.8
    • Fix Version/s: None
    • Component/s: Multi-User Chat (MUC)
    • Labels:

      Description

      In moderated rooms, XEP-0045 says that roles should be persistent across visits.

      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).

      This is not currently implemented in mod_muc. I would be willing to work on a patch for this with some help.

        Activity

        Hide
        Badlop
        added a comment -

        Affiliations are kept for the whole room, but roles are kept per occupant. When an occupant leaves the room, his role gets forgotten.

        If roles are to be remembered in moderated rooms, for how much time should they? remembered forever, like affiliations? remembered also between mod_muc restarts? That probably requires a change in the room #state record.

        Right now, in a moderated room, an occupant can obtain a permanent affiliation or a temporary role. When an occupant gets a temporary role, he knows that the role is temporary, until he leaves the room. If you want the role to be persistent, then what you want is an affiliation. I see a concept incoherence in the XEP.

        Show
        Badlop
        added a comment - Affiliations are kept for the whole room, but roles are kept per occupant. When an occupant leaves the room, his role gets forgotten. If roles are to be remembered in moderated rooms, for how much time should they? remembered forever, like affiliations? remembered also between mod_muc restarts? That probably requires a change in the room #state record. Right now, in a moderated room, an occupant can obtain a permanent affiliation or a temporary role. When an occupant gets a temporary role, he knows that the role is temporary, until he leaves the room. If you want the role to be persistent, then what you want is an affiliation. I see a concept incoherence in the XEP.
        Hide
        Lee Boynton
        added a comment -

        The problem that I have is that the visitor role is not persistent across user visits to a room. So, when a user has voice revoked in the room, they can simply leave and re-join the room to regain voice. I think this is why the XEP says that roles should be persistent in moderated rooms, otherwise there is little point to revoking voice.

        I have made some modifications which adds roles to the #state record and so makes roles persistent, but only if the room is configured to be moderated. I can upload my patch if you want after I've cleaned it up a little. However, I have kept the role in the #user record for now so that code which accesses the role from the #user record still works.

        Show
        Lee Boynton
        added a comment - The problem that I have is that the visitor role is not persistent across user visits to a room. So, when a user has voice revoked in the room, they can simply leave and re-join the room to regain voice. I think this is why the XEP says that roles should be persistent in moderated rooms, otherwise there is little point to revoking voice. I have made some modifications which adds roles to the #state record and so makes roles persistent, but only if the room is configured to be moderated. I can upload my patch if you want after I've cleaned it up a little. However, I have kept the role in the #user record for now so that code which accesses the role from the #user record still works.
        Hide
        Badlop
        added a comment - - edited

        I imagine with your patch, when a new occupant joins the room, the room checks in #state.roles if that occupants has a role from a previous conversation, and sets that old role to be used in the current #user.role.

        After a few months, #state.roles will have a lot of old spammers, boycotters, trolls, ... Have you considered the possibility to implement some kind of auto-role-cleaning? For example, keep the timestamp of last user-role participation, and delete roles that weren't used in the last 30 days?

        Show
        Badlop
        added a comment - - edited I imagine with your patch, when a new occupant joins the room, the room checks in #state.roles if that occupants has a role from a previous conversation, and sets that old role to be used in the current #user.role. After a few months, #state.roles will have a lot of old spammers, boycotters, trolls, ... Have you considered the possibility to implement some kind of auto-role-cleaning? For example, keep the timestamp of last user-role participation, and delete roles that weren't used in the last 30 days?
        Hide
        Lee Boynton
        added a comment -

        Yes that is correct. You also make a valid point about old roles needing to be cleaned up.

        My version is quite specific to my needs; I only store roles which have been changed to visitor by an admin, and then these last for 5 minutes. My view is that voice should not need to be revoked for longer, because if that user continues to be abusive in some way then they should be banned and their affiliation changed to outcast. Is there not the same issue with #state.affiliations filling up with lots of old spammers etc?

        For ejabberd your idea about deleting unused roles after 30 days is probably more suitable. If anyone else is interested in this then I might be able to help write a patch with this included.

        Show
        Lee Boynton
        added a comment - Yes that is correct. You also make a valid point about old roles needing to be cleaned up. My version is quite specific to my needs; I only store roles which have been changed to visitor by an admin, and then these last for 5 minutes. My view is that voice should not need to be revoked for longer, because if that user continues to be abusive in some way then they should be banned and their affiliation changed to outcast. Is there not the same issue with #state.affiliations filling up with lots of old spammers etc? For ejabberd your idea about deleting unused roles after 30 days is probably more suitable. If anyone else is interested in this then I might be able to help write a patch with this included.
        Hide
        Badlop
        added a comment -

        Is there not the same issue with #state.affiliations filling up with lots of old spammers etc?

        Exactly, as tracked in EJAB-342. That's why I'd prefer to maintain or reduce the problem, not increase it

        deleting unused roles after 30 days is probably more suitable.

        I guess you planned to implement it something alike this:

        #state.roles = [{UserBareJid, Role, Timestamp}]

        and when the user attempts to join, apply to it the stored Role and update Timestamp.

        And then, periodically (when the room is started at ejabberd start?), clean obsolete roles.

        If anyone else is interested in this then I might be able to help write a patch with this included.

        If you implement the cleaning and attach the patch, I'll review it for inclusion in ejabberd 3. I guess that, as it requires a change in a public record for such minor feature, it won't be included in ejabberd 2.1. But anyway, interested e2 admins will find your patch here.

        Show
        Badlop
        added a comment - Is there not the same issue with #state.affiliations filling up with lots of old spammers etc? Exactly, as tracked in EJAB-342 . That's why I'd prefer to maintain or reduce the problem, not increase it deleting unused roles after 30 days is probably more suitable. I guess you planned to implement it something alike this: #state.roles = [{UserBareJid, Role, Timestamp}] and when the user attempts to join, apply to it the stored Role and update Timestamp. And then, periodically (when the room is started at ejabberd start?), clean obsolete roles. If anyone else is interested in this then I might be able to help write a patch with this included. If you implement the cleaning and attach the patch, I'll review it for inclusion in ejabberd 3. I guess that, as it requires a change in a public record for such minor feature, it won't be included in ejabberd 2.1. But anyway, interested e2 admins will find your patch here.
        Hide
        Lee Boynton
        added a comment -

        Will the patch need to be targeted to ejabberd 2.1 or 3?

        Show
        Lee Boynton
        added a comment - Will the patch need to be targeted to ejabberd 2.1 or 3?
        Hide
        Badlop
        added a comment -

        You probably base your work in 2.1.x or v2.1.8, you continue that way.

        I'll take care to review it, and adapt it to ejabberd 3 and exmpp.

        Show
        Badlop
        added a comment - You probably base your work in 2.1.x or v2.1.8, you continue that way. I'll take care to review it, and adapt it to ejabberd 3 and exmpp.

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Days since last comment:
              2 years, 44 weeks ago

              Issue deployment