docs: ADR-204 new comms architecture #272
Conversation
Deploying adr with
|
| Latest commit: |
60685e2
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://0dfd5092.adr-cvq.pages.dev |
| Branch Preview URL: | https://adr-comms-ea.adr-cvq.pages.dev |
|
|
||
| #### Design Considerations | ||
|
|
||
| The establishment of the connection with the island remains unchanged, as that portion of the protocol is the same. The key difference lies in the types of messages sent through the channel. To establish a connection with a scene-room, a new service called [Gatekeeper](https://github.com/decentraland/comms-gatekeeper/) will be introduced to manage token permissions for the transport layer ([LiveKit](https://livekit.io/)). Only one scene room can be active at a time, as a user can only be present in one scene at any given moment. The scene room operates similarly to the communication service implementation used in worlds, where each scene has its own dedicated room. The Gatekeeper service will also allow scene owners to create authorizations for users, which will be reflected in the LiveKit token. This capability will enable them to moderate voice interactions and data streams within the scene effectively. |
There was a problem hiding this comment.
Only one scene room can be active at a time,
What is the limit of connected peers and what happpens if that limit is achieved?
There was a problem hiding this comment.
LiveKit does not have a hard limit on the number of participants in a room, allowing us to define our own limits as needed based on client needs.
The client receives information about users through the island and scene rooms. It must determine how many avatars it can render efficiently, especially in scenarios with a high number of participants. An approach could be prioritizing the processes of messages from players based on their proximity, rendering only the closest 200 avatars and ignoring the rest. This selective rendering can reduce processing load by discarding non-essential messages. This requires fine-tuning but these behaviors were deferred to a later phase as it is not a problem in the current state of the platform and the door is opened to different possible solutions. The key point is that based on LiveKit, there could be no limit on the amount of players connected to the room and we would probably find some bottlenecks in the bandwidth and the processing of the messages
I will add a comment in the ADR.
|
Hi, how are you? Great work @pentreathm! I have just a few questions:
|
|
|
||
|  | ||
|
|
||
| In the illustrated scenario, Peers 1, 2, and 3 are connected to the scene room `E1`. Additionally, Peer 1 establishes a connection to the island `I1`, while Peers 2 and 3 are linked to the island `I2`. This example serves as a simplified illustration. Users may be far apart within the same scene, but this aims to demonstrate that if a peer is at the edge of a scene, they will be able to see other players who are not within the scene but are within viewing range. On the other hand, the scene channel will be there to share consistent data among the visitors, like a stream of video on a texture or the state of an object like a door that can be opened or closed besides also sharing information about the users visiting the scene. |
There was a problem hiding this comment.
Just curious about this scenario:
- User A is on scene 101
- User B is on scene 102 which borders on scene 101
- Both users shares a single channel because of proximity but also are connected to different channels because of the scene distinct (one channel for scene 101 and another one for scene 102)
- If User A opens a door in scene 101
- And User B after the door was opened, joins scene 101, will it see the door open or close?
The question is if when a user enters a new scene it replicates the current state of the scene that has been changing by another users who were already on that scene.
There was a problem hiding this comment.
Technically, yes. The state of the scene (CRDT State) should be saved, and when it enters the scene room, it should receive the state and synchronize the scene.
So User B will see the door opened when it joins the scene and the state gets syncronized.
There was a problem hiding this comment.
yes, what @kuruk-mm said is correct.
Co-authored-by: Alejo Thomas Ortega <[email protected]> Signed-off-by: pentreathm <[email protected]>
Co-authored-by: Ignacio Mazzara <[email protected]> Signed-off-by: pentreathm <[email protected]>
A user should always be connected to only one scene at a time, only one scene connection should remain open.
Indeed, this feature will be lost in this initial version, it was a necessary trade-off in the design to give scene owners greater control over audio streams and the ability to moderate content. That said, there is potential for improvements. For instance, if a user is connected to Archipelago but not to a specific Scene, they could leverage that channel to share audio, enabling this use case. Additionally, a future "party mode" could be developed using the comms gatekeeper, allowing users to create a private communication channel with friends. This would facilitate sharing audio and text chat, irrespective of other connections in the environment.
yes, and I agree with your point, however, the decision was made because text chat is generally less intrusive for other users compared to voice chat. With voice, individuals can disrupt the experience for others, whereas text chat can simply be muted or turned off when needed. cc @kuruk-mm |
Co-authored-by: Alejo Thomas Ortega <[email protected]> Signed-off-by: pentreathm <[email protected]>
Co-authored-by: Alejo Thomas Ortega <[email protected]> Signed-off-by: pentreathm <[email protected]>
| @@ -39,6 +40,7 @@ The Archipelago protocol scales efficiently due to its dynamic island calculatio | |||
| Maintain the current Archipelago implementation while establishing a new scene room connection specific to the active scene. The Archipelago channel should be reserved solely for receiving avatar positions, profile update notifications, and nearby chat messages with the objective to be able to interact with users beyond the limits of a scene. All communications, including voice chat, scene objects state, and streams, will be shared within the scene channel. | |||
| This new model grants scene owners authority over the communication channel, allowing them to share content streams, share object states or handling speakers, providing a consistent experience for all users visiting the scene. | |||
|
|
|||
| At any given moment, a user can maintain up to two connections: one with the current scene and another with the island. When the scene changes, the existing connection to the previous scene should be closed, and a new connection to the current scene must be established. | |||
There was a problem hiding this comment.
Is there a specific reason to limit to only one scene connection? Wouldn't it be up to the explorer to determine how many scene-rooms can handle?
There was a problem hiding this comment.
Ultimately, it is the client’s responsibility to manage the number of open connections. However, keep in mind that maintaining multiple open connections is resource-intensive, and the data transmitted over the scene channel can require substantial bandwidth to share scene state and other streams. It is advisable to keep a connection open only with the scene that the user is currently interacting with.
* Describe Compression and Encoding algorithms Signed-off-by: Mikhail Agapov <[email protected]>
| --- | ||
| layout: adr | ||
| adr: 204 | ||
| title: Comms Architecture for new client |
There was a problem hiding this comment.
Should we just call it now Explorer 2.0 instead of new client? Or client 2.0
| title: Comms Architecture for new client | |
| title: Comms Architecture for client 2.0 |
No description provided.