I've got a problem with the naming conventions (1,2,3) for community types (open, closed, private). It creates a conflict where changes in these types will result in the creation of a new community/account altogether.
For example: if you'd like to change your open community to closed after creation, you will need to create a new one, even if it has thousands of active subscribers.
If there is no other way for whatever reason (instead of e.g. using the account metadata), then I could accept it, however, it is a nuisance.
Would be interested to hear some thoughts on this from @roadscape.
@therealwolf / @wehmoen - membership structure is a fundamental property of a community, switching between different types at will creates a lot of backend and frontend edge cases. Trying to keep the protocol as simple as possible, particularly for first version. Let's collect data first :)
Both options should be possible.
Integrating into "setProps" will need a little more logic to implement, since the op is also available to mods. It'll be a matter of adding a check for permissions, but it's not complicated.
A custom JSON op like "setType" would need even less changes to current logic to implement.
My thoughts were that maybe it's more an issue of making a community "immutable" in that current members who like it the way it is still get to keep it, while a new one can always be created for a new purpose.