Rocket.Chat -- Editions

[Sing-Li]

Rocket.Chat Editions

Rocket.Chat community -- your input and ideas are requested.

Rocket.Chat has been growing phenomenally fast since its inception. Both in features and community size.

As Rocket.Chat continues its dual-growth trajectory in 2016, the single edition approach may no longer be able to satisfy the requirements of its diverse users community.

Take as an example - while the recent addition of the (very large) LiveChat feature is a key to many users' adoption for Rocket.Chat; it has also been an unwanted burden for other users who may have no need to handle customer service.

Another example is the myriad of included single-sign-on schemes, with LDAP and SAML (being the most complex and large) that users with simple servers installation may never have any need for.

Coming up soon, are features that can control access via complex policies, plus log and audit every single operation performed within the chat system. These are features that are championed by the corporate sub-communities of Rocket.Chat, while despised by the pro-privacy free-and-untethered installs sub-communities.

Most relevant to myself personally, Rocket.Chat is no longer able to run on the original Raspberry Pi. And installations on 512 MB VPSes often crashes during normal operation due to "out of memory" condition.

It is clear, ONE SIZE NO LONGER FITS ALL.

It is becoming increasingly necessary to build, test, and maintain multiple Editions of Rocket.Chat.

The initial proposal is to support at least the following editions:

• Embedded A minimal core chat engine - designed to be easily embedded into another non-chat app
• Compact (Core Lean and Mean) Edition - smallest possible footprint, pro-privacy, with base features decided by community
• Full (Enterprise - kitchen sink included) Edition - everything included, standards compliant core, ready-to-activate
• LiveChat An inside-out edition of LiveChat - with messaging call-center features front-and-center, and team chat as an optional integrated feature.

But we would like to hear more about what you think about all of this before further planning.

Please comment and discuss.

[neurobe]

Edition: Payload - for non-chat centric, new, business oriented apps for which RC provides

• user management
• core suite of meteor apps
• chat window demoted to slide-in panel
• action manager and calendar as hooks for the payload activity
  RC is the start-here framework for new business & other applications.

[engelgabriel]

I like the idea, but the Community label alone doesn't say much. I'd go for:

• Minimal
• Standard
• Full
• LiveChat

or... we should be able do dynamically load packages. That may be possible with the new Meteor support for NPM.

[graywolf336]

I would like to see the more modular approach be the route we go. I foresee
there being a setup "wizard" when first ran and you can check the features
you want enabled.

On Wed, Dec 23, 2015, 6:20 PM Danijel Cole notifications@github.com wrote:

Great idea. For my use case, I'm looking for a minimal RC package. We have
a group based application already, we just want to plug RC into our
existing group system to enable team conversation.

I was just about to fork and reduce the code-base for my own purpose. But
if you guys are planning to make RC more modular, I will wait. I'd love to
help if i can, although CS makes it much harder for me to do so.

—
Reply to this email directly or view it on GitHub
#1741 (comment)
.

[Sing-Li]

@neurobe , @engelgabriel , @dcworldwide - thank you for the valuable input. I have updated the list of editions to reflect your comments. Please review.

Rocket.Chat community -- additional ideas and comments are welcomed.

[neurobe]

I am embedding my app into RC, rather than the other way around. This might be only possible for new apps (hey, there is a new app born every minute), but still, I think it differentiates RC from other less well structured chat apps. I am utilising RC's user management (and multi-language support et al) and will use its text/voice/video chatting, but that is not the raison d'etre of my app - which concerns health devices and giving the practitioner intimate access to both the client and the equipment. More generally, this app might fall under the category of 'distance education'.
There will be several slide-in panels associated with the technical control of the device. And I envisage that the main center page will switch between a chat window and the core display associated with the application (again, there will in fact be a couple of these windows). When this main window is switched it would be nice to be able to continue the chat in the slide-in window.
As an aside, I am 60+ and new to web technologies. Thought I might have been biting off more than I can chew, but RC came to my rescue. Thank you.
As a further aside, you may be interested to know that I am shoveling around data streams of 16kbps real-time continuous using arunoda:streams. No special buffering, just works, beautifully.

