5 ms·

Just a quick correction: Zulip supports logging in with your Google account (as well as GitHub, GitLab and Apple): https://zulip.com/help/configure-authenticati

Just a quick correction: Zulip supports logging in with your Google account (as well as GitHub, GitLab and Apple): https://zulip.com/help/configure-authentication-methods https://zulip.com/help/configure-authentication-methods. In Zulip Cloud, those options are enabled by default, but chat.futo.org is a self-hosted system, and I assume they either haven't done the setup work (getting API keys, etc.) for those authentication methods, or don't want to for policy reasons. As to why every organization has its own accounts, each organization has different people administering/controlling them, and separate accounts for different Zulip organizations is a lot cleaner of a security model, both for business customers but also for projects that are paranoid or opinionated about authentication options. 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. Feedback on how exactly you'd like to see that work is appreciated, especially in #feedback on https://chat.zulip.org https://chat.zulip.org, where it'd have the most visibility within our project. 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 https://zulip.com/help/public-access-option.

nightpool 2y ago
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 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.
- tabbott 2y ago
  If you have a bit of time, I'd love it if you stopped by chat.zulip.org to discuss this more interactively. I don't think we have heard any of them from other users, so feedback including a specific example of an organization or user who struggled with this would be helpful for us to debug your experience with this feature. For the thread, my understanding of the situation is: - The one-time setup steps for a self-hosted installation to enable web-public streams are a couple minutes of work, and to me seem immaterial compared to the minimum realistic effort for getting a server, getting a domain, transactional email provider, and SSL certificate, and then actually installing and configuring the server in the first place. - The default stream type when creating a new stream is web-public if the feature is enabled for an organization, for users with permission to create them. We don't allow normal users to create web-public channels as an anti-abuse measure. Trust me, you don't want it to possible for a threat actor to be able to sign up for an account in your open community, create a secret web-public channel with just themselves as a subscriber, and start hosting malware on your domain. I hate when anti-abuse concerns limit our ability to design features in the most convenient way possible, but that's life building products for the Internet. If anyone has ideas for how we can make this better, we'd love to discuss!

nightpool 2y ago

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 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.

tabbott 2y ago
If you have a bit of time, I'd love it if you stopped by chat.zulip.org to discuss this more interactively. I don't think we have heard any of them from other users, so feedback including a specific example of an organization or user who struggled with this would be helpful for us to debug your experience with this feature. For the thread, my understanding of the situation is: - The one-time setup steps for a self-hosted installation to enable web-public streams are a couple minutes of work, and to me seem immaterial compared to the minimum realistic effort for getting a server, getting a domain, transactional email provider, and SSL certificate, and then actually installing and configuring the server in the first place. - The default stream type when creating a new stream is web-public if the feature is enabled for an organization, for users with permission to create them. We don't allow normal users to create web-public channels as an anti-abuse measure. Trust me, you don't want it to possible for a threat actor to be able to sign up for an account in your open community, create a secret web-public channel with just themselves as a subscriber, and start hosting malware on your domain. I hate when anti-abuse concerns limit our ability to design features in the most convenient way possible, but that's life building products for the Internet. If anyone has ideas for how we can make this better, we'd love to discuss!