Thanks, but I understand that Zulip is technically capable of all of these things—that doesn't change the fact that it's still a very, very common frustration any time an org links to their Zulip channels. So it's clear that the additional setup required to go through Google auth review, get API tokens, test the integration, etc is just not feasible or reasonable to expect for many self-hosted admins.
> That said, we are planning to create a Zulip Cloud SSO option that would allow users in the many communities that aren't picky about authentication to use a single login for all their Zulip Cloud organizations
Would this be easy and accessible for self-hosted installs? e.g., can self-hosted installs now use Zulip Cloud auth out of the box with no further setup? Maybe even have it enabled by default for open organizations? That seems to be the biggest problem with the existing social login schemes. Defaults matter a lot, and if Zulip continues to ship with "Slack-like" defaults instead of "Discord-like" defaults, it's going to continue to be just as frustrating to see Zulip links on org websites.
> Open organizations can also set any channel to be publicly accessible without logging in, which I'd expect to be useful for something like FUTO: https://zulip.com/help/public-access-option.
Again, I understand that this capability exists, but it's very complicated for administrators to enable, and requires an explicit opt in for EVERY individual channel that is made public in this way, which means in practice it's very rare.
Having a good web-public organization requires a long list of steps:
1. manually editing the server config files to enable the feature.
2. having an administrator enable the option for the org.
3. having individual users remember to set channels as web-public every time they create them.
4. having an administrator audit popular channels and make sure they're set to web-public if necessary
I think many organizations would be better served with a "public channels are web-public by default" option that does NOT require editing config files or manually changing settings for every individual channel.
The distinction between "this channel is public and anybody can sign up for an account to read it" and "this channel is public and anybody can read it" is very, very slight and while I can see the value of making that distinction on an org level, I do not expect 95% of open-source orgs to have the policies / guidance necessary to enable users to confidently make a fine-grained distinction on a channel by channel level. This means that the distinction between public and web-public adds a lot of cognitive overhead and basically leads users to choose between those privacy types at random, unless their org has a "all channels must be web-public" or similar policy (like rust-lang does). In fact, checking the docs now, it looks like normal users can't even create web-public channels, so other orgs can't even replicate rust's policy without restricting who is allowed to create channels.
Unfortunately, both of these features fall prey to very common open source UX traps—having a bad out of the box experience (no SSO) ruin a user's first impression of your project, and having too many customization options, leading to user confusion on which settings to use when.