Co-Streaming Design Discussion


Streamers may want to directly collaborate with one another via a shared live experience such as a multiplayer game, tournament, challenge, podcast/panel discussion, etc. with their respective communities. Co-streaming should allow these creators to share their streams simultaneously with viewers on each participants’ channel.

Minimum Requirements

The base feature should cover, but not be limited to, the following requirements:

  • Streamers should be able to host a co-stream and invite other streamers to it.
  • Invitees should be able to accept, decline, or block an invitation.
  • A co-streaming-specific block list should be maintained and should include the chat blocked users list by default.
  • A host should be able to start or stop a co-stream. Invitees should be able to join or leave a started co-stream.
  • A host should be able to create/maintain a co-stream without the need to be live.
  • At the very least, two streamers should be able to co-stream and both streams should be viewable on the standard stream page.

Phased Approach

From speccing out this feature, it is clear that it will be a very large code change and such I believe it would be a good idea to break it into phases:

  • Phase 1 – base feature, create/maintain co-streams; invite others; basic qualifications; block list maintenance; join/leave co-stream; stream page modifications to view co-streams.
  • Phase 2 – chat relay
  • Phase 3+ – changes based on community feedback.

Phase 1

Main settings page

Here, streamers will be able to turn on co-streaming (off by default), turn on whether to use the tags/category defined by the co-stream when joining one, begin the “create a new hosted co-stream” flow, manage their co-stream specific block list, and be able to respond to invitations from other streamers or join a started co-stream they previously accepted an invitation for.


Streamers must meet minimum criteria to participate in co-streams:

  • Their account must be a least 5 days old
  • They must not be platform banned and their channel must not be deactivated
  • They must have an email-verified account
  • They cannot invite other streamers that are blocked in their chat or co-stream blocked
  • They cannot be invited by other streamers they have them blocked


Co-streaming is off by default as I strongly believe in a “opt-in” approach where it makes sense to do so. Using the category/title/tags defined in the co-stream should also be off by default since it is a destructive operation (it will replace the title/category/tags of the participants’ streams).

Launch Host a Co-stream Workflow

In an effort to keep the body of the settings page to a reasonable length, the process of creating a co-stream (hosting) should take place on a child page.

Co-stream Invitations

Here the streamer can see all the co-streams they have been invited to or accepted and they can manage their block list. In the actions column, the following buttons will be available depending on the status of the invitation:

Invitation Status Button Action
Pending Accept Sets the invitation to accepted status. Streamer is now visible to other invitees via the “Show Participants” button
Pending Reject Sets the invitation to rejected status. Only the host can see rejected invitations.
Pending Block Removes the invitation and adds the host to the block list
Rejected None Rejected invitations are hidden by default
Accepted Block Removes the invitation and adds the host to the block list. If necessary, will change the co-stream status from ‘ready’ to ‘waiting’ if there are no other accepted invitees

Manage blocked users

Allows the streamer to block or unblock other streamers from inviting them to co-stream. Note that streamers already blocked in your chat also cannot invite you to co-stream. Additionally, this blocking does NOT prevent you from participating in a co-stream with a blocked streamer if neither of you are the host.
The act of unblocking another streamer will re-enable all invitations (if any) and their status (accepted/pending) with that streamer.

Creating/Editing a Co-stream

For our purposes, creating a co-stream designates you as the “Host”. As the host, you dictate when a co-stream takes place, who is invited to the co-stream, and what layout the co-stream should adopt when viewed on the participants’ stream pages. Some points of note:

  • There is no limit to the number of streamers that can be invited to a co-stream. However, only a maximum of 6 participants can join at the same time.
  • The visibility of the participants’ streams will be dictated by the layout chosen. For “stacked right” and “stacked left” there will be 4 visible streams and 2 “swappable” streams shown as icons (“swappable” means viewers can, at their discretion, swap one of the visible streams for one of the invisible ones thus making it visible). For “host only”, only the host’s stream will be visible.
  • Co-streams can be long-lived – streamers are encouraged to “re-use” a co-stream they’ve created as often as they like.
  • The host can optionally set an appropriate category/activity/tags for the co-stream. This will allow participants to automatically use those settings if they desire. The title will also be automatically used but is required to create the co-stream.
  • Streamers can be invited as “Guests” – this means that their invitation will expire after they have joined and then left the co-stream. To join the co-stream in the future, they will have to be re-invited.

