Channel Claiming

[MinusGix]

This is mostly an issue for discussing how channel claiming should work.

General Idea: The general idea behind claiming channels is to allow for better formation of sub-communities that have their own sets of rules and are able to for-the-most-part self-moderate without the help of site-moderators.

Claiming a Channel: A user with a trip (so that it can be tracked) would type the command to claim the channel they are in. (/claim, /claim-channel, /claim_channel, also would need to decide if you can claim channels you aren't in.. probably not). This would make them the Channel Owner. (This seems like a better name than Admin?)
I don't know how we would represent this. A crown next to the name if you want to stick with the emoji method?
The server would store that the user's trip owns the channel. (See: Tracking Information section for more).

Channel {Owner,Moderator}'s Abilities: Presumably the channel owner has abilities in relation to this channel. The basic idea would be to allow them to kick users and ban users from the channel.
Kick: The Moderator ability to kick is able to deposit them in a specific channel. This has more potential for abuse if channel owners can kick a user into another person's channel without that person realizing. Ex: kicking a user from the programming channel into the we-hate-programming channel would cause them to potentially break the we-hate-programming channel's rules of not talking about programming since they don't know that they've been kicked. There's two routes for this, I believe:
a) Tell them they've been kicked. This changes the behavior of the kick command a notable amount. This would introduce a slight annoyance to show that they've been invalid according to the channel's rules. I don't particularly like this method as its easy to automate past. Another solution would be making it a timeout, so they can't rejoin for a whole minute.
b) Simply deny the owner the ability to kick a user to a channel that is owned by another user. This solves the issue pretty easily, but would make so a channel owner couldn't do some weird irc-esque setup where they kick users to sub-channels based on their topic. (Ex: if you mention Java in programming they kick you to java-programming and have a bot repost the question). This could be allowed through making it an option for channels if they should be able to be kicked to, though it would be an uncommon thing anyway.

Banning: Banning would obviously be done on a per-channel basis rather than the whole site. Might want to give a better message than "You got disconnected".

Move User: I believe this says that you joined to the user, but does it say the channel? I haven't checked.

Overflow: Channel owners/moderators probably shouldn't get this? As giving that power makes it easier to abuse.

Lockroom: This is useful. Requires a per-channel tracking of authorized trips. Would also allow whitelisted channels automatically. (The default uses blacklisted channels, via bans)

An owner would be given the ability to disclaim ownership of the channel. Two separate ways of removing ownership. Giving it to a specific user (keep channel-moderators), or just completely removing ownership (and so any channel-moderators are also removed).

Potentially have a way for them to 'ping' a site-moderator?

Delegating Power: For sufficiently large channels, the owner can't do everything themselves and would probably want to delegate power in some way. So, you could go for a fancy multiple role system like discord or a simple: there's an channel-owner and there's channel-moderators. The simple method would be easier to code, and more immediately useful as discord's role system would require a complicated permissions system.
For channel-moderators (chan-mods, or you could go for another term to avoid confusion with site-moderators, 'police' is one I've seen before, 'enforcer') the powers would be a subset of the owner's though probably pretty similar. Kick, ban, move user, etc.
Unsure what symbol they would have to uniquely signify them.

Decomposing Rights: The rights to the channel need to decay.
Perhaps:

• If a channel owner hasn't been on a mostly inactive channel (3 users? we don't want to keep track of too many channel specific stats probably) for.. a week? a month? two weeks? it gets reverted back to no one owning it.
• If a channel owner hasn't been on an active channel which has moderators they appointed then the right to ownership goes to the eldest mod? You could make so they can reclaim it if they come back from that moderator..
  Designing this to be perfect isn't an exact goal, and we probably don't want too many stats to keep track of and try to calculate if the ownership should transfer.

Tracking Information: The server obviously needs to track the information about the channel's owners, channel-moderators, etc. So, how should it do this? Obviously it needs to keep the information over reboot (I mean you could have it clear everything and then leading to mass reclaiming of channels by quick users.. but that isn't really great even if it is amusing).
JSON is obviously the simplest format to use, and is already used for things like configs and being natively supported by javascript. So, should it be a massive object that is put into a file with all the channels and channel information? That could be big and if you're claiming a lot of channels it could make starting the server rougher as it reads the entire file and parses it. As well as having to serialize it all when saving.
There's individual json files, but channel names can be rough and so probably shouldn't save the json files with their literal names which makes life harder. I could imagine ways around that (ex: just incrementing a number by one for each new channel and then having a file with a mapping of their channel name to the id for the file).
Personally, the massive json file is probably easiest, and at least at the moment we're unlikely to hit anything huge with it.

For the code, it will have to track information, which can just be tacked onto the socket as we've been doing since they are separate per channel.
Having a global variable with all the channel information could work, or just putting it onto the server object would work better. Likely a good idea to make it a class with a bunch of utility functions for {adding,removing,messing-with} channels.