[neurobe]

Also, should not forget RC's multi-platform, multi-deploy infrastructure that I intend to ratchet. Wow. All in all RC provides a bunch of infrastructure that is highly appealing to independent devs of modern apps I would think.

[Sing-Li]

OT: wow @neurobe! Thank you for sharing. Comments like that mean a lot to us. The rest of the core-team will be on cloud 9 when they read it in a few hours. 😄

[neurobe]

I'm not sure whether the "OT" tag means I'm not getting thru here.
To take another tack, I think that independent devs (or wannabes) of multi-player games might very well light a rocket under RC 🚀 when there is an understanding of what it (and Meteor and Meteor Streams) bring to the the table. This is to underline that, IMO, RC-as-host to embedded apps has huge potential, together with what was alluded to above as "distance education" apps.
How does this or would this impact on RC architecture? Well, time will tell I guess. For myself, I need the ability to move the chat window aside, and to have an Action Manager to provide an interface between RC and the Payload app. Not sure I understand what it is, but out-going webhooks might be getting close, perhaps a subset of what I had in mind.
+1 for "RC-Host" (of payloads)

[engelgabriel]

Hi @neurobe

I fully understand what you are saying, and I am very aligned with the idea of Rocket.Chat as a platform.

I have seen the glimpse of it on the new HitChat... see the article below:
http://www.businessinsider.com/atlassian-hipchat-uber-integration-chatops-2015-12

[neurobe]

There you go!
So I see that "Chat Ops" has a wider interpretation than I had understood from reading posts here. HipChat might be targeting a few shiny apps to integrate (at least as a lead up to the IPO 😄 ) but it seems to me that for general applicability as a chat "platform", the client of the platform will need to modify source a bit to get what they want. Now how many chap apps are good and open source? 😺
So, how to facilitate this hosting of disparate payloads?
I'm at the edge of my known universe here, but if "webhooks" encompasses the notion of extensibility as I think it may then I guess we are good: extensible input stimuli, and extensible output actions, accessible to disparate packages.
I need a Calendar as one of the stimuli and there is $500 bounty sitting there for the next 6 weeks or so, at which time I will need to mash it up myself. It won't be pretty, and wont be part of a wider "Chat Ops" story, but will probably do the job for me. So I hope someone with a little more talent than me gets in first.

[engelgabriel]

We will take a look at the calendar soon, and we pretty much embrace the notion of extensibility for payloads. :)

[Sing-Li]

@neurobe ... OT = Off Topic ... 😄

Certainly - we aim to become the chat/communications platform of choice with a large eco-system of apps. That is even our headline slogan on the website for the last few months.

[sampaiodiego]

just to share some numbers I got.
I made two builds of rocket.chat, with and without livechat package and get this:

About the tarball size of the build:
with livechat: 23140050 bytes
without livechat: 22692793 bytes ( -447257 bytes = -1,93% )

Browser loading:
with livechat:

without livechat:

Total transfered:
with livechat: 844KB
without livechat: 835KB ( -9KB = -1,07% )

Loading time:
with livechat: 1,07s
without livechat: 1,02s ( -0,05s = -4,67% )

so, I think it's fine to add livechat package as default.

[Sing-Li]

Thank you, @sampaiodiego , for the helpful quantitative stats!

It definitely looks like there is NO NEED, at least for the next few months, to disable LiveChat on Editions that should include it.

To summarize, the revised list of proposed editions are:

• Compact (Core Lean and Mean) Edition - smallest possible footprint, pro-privacy, runs on inexpensive VPS configs, runs on Raspberry-Pi and other Embedded low-resource platforms, runs on non-Intel hardware -- with a 'minimalist' workable features set
• Standard Our current edition - includes LiveChat; configurable to be pro-privacy; runs on medium sized VPS configs, includes FULL feature set as determined by community members
• Pro or Enterprise Edition - includes LiveChat; includes all SSO providers, auditing capabilities, full access policy, compliance features, qualifies for PKI and other industry-specific standards; tuned for deployment by businesses or large enterprises

