Group Communications

[pchainho]

Following discussion from here.

What are the use cases (technical/business) associated to this implementation ?

In WP1 we have a few Use Cases for group communication eg https://github.com/reTHINK-project/use-cases/issues/86

What would be the impact on authentication/association of hyperties identity management ?

Not sure I understood this question but I guess it is related with the support of Identity Management in NodeJS. As discussed, one idea would be to use Browser Runtime admin GUI to manage identities in remote NodeJS servers. There would be the notion of runtime accounts where we could distinguish two roles: administrators and customers. Administrators manages customer accounts. Anyway, I would prefer to have this discussion in a separated issue with our Identity / Security experts ( @Ricardo-Chaves , @gamdias @jmcrom ? )

[pchainho]

WP4 has already started discussed this issue. @jmcrom will provide the link to WP4 issue

[jmcrom]

related to https://github.com/reTHINK-project/dev-runtime-core/issues/96 and https://github.com/reTHINK-project/governance-security-implementation/issues/49

[pchainho]

thx @jmcrom

I'll use https://github.com/reTHINK-project/dev-runtime-core/issues/96 to follow up Identity management in the NodeJS

[pchainho]

A few comments on current specs:

• Missing the full meshed topology
• I would prefer not to use terminology like "client" and "server" since we are not using client - server communication model but a peer to peer communication model
• This spec should not be specific to Kurento
• Missing the possibility to dynamically discover the Conference Hyperty
• Missing required transactions to manage rooms (create, delete, etc) that will correspond to the creation of data objects representing these rooms that would be registered in the domain registry and a specific room. The conference room data object should be compliant with the communication data object
• Missing the possibility to dynamically discover previously created rooms that have been registered in the domain registry
• the interaction with the WebRTC API is internal to Hyperties eg Apps don't have to deal with SDPs
• there is a note about a "server connection object" but I don't find it in the data flows. It seems to be related with the Room Communication object I mention above
• there is a communication object in the conference hyperty data flow diagram that I suspect should be a connection data object. If the intention is to have a communication object representing a room, as proposed above, then we are missing connection objects per connected peer, as well as communication objects on the browser side
• the current spec does not address the identity management aspects

[jboulmal]

I hope you find answers here @pchainho :

1- Missing the full meshed topology

1- This point was previously discussed here WebRTC Multiparty

2 - I would prefer not to use terminology like "client" and "server" since we are not using client - server communication model but a peer to peer communication model

2 - well, this is just another P2P system model with some degree of centralization. we have replaced client by peer, while we have kept server nomination. Besides, the server in this Group communication acts as another special peer, we can also call it Super Peer like in network jargon.

3 - This spec should not be specific to Kurento

3 - I agree with that, we will update in most generic/standard way, but WebRTC compatible.

4- Missing the possibility to dynamically discover the Conference Hyperty

4 - It's intentionally missing, since we don't plan to add anything new to existing Hyperties discovery specs/mechanisms in the reTHINK framework.

5 - Missing required transactions to manage rooms (create, delete, etc) that will correspond to the creation of data objects representing these rooms that would be registered in the domain registry and a specific room. The conference room data object should be compliant with the communication data object

5 - Indeed, the data object in question is compliant with the communication data object.

5 - This is a hyperty internal discussion, similar to hyperty-connector, If I provide all details here it will results in heavy README.

6 - Missing the possibility to dynamically discover previously created rooms that have been registered in the domain registry

6 - duplicate of point 4, usage of existing mechanism in reTHINK framework.

7 - the interaction with the WebRTC API is internal to Hyperties eg Apps don't have to deal with SDPs

7 - It was clarified in WP3 Telco of this week.

8 - there is a note about a "server connection object" but I don't find it in the data flows. It seems to be related with the Room Communication object I mention above

8 - Affirmative, the correct one is the Room Communication object.

9 - there is a communication object in the conference hyperty data flow diagram that I suspect should be a connection data object. If the intention is to have a communication object representing a room, as proposed above, then we are missing connection objects per connected peer, as well as communication objects on the browser side

9 - I agree, little bit confusion here. In the ambiguity of missing interoperability documentation between the connection data object and the communication data object. safely, we will stay with communication data object model for both the Peers and the Super Peer involved in the group communication. Even though, for the Peers the connection data object is more than enough. While, in case of the Super Peer , the requirements are different. Thus, the communication data object is a must.

