docs: ADR-204 new comms architecture

[pentreathm]

No description provided.

[cloudflare-workers-and-pages]

Deploying adr with    Cloudflare Pages

Latest commit:	7151aa2
Status:	✅  Deploy successful!
Preview URL:	https://55420556.adr-cvq.pages.dev
Branch Preview URL:	https://adr-comms-ea.adr-cvq.pages.dev

View logs

[nachomazzara]

Great work @pentreathm

[kuruk-mm]

Hi, how are you? Great work @pentreathm! I have just a few questions:

1. Is it possible to connect to multiple scene rooms at the same time, or is only one scene room connection allowed at once?
2. With this design, are we going to lose the ability to walk around with a friend, explore Decentraland, and voice chat together? It seems like you'll be reconnecting with each scene change, and I think that's one of the best features of Islands. Has this been considered in the design? Are there any future plans for private rooms where we can stay with our friends to mitigate this issue?
3. I read in the "Consequences" section that you're not going to hear someone who is near you but in a different scene. If the reason for this is to give the scene owner control over the voice chat content, shouldn't the nearby chat be treated the same way?

[pentreathm]

• Is it possible to connect to multiple scene rooms at the same time, or is only one scene room connection allowed at once?

A user should always be connected to only one scene at a time, only one scene connection should remain open.

• With this design, are we going to lose the ability to walk around with a friend, explore Decentraland, and voice chat together? It seems like you'll be reconnecting with each scene change, and I think that's one of the best features of Islands. Has this been considered in the design? Are there any future plans for private rooms where we can stay with our friends to mitigate this issue?

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.

• I read in the "Consequences" section that you're not going to hear someone who is near you but in a different scene. If the reason for this is to give the scene owner control over the voice chat content, shouldn't the nearby chat be treated the same way?

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

[aixaCode]

Should we also mark the older comms ADR as deprecated as we introduced the new state?

[leanmendoza]

Should we also mark the older comms ADR as deprecated as we introduced the new state?

Only after this had lived for at least year (or a period that makes sense) I'd set the current comms as deprecated. There is no rush; this is still experimental and not implemented by other clients except by the new Unity Explorer.

[aixaCode]

Should we also mark the older comms ADR as deprecated as we introduced the new state?

Only after this had lived for at least year (or a period that makes sense) I'd set the current comms as deprecated. There is no rush; this is still experimental and not implemented by other clients except by the new Unity Explorer.

Agree, there is definitely no rush, just would like to avoid situation when potential new clients start using the old version of the comms.