Stream page concept wireframe

Work-in-progress concept of the streaming page look and feel:

More Phase 1 Details to Follow

Any feedback/suggestions are greatly welcomed!


I think is an excellent, well-thought out approach. I especially like the ability to differentiate invites to a “Guest” with a one-time-use invite while also keeping the ability to have regular co-streams. The options around pending invites, accepting/rejecting/blocking, and all that are very useful and gives plenty of agency to both parties, which is an important thing. I also agree that opt in is important, and having basic requirements to be eligible, similar to front page feature slots.

I’ll definitely be reading over this again and thinking on it to see if I can add anything of merit! I’m especially interested in the conversations around chat further down the road, as well as channel moderation from the participants point of view. Excellent job, I’m looking forward to seeing where this goes moving forward!

This looks great. Very well thought out and it seems like you have a very nice roadmap of the feature set in place.

I look forward to seeing more

Looking great so far! I reckon that one thing to consider for phases 3+ would be layout options. Like the following with the 6 streamer maximum in mind:

  • Default: 1 stacked right, 3 stacked left and the 2 swaps.
  • Balanced Stacking: 2 stacked right, 2 stacked left and 2 swaps.
  • Focus: 1 main channel and 5 swaps.
  • Duet: 1 main with 1 secondary picture in picture and 4 swaps.

Something like that. Like how discord do video calls so maybe you can yoink some of their code :rofl:

Opt-in is pretty much a staple of Glimesh anyways so it suits perfectly.

Yep – I’m also open to suggestions on if there is a layout that could enable all 6 streams to be visible without the screens being too tiny to enjoy. Also, I just want everyone to be aware that I’m not sure what the performance of the streams will be like with many videos playing – so all this is aspirational.

1 Like

Initial Phase 2 Thoughts (combined chat)

Here are some of my initial thoughts on what a combined chat experience would be like. I haven’t dug deep enough into the inner workings of chat to know how realistic these goals are so please treat them with appropriate levels of skepticism.

Chat “relay”

  • Each streamer participating in a co-stream will have the option to turn on a “Shared Chat” experience. A minimum of two streamers must have this feature on for it to work. Only the streamers that have opted in to this will see the effects of it – viewers of other participants in the co-stream will continue to only see their own stream’s chat.
  • When enabled, chat messages will be relayed between participating channels and it will function as though the viewers in each chat were in one combined chat experience (ie. they will be able to talk back and forth and see the messages from the other chats).
  • System alerts such as Follows/Subscribes will not participate in the relay; they will only appear on the channel they are intended for with one exception (below).
  • Gift sub alerts may be the exception to this rule. If a gift sub crosses channels, I may be able to relay a special version of that alert since we don’t have direct messages on the platform. This is something I have to investigate further.
  • Emotes – I have to investigate how we handle subscriber emotes and whether they can be relayed from one chat to another or be available to viewers who are subscribed to multiple channels participating in a co-stream.


  • Moderation actions will continue to only affect the channel in which the moderation took place (which may not be the channel where the message originated). I think attempting to have these actions work across channels will lead to confusion, but I’m open to thoughts on this.
  • Chat originating from viewers who are banned on a channel receiving the relayed message will be appropriately suppressed.
  • Deleted messages will only be deleted in the channel where that moderation took place – it will not stop or “undo” the message from channels it was relayed to.

Chat bots

