talkat specification

Since my last post about geminifying talk(1), and the useful feedback I got from a few people, I have been slowly working on the protocol and a haskell implementation. The implementation needs a little more work before it's ready for release, but I think it makes sense to first present the protocol that it's implementing, on the basis that it will be harder to change that once the implementation is released. So if you have any comments on it, please let me know now!

Draft speculation for talkat

That document is rather dry, so for context here's a sketch of how it functions for the end user. The sample syntax is that of the unfinished haskell implementation.

• You create a keypair ('htalkat id'), optionally specifying a name, and distribute the hash to people you might want to talk with, say by putting it on your gemini capsule, including a hostname if you will run a server; e.g. I will add talkat:068ff3b2003eed3073676288f46c008b@thegonz.net to the contact section on my capsule.
• Optionally, you run a server ('htalkat l[isten]').
• You obtain the hash and hostname of someone who is running a server, and connect to it ('htalkat c [talkat:]HASH@HOST' or 'htalkat c NAME'). The hash is checked, foiling any MitM.
• The user running that server is notified of an incoming call; if they have already assigned a petname to your hash (with 'htalkat n HASH[@HOST] NAME') then they will be shown that petname, otherwise it will be shown as an unknown caller with the name you set in the first step (set as the Common Name of the client certificate).
• They may answer ('htalkat a'). Then an interactive client starts on each end, and they pass realtime unicode text back and forth until one side or the other closes the connection. As in talk(1), the client shows two windows, one for each participant, and keystrokes including erasing characters from the current line are shown in realtime (with a slight delay to handle network jitter). Editing completed lines is impossible.