Disable Registration?

[mitchellurgero]

Not a problem, but more of a question and I cannot find anything in the wiki about this.

But I would like to disable registrations, so that way only accounts I create for people can be used to create channels. Is this possible?

[calzoneman]

But I would like to disable registrations, so that way only accounts I create for people can be used to create channels.

Do you want to disable account registration or channel registration? There's no core feature to disable these things, but you may be able to accomplish an equivalent result by setting max-channels-per-user and max-accounts-per-ip to 0 in the config (server administrators can bypass the max-channels-per-user check).

Beyond that, I don't know that this is an option I really want to support in core because it's a pretty niche use case.

[calzoneman]

Regardless, it should be documented in the wiki for others to find, so leaving this open for now.

[mitchellurgero]

Doing either would be good. I'll look at the config to see if there is something that can at least prevent channel creation, thanks! EDIT: Looks like setting both those options to 0 worked for me.

Side question, kinda related maybe?: Manual account creation?

EDIT2: To respond to use case, I just want to ask, how many admins do you think will want to keep their own sync server private (like a small community or something) I know I cannot be the first to think of this but who knows. I figured it would probably not take much to implement?

[mitchellurgero]

You could do something like this in database/accounts.js somewhere around line 115?:

if (config.allowRegistration !== true) {
            callback("Registration has currently been disabled by the Administrator. Please contact them for further details", null);
            return;
}

Or something like that (I only briefly looked at the code but I think something like that would be super simple to do?

[calzoneman]

You could do something like this in database/accounts.js somewhere around line 115?:

Disabling registrations in the database would be a good place to start, but ideally you'd also want to disable the registration page from being available at all, and provide some functionality for administrators to allocate accounts. An alternative approach would be to allow accounts to be created in some "unapproved" status and require an administrator to accept or deny the registration.

To respond to use case, I just want to ask, how many admins do you think will want to keep their own sync server private (like a small community or something) I know I cannot be the first to think of this but who knows. I figured it would probably not take much to implement?

The topic of wanting a single channel, or limited set of channels, comes up fairly often, but I don't remember if anyone else has mentioned disallowing user registrations. Everyone has their own tweaks or subset of features that they do or don't want. Someone wants only video, someone wants only chat, someone wants login-with-Facebook/Google+, etc.

It has less to do with how easy something is to implement, and more about whether I think it fits in with the repository. I try to keep this repository as close to what is running on the live server as possible and avoid these kinds of feature-toggles, because:

1. Features that don't get used on my live setup never get tested/maintained, so I'm prone to breaking them without realizing it. If I don't want to break it, then it's extra cruft that I have to drag along with me through every refactor or code change that affects that part of the program, when I don't even know if anyone uses it anymore
2. Attempts to make the configuration more flexible to support additional use cases has already made it sufficiently complicated that new users are often confused and come bother me for help understanding it

Thus, I generally prefer the model of people forking to tweak it for their needs. This keeps the maintenance of the patches colocated with the admin that uses them.

There's an underlying problem here which is that I never really intentionally supported the small-community-server use case -- I think of it more like IRC, where a community typically registers channels on an existing network, rather than hosting their own -- it's just that the lack of alternatives in the space lead a lot of people to this repository, which has always been "the open source version of what runs on cytu.be".

What works well for thousands of users/channels is not the same as what works well for 10, and I'm already running into this problem with, for example, the sharding support that was added to support dividing channels across many physical servers. I don't want to require everyone to configure a cluster just to get a server up and running for a small group of friends, but I also don't want to indefinitely maintain variants of if (clusterMode) { ... } else { ... }.

I've been toying with the idea for a while now that it might be preferable in the long run to split the functionality into smaller pieces that can be glued together in smaller meta repositories that provide the actual hosting environment for different kinds of setups.

[fredsif]

I've also been looking to do my own self-hosted cytube site but only for one channel, not allowing other users to create their own. The idea that new users can log into the chat with their social accounts could be implemented with sites, such as oneall. It's worth looking at it.

[calzoneman]

I've also been looking to do my own self-hosted cytube site but only for one channel, not allowing other users to create their own.

This goes in line with my above comment: I acknowledge that people have a desire for this kind of server, but the repository currently doesn't support that, and there are subtle considerations about supporting this kind of thing that aren't obvious from the simplicity of the request.

The idea that new users can log into the chat with their social accounts could be implemented with sites, such as oneall.

This is non-trivial. Basically everywhere in the code makes assumptions about locally-registered users.

Would it make the software more robust and fully-featured if it were refactored to support pluggable authentication? Maybe. Is this something I'm likely to have time and motivation to work on in the near future? Probably not.

[mitchellurgero]

Fair enough, you're the dev for this project so last call is up to you, thanks for discussing.

At the very least a Wiki page that can help admins "disable" registration. :) Cheers!

[calzoneman]

The workaround is documented on https://github.com/calzoneman/sync/wiki/Server-Hosting-FAQ. I'm closing this, because right now unfortunately I don't have the time to invest in making it an officially supported feature toggle.