Co-Streaming Design Discussion

Description

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.

Qualifications

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

Permissions

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).
main-permissions

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.
main-host-workflow

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!

4 Likes

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

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

Example:

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