Requiring people to organize and choose a time to use kataomoi together is a serious hindrance to using kataomoi successfully. We should allow users to select Yes/No answers for other users who aren't currently online; the protocol exchange still can't take place until both users are online at the same time, but online status can be detected automatically and acted upon by the client without further user intervention.
In more detail, this would require persistent user accounts instead of ephemeral rooms and usernames. Users would create accounts, and join (or be invited into) "circles" containing other users, who they could then select answers for. Clients would detect when users in the same circle come online, and perform exchanges then if they hadn't recently performed an exchange with the same user. Long-term client state (such as keypair, circle memberships, choices for other users, and past results) would be encrypted client-side with the user's password, and then both stored in browser localStorage (when possible) and sent to the server to be saved.
When dealing with users not in the same physical location, we'll need fancier mechanisms for authenticating mappings between real identity and username/public key. We should give users a way to display their own public key fingerprint for verification, and locally sign other users' public keys (these signatures would become part of the saved client state). Adding ways for users to verify public keys without face-to-face interaction (for example, users can upload a PGP-signed statement for other users to view) could also be useful.
Requiring people to organize and choose a time to use kataomoi together is a serious hindrance to using kataomoi successfully. We should allow users to select Yes/No answers for other users who aren't currently online; the protocol exchange still can't take place until both users are online at the same time, but online status can be detected automatically and acted upon by the client without further user intervention.
In more detail, this would require persistent user accounts instead of ephemeral rooms and usernames. Users would create accounts, and join (or be invited into) "circles" containing other users, who they could then select answers for. Clients would detect when users in the same circle come online, and perform exchanges then if they hadn't recently performed an exchange with the same user. Long-term client state (such as keypair, circle memberships, choices for other users, and past results) would be encrypted client-side with the user's password, and then both stored in browser localStorage (when possible) and sent to the server to be saved.
When dealing with users not in the same physical location, we'll need fancier mechanisms for authenticating mappings between real identity and username/public key. We should give users a way to display their own public key fingerprint for verification, and locally sign other users' public keys (these signatures would become part of the saved client state). Adding ways for users to verify public keys without face-to-face interaction (for example, users can upload a PGP-signed statement for other users to view) could also be useful.