devrandom: > A potential solution to the startup/shutdown user-experience is to > maintain multiple overlapping sessions. > > So: > > * When a client joins or leaves, initiate startup of a new session > * Always communicate on the newest session that is active > * An active session is defined as a session that has startup completed > and no shutdown initiated > * When you have a new active session, initiate shutdown of any old ones > * Long timeout on shutdowns (1 hour?) > > Advantages: > > * There will always be an active session so that chatting will not be > disrupted > * Clients will likely be able to complete shutdown so that they can have > deniability even with flaky networks > * New clients will be able to start chatting as soon as possible, > without disrupting existing chat > > Disadvantages > > * Additional network bandwidth and CPU usage (mitigate through > throttling creation rate?) > > Open questions: > > * How do we decide on the group membership for startup? Different > clients may have different ideas of who is present due to network > delays. Perhaps that is okay - make the session ID be a hash depending > on members and just go ahead and create multiple sessions. Since you > always chat on the newest session that initiated successfully, > additional sessions are not an issue.
I think this is a good proposal. Definitely seems to be the best method to ensure usability and meet existing expectations about how group chats function. As for group membership, I think this could be supplied by the underlying transport (XMPP, IRC, etc.). When Carol joins a chat/channel, she will likely see gibberish (current conversation) until all other participants roll into a new session with her. Ideally, the client implementations will be able to hide that gibberish and simply provide a "Joining chat..." message until the session has initiated. ~abel
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