Rocket.Chat community ... please keep those comments and suggestions coming. We're wide open for your ideas on this one.

[Megatronic79]

@Sing-Li assuming all editions will remain opensource and free? - other OSS products when using the editions "Pro or Enterprise" usually start charging for that version?

[Sing-Li]

@Megatronic79 Yes. The intention is to keep the editions, "Pro or Enterprise" included, open source and free.

Support for all editions will be exactly the same as it is today. Community support plus optional professional support (from our community members as well as direct from Rocket.Chat).

Recent global-scoped FOSS projects have found great success with this model.

[Megatronic79]

Thanks @Sing-Li

+1 for dynamically loading of packages, think this would be a great option.

[Sing-Li]

@Megatronic79 - at this time, Meteor does not load packages dynamically. By design, Meteor packages are configurable only at build time.

We can engineer such a mechanism specifically for Rocket.Chat --> #1485, or wait for MDG to solve the problem (some Meteor community members already have some success with hacking webpack ). And MDG is trying to integrate at some npm level in 2016.

We have also considered the possibility of hosting a custom-build-service that performs customized builds on-demand.

More thought is needed on the combinatorial support matrix implied by such approach, as well as how realistically useful it may be - unless every features package comes with some "tested and well-documented" resource [compute + memory + db vs # of users] and dependencies profile.

[neurobe]

feedback on RC usage.
For my project I currently envisage up to 10,000 private channels each associated with an individual IOT device and 1..3 registrants per channel. No more than 5% on-line and active at any time. That is, the approvals mechanisms for private channel access will also be used for accessing the data streaming from the device. Chat inside this private channel will be occasional, whilst data streaming to and from the device frequent. (Of the 6,000 devices we have in the field today, we expect 2,000 of them to be able to switch over to the new RC software immediately.)
Supervisors will create a set of private channels for their clients. They have admin rights over the channels they create. Given that on occasions Supervisors will have control of 100+ private channels it would be nice to be able to group/sort/search or filter them - I think there is an RC issue open to searching public channels.

If there is something that someone sees is needed before this can happen, then I am happy to put a bounty on it. (Aside: a map showing location of those currently on-line would be a nice slide-in panel to have - think it go mentioned in the early days..)

Versions will run on embedded processors (ie smart toys (as client) and micro-computers HDMI dongles (as server)) as well as tablets and PCs. Don't see issues in doing this - instances of headless toys (as client) which don't need chat capability (the toys won't be that smart), but rather needing data streaming only maybe can exist outside RC as a standalone app, but then again a major point of the all this meteor stuff is to have a single code base.
Live Chat: not needed
Calendar to schedule events: needed
Thanks.

[haceru]

Greetings all, and thank you for the great work you are doing !

We are looking into using RC as a framework / platform to build on for a direct democracy (e-democracy) voting application and for this purpose, the modularity / custom built "setup wizard" approach would be awesome (like @graywolf336 suggested). Also, the planned npm support would make our life much easier.

Great work and great suggestions,
Thank you !

[engelgabriel]

There is this #1859 thread discussing the ideal of a package system. Maybe we should merge this issues?

[epatpol]

I agree with the dynamic modular approach, I think it would allow admins to specifically configure their instances the way they want. I don't even think a wizard is needed in most cases, simply a configuration file with the modules to enable/disable would be good enough in my opinion (I'm coming from inspircd so that's why I may be biased towards a simplistic solution).

Wouldn't that approach also make it easier for 3rd party developers to make their own modules/custom commands? I'm not familiar with the rocket.chat code architecture and such, so pardon me if I'm asking.

[engelgabriel]

Wouldn't that approach also make it easier for 3rd party developers to make their own modules/custom commands?

That's the main reason.

[engelgabriel]

Lets close this discussion about and concentrate the conversation at #1859 as it seems the way we will accomplish the modularity we want.