Investigate adding support for multiple organizations

[timabbott]

This is likely to be a fairly big project, but I think it's one of the most important large structural changes that zulip-terminal may want to make.

There's an argument that we don't need this feature, because one can just run multiple copies in different terminals (or terminal tabs within a window). But I think there will certainly be users who'd much prefer to have a single terminal user experience.

So I think it's worth doing a bit of investigation/planning into what would be required to support being logged into multiple organizations in zulip-terminal.

[neiljp]

Do we have particular users who want this feature? There has been mention of this in the past, but like you say this is easily achieved with multiple terminal sessions. This is documented in the FAQ as it stands.

One part we could certainly improve is to handle profiles better, rather than just encoding everything in the zuliprc, which should be a lot easier to handle now that we're at python3.6+ and can use xdg with #678. For that we could have a command-line positional parameter as the name of the profile, which would be simpler than locating the zuliprc each time.

[timabbott]

I think basically anyone who uses Zulip in their own community and wants to have chat.zulip.org open as well wants this. And there's a bunch of projects, like Rust, that have a constellation of Zulip organizations (one for the Rust language, and then individual ones for different libraries).

There is prior art for putting multiple things in a zuliprc file: https://zulip.com/api/deploying-bots#running-multiple-bots-using-the-zulip-botserver, so I don't think the configuration part of prototyping this needs to block on migrating to xdg.

[neiljp]

I'm not denying that the feature of having multiple ZTs open is desirable, just suggesting that having that occur in the same process rather than being handled elsewhere by a system that already handles it well (tabs/windows) is much lower priority.

While we do have an object model that could lend itself to multiple organizations, and tidying that up to support this would be a good project in itself, there are other aspects that need more attention.

The point with #678 would be to improve the current experience (one ZT per terminal tab/window) and allow for different configuration styles, including eg. having users download a zuliprc from a server and simply saving and renaming it to get a profile, perhaps centralized config in one file, and per-profile config in the renamed zuliprc files. That as well as generating config files. All of that is a project in itself. The use of xdg is mainly to ensure things are stable and standardized.

Perhaps one preliminary solution here could be to have a launcher(/switcher) to improve the UX, which would fire up one or more sessions at the start or on demand. However, it'd need to interact with the system/terminal to know how to open them. There's likely only so much that can be automated in that regard - so I'd really like to understand specific use cases, for example whether these are users who don't use the command line but want a terminal UI? How much terminal knowledge to assume, for example?

[dehnert]

FWIW, historically I think I'm a lot more likely to read any of chat.zulip.org if I'm reading it in a client I'm using for other things. I don't think I've ever kept a tab open for long, but when it can live in my Barnowl or Snipe session that I'm also using for Zephyr and possibly other Zulip realms, it's (maybe?) stuck. (I haven't continuously used a chat client that supports Zulip + other things for very long -- Barnowl's support broke a couple times, and Snipe is recent -- so it's hard to be sure it'll really stick for months.)