There are other ideas which would need to be thought of. Ex: Site-Moderators capabilities (can they channel-ban on any channel or just sitewide ban? if we use the UAC, they would be able to.), should alerts that a user has been banned in a channel you own be sent to you if you're online on any channel, the permissions structure, whether it should wait for a good command parser to be implemented before trying to implement a lot more commands, more commands should also probably be implemented so that a channel owner can do /ban user instead of opening their developer console, etc.

[ArteomBalanuta]

Communism

[raf924]

Didn't read everything cause ugh. On the topic of kicking. Maybe the command should be split: one for kicking into a random non-claimed channel and one for moving to a specific channel (with optional approval from the destination channel owner if there is one).

What do you think?

[henrywright]

For tracking information I'd suggest having a folder for each channel named by hashing the channel name. Each folder would store a json file

This would solve the funky channel name file naming problem and allow more things to be added in future. For example each channel may have a channel icon.

Reading from and writing to a single monolithic json file could have problems

[henrywright]

For the claiming-a-channel functionality, I think multiple channel claiming should be avoided if possible. For example a user can claim a maximum of 1

[henrywright]

/report nick could be useful in the context of a given channel. It would notify either the channel admin if invoked by a channel mod or notify site mods if invoked by a channel admin

[henrywright]

I agree decaying privilege is difficult to get right. Inactivity isn't necessary the best signal. The user may be on holiday for example

[MinusGix]

For the claiming-a-channel functionality, I think multiple channel claiming should be avoided if possible. For example a user can claim a maximum of 1

