Changes
First version
=Proposal for concurrent join=
With having session key confirmation one can have following protocol to handle concurrent join.
Each session can have 5 status: {current, potentially next, next, admissible, inadmissible}.
==Session picking protocol for current occupant of the current session==
Suppose user <math>U_i</math> is in Session <math>S</math>. When new user <math>Unew_j</math> send a join request, user <math>U_i</math> start an admissible session <math>S_j</math> with the list of authenticated participant in the room (not users in the session).
If <math>m</math> users are joining that session concurrently, there are <math>S_1,...,S_m</math> admissible which are receiving shares and authentication messages.
Suppose <math>S_j</math> receives the mutual authentication of all new users in admissible session <math>S_j</math> that will become the potentially next session of <math>U_i</math>. <math>U_i</math> then sends the combined list of (authenticated) participants in <math>S_j</math>, <math>(U_1,y_1,...,Unew_m,ynew_m,...)</math> to the room intending for new users not in the list to see and to authenticate to, and to old user to signal its potentially next session. It tags <math>S_1,...,S_m</math> as inadmissible sessions.
When <math>U_i</math> receives all shares of potentially next session <math>S_j</math> and the authenticated list from all users from current session, they tag the session as next and send the session key confirmation of <math>S_j</math>. The session will not be tagged as inadmissible in case of new authenticated list, it just make new admissible session.
If user U_i receives another authenticated list from another <math>S_j'</math> then it tag <math>S_j</math> inadmissible as well and start an admissible session with <math>plist_{S_j'} \cup plist_{S_j}</math> as new admissible session waiting for authentication from new users.
If it receives key confirmation from all <math>U_l</math> in <math>(U_1,...,Unew_m,..)</math> then it will make <math>S_j</math> as current session and send messages to this session.
==Session picking protocol for new user joining the room==
When a joining user Unew_l receives a list of potential users which is not including them, it authenticate to U_i's which new user has not yet authenticated to, and compute new share for the new share list. When they have all shares and authentication for plist_j then they send the key confirmation and wait for all of key confirmation.
When they receive confirmation from every user in plist_j. They make it current session and start chatting.
admissible -> {inadmissible, potentially next}
potentially next ->{inadmissible, next}
next->{current}
current and inadmissible will be eventually discarded.
With having session key confirmation one can have following protocol to handle concurrent join.
Each session can have 5 status: {current, potentially next, next, admissible, inadmissible}.
==Session picking protocol for current occupant of the current session==
Suppose user <math>U_i</math> is in Session <math>S</math>. When new user <math>Unew_j</math> send a join request, user <math>U_i</math> start an admissible session <math>S_j</math> with the list of authenticated participant in the room (not users in the session).
If <math>m</math> users are joining that session concurrently, there are <math>S_1,...,S_m</math> admissible which are receiving shares and authentication messages.
Suppose <math>S_j</math> receives the mutual authentication of all new users in admissible session <math>S_j</math> that will become the potentially next session of <math>U_i</math>. <math>U_i</math> then sends the combined list of (authenticated) participants in <math>S_j</math>, <math>(U_1,y_1,...,Unew_m,ynew_m,...)</math> to the room intending for new users not in the list to see and to authenticate to, and to old user to signal its potentially next session. It tags <math>S_1,...,S_m</math> as inadmissible sessions.
When <math>U_i</math> receives all shares of potentially next session <math>S_j</math> and the authenticated list from all users from current session, they tag the session as next and send the session key confirmation of <math>S_j</math>. The session will not be tagged as inadmissible in case of new authenticated list, it just make new admissible session.
If user U_i receives another authenticated list from another <math>S_j'</math> then it tag <math>S_j</math> inadmissible as well and start an admissible session with <math>plist_{S_j'} \cup plist_{S_j}</math> as new admissible session waiting for authentication from new users.
If it receives key confirmation from all <math>U_l</math> in <math>(U_1,...,Unew_m,..)</math> then it will make <math>S_j</math> as current session and send messages to this session.
==Session picking protocol for new user joining the room==
When a joining user Unew_l receives a list of potential users which is not including them, it authenticate to U_i's which new user has not yet authenticated to, and compute new share for the new share list. When they have all shares and authentication for plist_j then they send the key confirmation and wait for all of key confirmation.
When they receive confirmation from every user in plist_j. They make it current session and start chatting.
admissible -> {inadmissible, potentially next}
potentially next ->{inadmissible, next}
next->{current}
current and inadmissible will be eventually discarded.
