Context?
Im milestone #2 we have done refactor of WebRTC connection, to reduce responsiblity of Node.JS server to pure websocket Signaling duties. To prioritize delivery sticked to simple communication architecture which is Leader/Followers pattern.
Problem?
One of the business requirement is that - upon box Unlocking - keys are shared only with key holders that keys are meant to be shared with. With architecture Leader/Followers the keys will have to be send through leader even if he is not meant to receive the key.
Leader of course is not persisting the key, according to milestone #2 implementation/plan, if the key is not meant for the leader. But that does not solve the problem.
What?
Unlocking keys should be shared directly between key holders.
We can keep leaders/followers architecture as it simplifies business logic, because there is single source of thruth that is easy to implement.
The architecture should be use everywhere, but when keys are shared at final step of box unlocking. This should happen with direct WebRTC connections between key holders.
How
To be discussed, but I think we can use current Caller/Callee signalling service, to create multiple DataChannelsManagers for each Keyholder, a keyholder should connect with.
The Signaling Service Server could be used the same Node.JS server, but if decide to use leader connection with this task to exchange, answer/offer and ice candidates - we get harder to implement but more robust solution.
To decide who is Caller and Calle, we can simply take who is the first that shared the key with other key holder. This person should be Callee, other Caller.
It is possible that key exchange will be in single way only.
Context?
Im milestone #2 we have done refactor of WebRTC connection, to reduce responsiblity of Node.JS server to pure websocket Signaling duties. To prioritize delivery sticked to simple communication architecture which is Leader/Followers pattern.
Problem?
One of the business requirement is that - upon box Unlocking - keys are shared only with key holders that keys are meant to be shared with. With architecture Leader/Followers the keys will have to be send through leader even if he is not meant to receive the key.
Leader of course is not persisting the key, according to milestone #2 implementation/plan, if the key is not meant for the leader. But that does not solve the problem.
What?
Unlocking keys should be shared directly between key holders.
We can keep leaders/followers architecture as it simplifies business logic, because there is single source of thruth that is easy to implement.
The architecture should be use everywhere, but when keys are shared at final step of box unlocking. This should happen with direct WebRTC connections between key holders.
How
To be discussed, but I think we can use current Caller/Callee signalling service, to create multiple DataChannelsManagers for each Keyholder, a keyholder should connect with.
The Signaling Service Server could be used the same Node.JS server, but if decide to use leader connection with this task to exchange, answer/offer and ice candidates - we get harder to implement but more robust solution.
To decide who is Caller and Calle, we can simply take who is the first that shared the key with other key holder. This person should be Callee, other Caller.
It is possible that key exchange will be in single way only.