This has the issue that it is trivial to log in with a different tripcode, and so there is not much use from limiting it to one. (Can't detect based on hash either). It would be possible to have the rule and keep an eye out, but its easy to violate it and would require the admin/moderators to look in to that to actually enforce it.

/report nick could be useful in the context of a given channel. It would notify either the channel admin if invoked by a channel mod or notify site mods if invoked by a channel admin

That could work, yes. Though, I think channel mods being able to call site-mods makes more sense.

[marzavec]

@MinusGix

Claiming a Channel

Yessir, by text command or ui option. "Admin" isn't a good label, we aren't Discord pretending people have "servers". As for marking level within the client; any one have any thoughts on making "flair" part of spec? This would work in the same way that "color" does, and may be locked down to priviledged users (chan mod/admin, global mod/admin). Or possibly available to everyone with reserved flair for indicating level?

Channel {Owner,Moderator}'s Abilities

As for kicking, I'd vote for B- though your mention of sub-channels is interesting. Might be something to consider in the future as an official option. I'd agree with @raf924, atm we can just leave it split and maintain the ninja shadow-kick.

Banning will have to be split as well. Legacy clients will just straight up be disconnected and if they attempt to join that channel again, they'll be denied access. V2 clients would get a unique event that closes that "subscription" and displays a notice. Maybe add a "reason" flag to both? This is relavent here and later in your initial post.

"Move User" command, along with the "move" command are, um, complicated. I don't wanna write a novel on the topic, but they don't play well with V2. Legacy basically has zero cares about it's state, but v2 is tightly coupled to it's state. These two commands can be made to work in v2, but it doesn't make sense that they should. Originally the "moveUser" command was added to pull people out of purgatory when a channel was locked. "move" was added on whim at the request of Zed, not sure why tbh. I'd have to vote that we remove both these modules and alter the "lockroom" module behaviour (which would be wonky with mulitchannels anyway).

"Overflow" isn't official spec and likely won't change.

"Lockroom", like mentioned above, would work the same- whitelists and all that you mentioned. However, instead of dumping into a special channel, I'd vote we just alter it to deny the connection all together. This simplifies a lot of issues and doesn't require a mod be watching the purgatory channel.

Good points about passing on ownership and pruning defunct mods, that'll be essential.

On pings and reports to global mods. . . Sure, seems reasonable. This kind of command along with claiming a channel will need to require the user to solve a captcha though, which has already been added into the package and will be made part of the official spec.

Delegating Power

I'd vote for simple and hope someone would build a bot to handle nuanced perms. A simple could could be added and then revisted later as well.

Decomposing Rights

If the rights decay and are then passed onto the next mod, I feel like this would invite abuse. Say, I add 100 mods, all trips that are mine, I then have 100 * decay time to control that channel. On a similar tangent, I suppose we will have to cap how many mods an owner can have. . .

Tracking Information

"mass reclaiming of channels by quick users.. but that isn't really great even if it is amusing" tbh that'd be hilarious. But I'd agree that it'd have to be multiple files or a config within a directory as suggested by @henrywright. Once decayed, simply remove the directory or file. Performance is a high priority; memory / storage / read & write lag on the join event will have to be taken into consideration.

Likely a good idea to make it a class with a bunch of utility functions for {adding,removing,messing-with} channels.

Such a thing is already in place here.

can they channel-ban on any channel or just sitewide ban?

whynotboth.jpeg

more commands should also probably be implemented so that a channel owner can do /ban user instead of opening their developer console

For sure, we can get text hooks on the rest of the modules, the v2 ui already hides mod commands if the user is unable to use them.

For the claiming-a-channel functionality, I think multiple channel claiming should be avoided if possible. For example a user can claim a maximum of 1

@henrywright Such a thing cannot be implemented without forcing verified user accounts, which is against one of the founding principles of this project. The extent of user tracking is limited to trips or userhashes, both are changed too easily too justify such a function. To prevent bot-claiming, a captcha will need to be passed for both claiming and renewing claims. Similairly, global mods should be able to remove or transfer ownership.

Welp, this turned into a novel again, sorry :(

[henrywright]

Such a thing cannot be implemented without forcing verified user accounts

I was thinking this should be based on the trip rather than registering a user account. What are the chances of a trip collision inside a hack.chat install?

[henrywright]

That could work, yes. Though, I think channel mods being able to call site-mods makes more sense.

I agree that would work well. In general a reporting feature is needed. This could be available to all users to report rule violations, abuse, bullying

[marzavec]

I was thinking this should be based on the trip

Ah, well, if it was me and I wanted to own more than 1 channel, I would just keep a list associating which trip I used to take ownership of which channel. So "limiting them" turns into "forcing them to have multiple passwords".

What are the chances of a trip collision inside a hack.chat install?

Approximately 1 in 4.3*10 to the 60th power

[henrywright]

Approximately 1 in 4.3*10 to the 60th power

Possible then lol

Ah, well, if it was me and I wanted to own more than 1 channel, I would just keep a list associating which trip I used to take ownership of which channel. So "limiting them" turns into "forcing them to have multiple passwords"

True but it would make it tedious for them to achieve

[MinusGix]

As for marking level within the client; any one have any thoughts on making "flair" part of spec?

Like an appropriately authorized user can specify their own flair? I mean, I guess, but part of the point of them was to properly distinguish Site-Moderators from normal users changing their nick color. So that would just create the issue again.
Though, the v2 client would be able to display some unique identifier for actual site-moderators/site-admins.
But, having flairs that can be set by channel-owner/channel-mods would be useful for fancy things in channels.
So, how would you uniquely identify Site-Moderators/Admin? Hover over their nick and it says it? Replace their trip with {Mod1, Mod2, Mod3, Mod4}/Admin?

However, instead of dumping into a special channel, I'd vote we just alter it to deny the connection all together. This simplifies a lot of issues and doesn't require a mod be watching the purgatory channel.

True. What could be done is simply don't connect the user (so no channel attribute on their socket, ex: joining-channel) and tell them to wait. This would notify a channel-moderator who could let them in with a slash-command. That way, no special channel, and you don't need to watch it as it simply alerts you. Probably, it would just essentially early exit in the join command as the channel is locked and you'd not be in the channel, when they let you in it just sets a flag to let you in and re-runs join command.
But, you'd have to have a way to tell that you don't want notifications, for cases such as complete whitelisted channels where they don't care that you're wanting to join, and cases where you're getting spammed by joins.
Isn't essential, but would be useful.
Oh, just realized that you could also just have them solve a captcha. They have to solve a captcha for it to notify a channel-moderator. "Please solve this captcha to request access to the channel from a channel-moderator."

If the rights decay and are then passed onto the next mod, I feel like this would invite abuse.

Yep, that is an issue. Though, it would also be an issue for an established community to have its owner disappear, causing all the channel-moderators to be removed, and then some random person claiming it quicker than the rest.
Though, you could do a shorter term where ownership can be passed to a requesting channel-mod. Ex: Ownership is completely removed in one month, but you can request ownership transfer after three weeks. So, a channel-moderator approaches a site-moderator and asks them to give them ownership. They join the channel, run a command to see if the owner has been away for the minimum amount of time (probably not listing the exact time so we aren't visibly tracking that due to it not being important for the mod, but you'd have to track it internally), and if there's other channel-moderators there they mention that they are willing to transfer ownership. This would be where conflict resolution happens if they don't agree on who becomes the new ruling owner.

True but it would make it tedious for them to achieve

@henrywright if I was wanting to claim multiple channels with a limit of one trip, I'd just append the channel name to my usual passcode. That way I know what pass to use on whatever channel I want to be active on at that moment. In my opinion the idea of the captcha before claiming a channel and channel ownership decay would be enough to make it tedious to abuse it.

[marzavec]

Oh, just realized that you could also just have them solve a captcha. They have to solve a captcha for it to notify a channel-moderator.

Same thing I was saying with;

On pings and reports to global mods. . . Sure, seems reasonable. This kind of command along with claiming a channel will need to require the user to solve a captcha though

Sounds like we've basically fleshed it out along with some good suggestions for new features. I'll leave this open until the feature is added in case anyone has any more thought.

[ghost]

I'm afraid channel mod isn't good 4 hack.chat. There will cause much more problems. And i think public channel's admin should be voted by global mods and admin. It is better than claim by everyone.

[ghost]

And how to make sure a person left here? If he away from hack.chat channel for 14days, delete his trip from config file. It easy to make a robot to join everyday, so we need captcha to prove he is human

[ghost]

And now some bots are able to pass capture. If it possible, we need hcaptha or recaptcha.
I seen spam robot go on joined even captcha is enable...