My goal is to do the best I can to not break existing chat bots on the platform. To this end, here are my thoughts:

  • There will be a new API boolean flag that will default to “false”. This flag will dictate whether an individual chat message will participate in any kind of relaying. This will enable me to set the flag to “true” on the website chat (to allow relaying to take place) while allowing bots to continue working as they do now (their messages will only be viewable in the channel they originated).
  • There will be a new API variable on incoming chat messages that identifies the source channel id of where the message originated. This will allow bot authors to update their bots to ignore commands that were relayed from other channels (if desired). In the absence of changes, existing bots will likely respond to relayed commands but their response will not relay back to the viewer who typed the command in. This can be annoying to the streamers if your commands generate chat messages so I’d recommend making sure your commands have a cool down period on them.

And as always, thoughts and feedback are welcome!

What would be really handy if there was some shortcut keybind for easy functionality to allow for quick tabbing through each stream for focus. That way you might be able to allow for some overlapping maybe to fit all 6 streams on the main stage let’s say.

That said, it’s gonna be annoying on the mobile app so I dunno.

Personally I feel like it’s a given part of a co-stream to have a single shared chat. I know that it’s better to have the opt-in though but I’m still gonna whine that I find alt-tabbing between chats annoying. Reckon it’s possible to make the opt-in for it to take place on the viewer’s end? That said I understand that’s probably gonna make so many things significantly more complicated but whatever. Call it “aspirational”. :wink:

I agree that a shared chat is a better viewer experience, but I’ve heard mixed feedback from mixer streamers about the combined chat they had so I’m trying to tread lightly. Also I want to make an allowance for smaller streamers that may not have moderators and are suddenly flooded with chat messages. But again, nothing is off the table.

That’s a good idea! I could have it set up in a carousel-like layout. Unfortunately, I don’t have a means to debug/test the mobile app on IOS so it will have to fall on someone else’s shoulders to figure out a reasonable way to integrate co-streaming into the app.

I’m curious about what kind of feedback you’ve heard. There might be ways around such feedback to make the experience as comfortable as possible.

Any takers in this thread?

… we need more people to pay attention to this forum :sweat_smile:

I really like the opt-in idea and I think it will be a good way to transition people from phase 1 to phase 2 as well. I suspect, when people see the feature implemented this way, they may also want the ability to choose which chats they want to merge with. I can see an interesting use-case where you have a 4 player 2v2 game where you may only want to merge chat with those on your team…or maybe not all people in the costream moderate their chats as strictly, and you only want to merge chats with like-minded streamers/moderators

I suspect deleting messages from only one chat will cause confusion. viewers in [channel A] will continue to see messages from viewers in [channel B] replying to a message they can no longer see.


(A)Mike: I like soup
(A)BOB: F* you
*moderator immediately deletes Bob’s message in [channel A] *
(B)Alice: shut up

out of context, it now appears alice from [channel B] is being rude to mike (unprovoked), and not bob from the perspective of [channel A]. Deleting messages from only one chat also doubles the amount of work required by mods, rather then letting them divide up the work across all participating channels

Not feeding the opposing team information is a very valid use-case, so I can see an argument for having a way to group chat at a finer grained level. I’ll keep that in mind as I continue development.

I tend to view that as more of a “social engineering” problem rather than one I can solve with software. My hope is that co-streaming will be used primarily to bring together like-minded communities. That said, if a consequence of chat groups is that this can be facilitated then that is a plus.

So I have a question on this – should the message deletion propagate always or only when the original message is deleted? To use your example, what happens if a moderator in channel B deletes the message from bob? Does it propagate back to channel A where it originated?

I ask this because it is possible that bob’s message doesn’t violate the rules of the chat he’s in and from his perspective he’s now being held to a standard he didn’t necessarily agree to (by directly chatting in channel B).

Updated Look at Layouts

After several months of coding, I finally have an in-site prototype of the various layouts streamers can choose when setting up a co-stream.


When users view a streamer’s page, regardless of layout, that channel’s stream will be visible. In layouts where more than one stream is visible simultaneously, the second visible stream will be that of the host (if different from the currently viewed channel). If more than two streams are visible, the remaining default visible streams are randomly selected from the guest streams.

Common Functionality

Stream layouts with the exception of carousel, share some common functionality:

Swapping Minimized or Visible streams

Rolling the mouse over a stream presents a swap button that, when pressed, will remain visible and blue until another swap button is pressed or the blue highlighted button is pressed again.


