Skip to content

Instantly share code, notes, and snippets.

@Zirak Zirak/gist:5644118
Last active Jun 30, 2016

Embed
What would you like to do?
Permission system

Overview

Current situation: A small amount of users annoy the lot of us, we have no power to ban them, mods are annoyed.

Official solution: Go into Gallery mode, so all users can view, only users with explicit write permissions can write. This has the problem of approving users. We don't want to manually approve nearly everyone just to disapprove a small number.

Wayward solution: Use Gallery mode with the bot. When a user enters the room, the bot grants him write access automatically. As it's automatic, the transition is nearly seamless. An owner can then use the bot to ban a user. In that case, the user has his write privilege revoked, and will not be granted write access the next times he comes.

Bot interface

(For an explanation how it functions with the chat, see the file below)

Unmuting

/unmute username|usrid

Gives the user write permission. If he was muted, the mute is undone. Plain and simple.

Muting

/mute username|userid [duration=1h]

Takes away the write permissions of a specified user (you can only use a username if the user's in the room, otherwise you must provide a user id).

The duration parameter is debatable: Both in syntax and in default value.

  • Syntax:

  • My offer: One of nd for n days, or nh for n hours.

    • Jan Dvorak: In addition to that, nm for n minutes.
  • BenjaminGruenbaum: 1y1M1d1h1m (instead of 1, any number of course, or omitted for 0). Enables fine-tuning, which might not be necessary.

  • Florian Margaine and rlemon: Argument will just be in minutes.

  • Default value:

  • rlemon and I: Permaban

  • Florian Margaine (and Benjamin Gruenbaum?): 1 day

  • phenomnomnominal and Jan Dvorak: Incremental (each default ban increases according to the last ban)

  • Gordon and twiz: Argument is required. You have to specify a duration.

How the system works internally

Whenever a user joins the chat room, the chat fires an event which looks like this:

{
  "event_type": 3,
  "time_stamp": 1364308574,
  "id": 16932104,
  "user_id": 322395,
  "target_user_id": 322395,
  "user_name": "Loktar",
  "room_id": 17,
  "room_name": "JavaScript"
}

(Don't worry Loktar, nothing confidential is revealed) The bot listens for these kind of events. When it sees a new user (a user the bot hasn't seen before), it asks SO for user information, which looks like this:

{
  "id": 322395,
  "name": "Loktar",
  "email_hash": "710a392a974ed826ed96407788e0df5e",
  "reputation": 12738,
  "is_owner": true,
  "last_post": 1369450614
}

...and registers the user in the bot.

After the user registered inside the bot, OR if the user who joined was already recognized by the bot, an internal event is fired. The room authorization system listens to this event. The system receives two pieces of data: The information presented above, and the room the user joined to. A simple check is then made (python pseudo):

def permission (user, room):
  if room == gallery_room and not bot.hasPrivileges(user) and not bot.isMuted(user):
    giveVoiceTo(user)
  • First, room == gallery_room check is to make sure we don't try to mess with permissions of other rooms
  • Then, not bot.hasPrivileges(user) checks if the user is an owner or moderator. In that case, user already has rw permissions, and explicitly giving it to them causes a demotion (in case of an owner. see this for everlasting shame).
  • Finally, not bot.isMuted(user) checks if a user was muted, in which case we shouldn't do anything.

giveVoiceTo(user) does a simple http request to a special part of the chat in charge of permissions, and grants the specified user read-write permissions.

@SomeKittens

This comment has been minimized.

Copy link

commented May 24, 2013

I like the bot solution. It might be useful to be able to set temp bans on users.

@Zirak

This comment has been minimized.

Copy link
Owner Author

commented May 24, 2013

The interface so far:

  • /mute usrid reason [duration] removes a user's write access. Duration is infinite by default
  • /unmute usrid re-grants a user's write access (maybe add a reason argument as well?)
@benjamingr

This comment has been minimized.

Copy link

commented May 24, 2013

I like the idea, I think duration should default to 30 minutes though, I don't want users banned for a long time by mistake

@AmaanC

This comment has been minimized.

Copy link

commented May 24, 2013

Sounds like a good idea to me as well. I'm not completely sure about whether moderators being okay with it is good enough, though. Might want to ask an actual SE employee

@ThiefMaster

This comment has been minimized.

Copy link

commented May 24, 2013

I like the idea. Certainly better than auto-binning someone's posts.

@AmaanC: Since it doesn't require mod powers at any point but just regular room owner permissions I doubt that anyone will have a problem with it. I'll ping someone from SE though.

@Zirak

This comment has been minimized.

Copy link
Owner Author

commented May 24, 2013

There's a side-effect to this that I haven't thought of before: Giving everyone write access by default also includes those who wouldn't have it naturally, i.e. users with less than 20 rep.

Should there be a rep check to imitate the existing state, or is that okay/desirable?

Edit: I was wrong, this did not give <20 rep users write access.

@benjamingr

This comment has been minimized.

Copy link

commented May 24, 2013

I think desirable, rep is meaningless in this context. Having the ability to quickly enforce such a limit is desirable though

@mainerror

This comment has been minimized.

Copy link

commented May 24, 2013

Sounds good. IIRC you can't give write permission to a user <20 rep anyway. Unless you're a moderator.

@simonsarris

This comment has been minimized.

Copy link

commented May 26, 2013

Note a huge fan conceptually, but if thee all please

@Shmiddty

This comment has been minimized.

Copy link

commented May 28, 2013

I think the duration param should just be in days, always. I don't see any value in having granularity there (why mute someone for 5 minutes, or even 5 hours?). This has the benefit of simplifying input (and the parsing thereof) a great deal. /mute 365 etc etc.

I also feel like we should have an optional (maybe even required?) note param for /mute so we can see why someone was muted.

@benjamingr

This comment has been minimized.

Copy link

commented May 28, 2013

Muting someone for 30 minutes is punishment, you tell them "This behavior will not be tolerated in our community", and usually gives them a chance to adjust accordingly before you mute them for a longer duration.

As the room is perfectly fine right
now, this is strictly theoretic of course :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.