[prev in list] [next in list] [prev in thread] [next in thread] 

List:       otr-dev
Subject:    Re: [OTR-dev] mpOTR: shutdown()
From:       Abel Luck <abel () guardianproject ! info>
Date:       2012-07-24 14:22:21
Message-ID: 500EAF9D.6030705 () guardianproject ! info
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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" (application/pgp-signature)]

_______________________________________________
OTR-dev mailing list
OTR-dev@lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev


[prev in list] [next in list] [prev in thread] [next in thread]