My guess is that for, eg, "multiple, low-traffic zulip realms", being able to view them in the same terminal app, with "All Messages" showing them all and n cycling between unread topics, could be quite compelling. (I'm a longtime lover of the "All Messages" view, which may be relevant here.)

(OTOH, I'm not a real zulip-terminal user and don't really expect to be one soon, and I don't know that you're really at the "features for hypothetical users" stage of things...)

[neiljp]

@dehnert This sounds like two aspects:

1. if all configured profiles are as easy as possible to get to, up to the point where connections just start up automatically, then the user is more likely to stay connected with that community
2. having multiple profiles in the same client would enable treating multiple communities with a "shared inbox" experience, eg. n cycles through all organization "feeds", or even interleaved with pinned streams from each first, or other variants

Does that summarize what you're saying?

[dehnert]

Sure. I think the second is significantly more important, though - if it's one more place to check, even if it's equally easy, I think it's likely to fall by the wayside.

[alok]

fwiw, i'm an end-user who came looking for just this feature

[neiljp]

@alok Thanks for letting us know, but just to clarify, which feature of the 2 I mentioned above?

[alok]

2

[neiljp]

@timabbott Did you envisage this as point one or two? Point 2 isn't available in other clients, so I'm guessing you meant point 1.

I'm thinking we could split this up to allow focus on one or the other - though of course one does depend on the other.

[timabbott]

Approach 1 (basically analogous to the Zulip desktop app -- where you can see unreads for each connected organization and easily switch which one you're looking at content for) is easier to build, and is what I'd start with because it's a subset of the work for approach 2, but it'd certainly be cool to build something more in the "approach" style. (I imagine that would mostly be a single sidebar with all unreads across the user's organizations).

So I'd recommend scoping this issue's work to approach 1 and then revisit approach 2 once that is done.

[Juliaria08]

Approach 1 (basically analogous to the Zulip desktop app -- where you can see unreads for each connected organization and easily switch which one you're looking at content for) is easier to build, and is what I'd start with because it's a subset of the work for approach 2, but it'd certainly be cool to build something more in the "approach" style. (I imagine that would mostly be a single sidebar with all unreads across the user's organizations).

So I'd recommend scoping this issue's work to approach 1 and then revisit approach 2 once that is done.

If possible, when approach 1 is done, add a configuration option to enable or disable approarch 2, maybe even add an option to group the instances, so "Rust" (example) servers can be selected all using approach 1 and then it'd display it using approach 2, but if you want you're able to select to specifically connect to a specific server or to a group of servers. (groups would be created by the user) (for example for a specific rust library's server when you don't want to waste battery or get distracted (for laptops, not connecting to every server when starting up might be neat, but I guess that's another feature), or if you want to login to your company's only server and don't want to see more servers joined together) but I guess that would be more work to build.

[neiljp]

I agree that it will be important to control

• how many organizations (of those with configs) one 'multiplexes' in a given session (and whether they connect manually/automatically) - approach 1 (multiplexing)
• how many open organizations in a given session are 'integrated' - approach 2 (integrating/combining)
• whether integration is a toggle of all organizations in a session, or further into only certain groups of organizations within a session, which would likely be 'approach 3' (or 1+2, depending on the UI)

[neiljp]

Assuming we retain zuliprc files or their equivalent, at least for authentication, an extension of the plan in #678 in https://github.com/zulip/zulip-terminal/issues/678#issuecomment-808967514 seems feasible. The premise would be:

• 678: named configuration sub-directories under an xdg root, each with a zuliprc file created by ZT or via the web app (possibly with org-specific config in those files or separately in those directories)
• 678: those directory names would be the organization reference to connect to; as of now that would enable eg. zulip-term czo or zulip-term rust instead of needing to specify configuration file locations, depending on the directory names in the xdg config root
• 678 extension: support aliases in a common config file in the xdg root, so that eg. the zulip web app could save to a unique name such as chat.zulip.org-some_name-2504-86325982/ ({url}-{name}-{id}-{time_or_version}/) or chat.zulip.org-bot45-993013-3/, but then ZT could map that to something memorable for easy usage like czo and czo-bot - and if an API key was reset and redownloaded, then only the alias would need to be changed
• approach 1: once the code can support multiple simultaneous servers cleanly, add a 'multiplexes' section to the aliases config file, each entry being a new alias based on a list of base organization directory names or aliases. We could also support optionally auto-populating via aliases and searching for zuliprc files, and if in the same section the alias would be configurable (all? browse? allofthem?). We could still support the individual connections, but also eg. zulip-term oss via something like

  [multiplexes]
  oss=czo,rust  # like the mobile app and switching between specified servers
  work=devs,sales
  allofthem=*  # optional

• approach 2: similarly we add an 'integrated' section: new aliases that are a list of base organization directory names or aliases, whose messages should be shown in a combined view
• approach 1+2: support using integrated alias names in the multiplexes section, so one could eg. switch between czo and an integrated view of the rust servers

I think we'd need to wait for 1+2 to know if a distinct 3rd approach would be a desirable use case, but we could add a 'groups' section: aliases for organizations to show visually together, maybe ordered, that could behave half way between the switching of the multiplex approach and the full combination of the integrating approach. Maybe like a client version of the proposed server stream-groups feature.

[dehnert]

1. if all configured profiles are as easy as possible to get to, up to the point where connections just start up automatically, then the user is more likely to stay connected with that community
2. having multiple profiles in the same client would enable treating multiple communities with a "shared inbox" experience, eg. n cycles through all organization "feeds", or even interleaved with pinned streams from each first, or other variants

[...] Point 2 isn't available in other clients,

FWIW, an interleaved view (within or between organizations) may not be available for clients of other chat systems, but the equivalent of "n cycles through unread messages across organizations" is -- A-S-up/A-S-down in the Discord webapp cycles through unread messages across servers. (The fact that the Discord webapp supports multiple servers in one tab and cycling through the messages with a keyboard is a significant part of why I think Discord is a better fit than Zulip for social group chat, where people aren't getting enough value to justify keeping another tab up... Of course there's technical reasons why doing that for Zulip webapp is hard.)