10 - the current spec does not address the identity management aspects

10 - Reported in phase2 Identity Module. Today, temporarily, we have a basic static id provision for Super Peer (server side) hyperties.

[pchainho]

1- Missing the full meshed topology

1- This point was previously discussed here WebRTC Multiparty

Yes, but I don't find it in the specs page. The issues will be closed as soon as they have been addressed in the specs page.

2 - well, this is just another P2P system model with some degree of centralization. we have replaced client by peer, while we have kept server nomination. Besides, the server in this Group communication acts as another special peer, we can also call it Super Peer like in network jargon.

Conference peer would be ok. We should avoid centralisation even for "Media Servers".

4 - It's intentionally missing, since we don't plan to add anything new to existing Hyperties discovery specs/mechanisms in the reTHINK framework.

Agree we should reuse existing mechanisms but in the current specs its not clear that's case. In terms of diagrams you can just have a panel with a reference to the diagrams where discovery is specified. by the way, these diagrams should be moved to the "dynamic view" folder. This comment also applies to point 6 related with data object discovery.

5 - This is a hyperty internal discussion, similar to hyperty-connector, If I provide all details here it will results in heavy README.

you can use several MD pages for the spec not just a readme file. You don't have to provide the full details here but just what is required to analyse the impact on the core framework.

10 - Reported in phase2 Identity Module. Today, temporarily, we have a basic static id provision for Super Peer (server side) hyperties.

As mentioned above, the specs should address all the discussions around the group communication topic. Probably it makes sense to have the Nodejs identity management discussion in a separated page.

[jboulmal]

I have updated the specs according to your feedbacks @pchainho. However, the identity management #17 specs for server-hyperty still not improved in these current specs. Nonetheless, we will report its current status in the specs.

Concerning the impact on the core framework, I find it difficult guess for spec design phase. However, answering the following questions would considerably help :

• According to the current specs, the Syncher provided by the runtime for the Server conference hyperty needs to have the ability to create/maintain several room data communication objects (for which is an observer) per the same runtime ?
• The Syncher needs also to handle subscription requests for several room communication data objects simultaneously.
• On the server runtime, the Hyperty needs to have the ability to be Reporter for differents room communication data objects and at the same time be observer for peers communication data objects.

Please have look and let'us know what we need to improve.

[jboulmal]

As discussed in WP3 Telco of this week: The group communication model in these specs is based on the concept of rooms. The Server Conference Hyperty will handle room communication data objects. Implicitly, every room communication data object will handle several connection data objects that will represent connected peers WebRTC endpoints. Hence, for simplicity and in order to be more generic, we used communication data objects for Server and peers data objects. Besides, for the same raisons stated above, the connection data object is sufficient for connected Peers. While, in case of the Server Conference Hyperty, the requirements are differents. Thus, the communication data object is a must for the server side hyperty.

[pchainho]

Right, but it is still not clear that you are using connection data object in both Hyperties. Even in the text, there is no reference to them. Anyway, I guess peer conference Hyperty could just use connection data objects and it will still be able to interact with Conference Server hyperty. I still don't like this name. Just Conference Hyperty would be much better.

[pchainho]

Regarding the impact on the Core Framework:

According to the current specs, the Syncher provided by the runtime for the Server conference hyperty needs to have the ability to create/maintain several room data communication objects (for which is an observer) per the same runtime ?

No sure I understood, but currently each Syncher instance can simultaneously handleseveral data objects, as observer or reporter.

The Syncher needs also to handle subscription requests for several room communication data objects simultaneously.

No problem.

On the server runtime, the Hyperty needs to have the ability to be Reporter for differents room communication data objects and at the same time be observer for peers communication data objects.

Also not a problem.

Where I see an impact is on the Identity Module, but there is yet, no reference to it in the specs.

[jboulmal]

Ok @pchainho I have updated README according to your feedbacks. Concerning the Identity Management at Runtime Node, I haven't included it in the current specs, since there is not much progress about it from Trust Managment specs.

[jboulmal]

It's done @pchainho for phase 2 deliverable. Thanks for your valuable feedbacks.