Skip to content

Commit

Permalink
Update content/ADR-204-comms-architecture.md
Browse files Browse the repository at this point in the history
Co-authored-by: Alejo Thomas Ortega <[email protected]>
Signed-off-by: pentreathm <[email protected]>
  • Loading branch information
pentreathm and aleortega authored Oct 28, 2024
1 parent dc40af7 commit d664b47
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion content/ADR-204-comms-architecture.md
Original file line number Diff line number Diff line change
Expand Up @@ -197,7 +197,7 @@ Date: TBD

- The protocol and architecture for the communication services will undergo significant changes with this implementation. This means that users connecting through clients built on the previous version of the protocol will not be able to interact with those using clients on this new version.
- Voice chat will be routed through the scene room. If one user is on a road and another is on the floor, each in different scenes, they won’t be able to hear each other. This decision was made to give the scene owners the control over the voice chat on their scenes.
- Duplicated messages, such as positions, profiles, and text chats, may be transmitted across both island and scene rooms. This can lead to inefficient data transfer; however, it can be optimized on the client side by adjusting the message frequency for each channel based on the number of active connections. This design trade-off was necessary to meet all criteria and to visualize and interact with users within the scene and users close to the scene boundaries.
- Duplicated messages, such as positions, profiles, and text chats, may be transmitted across both island and scene rooms. This can lead to inefficient data transfer; however, it can be optimized on the client side by adjusting the message frequency for each channel based on the number of active connections. This design trade-off was necessary to meet all the criteria and enable visualization and interaction with users both within the scene and near its boundaries.
- LiveKit rooms will be protected by a Gatekeeper, which will oversee token permissions, empowering scene owners to manage access within their environments effectively. This setup allows Decentraland Cast to connect seamlessly to scene rooms, enabling the sharing of streams and management of speakers.
- The scene room could become a bottleneck during periods of high user influx. To address this challenge, the system can scale by implementing broadcasting across multiple rooms, which will require design and rigorous testing to ensure effectiveness.
- The extensibility of this model supports new use cases. The cast application could evolve into a comprehensive show management system, facilitating the orchestration of events. Additionally, a new party-mode could be created through a dedicated channel via the Gatekeeper, enabling communication features within private user groups.

0 comments on commit d664b47

Please sign in to comment.