Livestream and Live Events

This guide is designed to provide general best practices for the Livestream and Live Events use cases.

The Livestream channel type is designed to be used in a Livestream setting and has pre-configured permissions that do not require membership as a registered user to read or write to a channel. This channel type is “open” to any user accessing it with an authorized JWT. Users are not required to be added as members, which saves complexity and additional updates to the channel through the membership endpoint. The channel can be “watched” by users in order to receive real-time updates on the activity (new messages, etc) in the channel. 

Live events, by contrast, may sometimes be well suited for the Livestream channel type, but frequently require membership for interacting in channels. Creating a new channel type with similar settings to the Livestream channel, but with some tweaks to tailor to your event platform's needs, may be necessary.

A performant website or mobile app can easily be degraded or overwhelmed by excessive API traffic. The Stream API has been designed with this in mind with features to protect clients (see throttling and slow mode). However, we still recommend taking these additional steps. 

Certain features that are beneficial to remove for Livestream type settings (in order of performance impact) are

1. Read events

2. Typing indicators

3. Connect events

4. File uploads

5. Custom messages

The Stream Chat API automatically starts throttling typing and read events at 100 watchers in a channel, but it is good practice to remove these from the start, as even 100 very active users can be problematic. It's also worth noting that typing and read events lose their value in user experience as active users rise.

The Stream API will begin to throttle messages at >5 messages per second and some messages will not be delivered to all clients watching a channel to protect the client from degraded performance. We also recommend considering Slow Mode for events in which traffic is expected to be particularly high. 

An additional measure that can be taken in order to keep the messaging volume at a level that is readable for all users, is “sharding” users into several channels. For example, you might create a channel per state, based on your users address, or even just create a new channel after N users to construct your shards. When done properly, this can give users the impression that they are in a much larger channel, but maintain an experience that allows each user to contribute meaningfully.

It is common for guest or anonymous users to be integrated into Livestream channels. These users have access to fewer permissions by default, but this is entirely configurable. Guest and Anonymous users do not require a signed JWT from a server.

Stream recommends that users are “pre-loaded” into the Stream API prior to the event. This prevents registration/upsert bottlenecks at the start of the event. In particular, for channels that may have large member counts, it is advised to add members to these ahead of time. 

If this can’t be achieved, based on your app's use case, then we recommend batching users being added to Stream and members being added to channels. Both upsertUsers and addMember endpoint accept up to 100 user_id’s in a single API call. 

Lastly, if this isn’t possible, and you expect to exceed rate limits, please email https://getstream.io/contact/support/ with your use case and we may seek to make an exception for your application to avoid any disruptions.

There are several methods that will trigger an API call to /channels. Watch, query, and create. Only one of these is necessary and additional API calls quickly add up and can be problematic. Filtering and sorting generally are not issues for this use case, but for more information on optimizing these queryChannel parameters, take a look here.

Using a Virtualized list on a web platform is a recommended means to cap the number of messages stored in the DOM and have proven to significantly improve client performance and protect the quality of a video stream. For more information on the Stream Virtualized list components, take a look here. The key caveat to the Virtualized List component is that messages should have a fixed height, which can make images, emojis, and custom messages types problematic.

Stream provides a number of moderation tools that can be useful in a Livestream setting:

1. Users flagging messages - Any user has the ability to flag another user’s message. Flagged messages are currently sent to the Stream Moderation Dashboard and flagged messages also trigger a Webhook event. 

2. Moderation Dashboard - available to all customers and includes a chat Explorer, Flagged Message review area, and a number of API driven features to ban or delete users. 

3. Block Lists - a simple but powerful tool to prevent lists of words from being used in a Chat. These are applied on a Channel Type basis and either a Flag or Block behavior can be defined. 

4. Pre-send message hook - a customer-hosted solution that provides a means to host your own moderation solution that can hook into any 3rd party solutions, have Regex filters, or more advanced filtering based on your own criteria. 

5. AI Moderation - currently in beta testing currently. Please reach out to https://getstream.io/contact/support/ to learn more. 

6. Image Moderation - an addon to Enterprise packages and will flag images that are deemed to be inappropriate by the moderation logic.