Stream Avatars and Channel Names

Rolling over a minimized or visible stream will display the channel’s avatar and name.


Built-in Layouts

Host Only

The Host’s stream is the only one viewable across the participants in the co-stream. Maximum of 6 participants. The layout is unchanged from the normal stream page layout.


Displays one stream at a time with a previous and next button on either side to switch to the other available streams. The avatar images of the previous and next channel appear (and cycle) under the respective buttons.

Split Vertical

Two streams are visible in a vertical column with up to four minimized on the left side that can be swapped into the visible positions.

Split Horizontal

Two streams are visible in a horizontal row with up to four minimized on the left side that can be swapped into the visible positions.

Stacked Right

Four streams are visible with the current channel in a large column centered vertically and three other streams on the right side stacked in a small vertical column. Up to two minimized streams can be swapped into the visible positions.

Stacked Left

Same as stacked right above but the small column is on the left and the large column is on the right.

Stacked Top Heavy

Four streams are visible with three small streams above one large stream that is centered horizontally. Up to two minimized streams can be swapped into the visible positions.

Stacked Bottom Heavy

Same as stacked top heavy except the large stream is above the three smaller streams.


Three equally-sized streams are visible in a triangle pattern. Up to three streams are minimized and can be swapped into the visible positions.

2x2 Grid

This layout only supports a maximum of four streams, all of which are visible in a grid pattern.

2x3 Grid

Six streams are visible in a grid pattern. No streams are minimized.

3x2 Grid

Six streams are visible in a grid pattern. No streams are minimized.

Custom Layouts

Streamers will be able to upload their own custom CSS layouts for use in their co-streams. The settings page will follow a similar flow to the emotes upload page as shown in the following mock-ups. All uploaded layouts will need to be approved by the GCT before they can be used in a co-stream. The layouts are only available to the channel that uploaded them and will only apply to other channels if the channel that uploaded the layout is the host and selects it.

Landing Page

Here the streamer can see the layouts they have submitted. The top section shows approved layouts that are available for use in their co-streams. The bottom section shows pending and rejected layout submissions.

Upload Page

Here the streamer can submit a custom layout to be available for use in co-streams they host if approved. The layout name is required and will be visible in the layout selection drop-down when editing/creating a co-stream. The “Max Channels” and “Visible Channels” allow the UI code to correctly place CSS class names on the various video streams so they can be properly customized. This will also be the default page displayed if a streamer has not yet submitted any custom layouts.

More to come friends! Please leave any feedback/suggestions below!


I’m not sure approving custom co-stream layouts really falls under the scope of GCT’s responsibilities. I also suspect most people won’t use it, with the exception of maybe glimesh itself, or maybe a large professional event (who would probably have a professional make it). I think it’s beyond the skillset of your average user (I watched you struggle through making the current layouts :wink: ) particularly without a starting template. If streamers tend to just making simple changes like adding a badge, or changing the colors of the templates, it may more sense to just add that customizability to the existing ones. we’ll have to wait and see how people use them.

I also feel like transcoding might be really important for the roll-out of this feature to go smoothly. I know I can’t watch 4-6 1080p streams on my connection for sure. I’m not sure we can count on streamers to understand that they may need to adjust quality for the sake of their viewers, and they may not want to do so (nor should they have to) for what they perceive to be a minority of their viewership. Streamers generally want to send out the highest quality broadcast they can, and leave it up to the platform to lower quality as needed on a per-viewer basis

1 Like

That’s fair. I didn’t show it in the mockups, but you’ll be able to download the built-in templates and modify them. I’ll also provide supplemental information for the help documentation. There may be some adventurous folks who will give it a whirl and if not, we’ll still be able to expand the built-in offerings in the future.

I’m concerned about that too, but I can’t really determine how much of an issue that may be until it goes live. That said, I plan to allow viewers to switch to the carousel view if they prefer. That could hopefully help mitigate insufficient bandwidth or smaller tablet screen sizes while still allowing them to cycle through the co-streams.