For better browser compatibility, this socket library looks like it would work (although there are probably other good libraries out there as well). I'd be willing to help rewrite parts of the web interface, if you need help with that



1 - Screen data. I won't go into details how the screen data is encoded, it can be read from the source code.

2 - JSON message. The rest of the packet is UTF-8 encoded JSON that, on the top-level, is an array. The first element in the array is a string that describes what the message is about and that to expect in the rest of the array:

"who_is_playing" - The second element of the array is the name of the player who last gave input to the Dwarf Fortress game we are watching right now. "chat" - The second element of the array is the name of the player who is talking and the third is the contents of the chat message. "game_list" - The second element of the array is another array where each element is an array of two elements, the first one is the name of a game and the second is an index that the client can use to refer to a game when it talks back to Dfterm3.

3 - Login failed (the rest of the packet is empty)

4 - Login succeeded

"\x01" - Choose a game to watch. The rest of the message is Unicode-encoded index that was received from the "game_list" message as described above. Note that it may take up to 20 seconds before the server responds and there is no separate "game watching succeeded" message, you'll just start getting screen data.

"\x02" - Stop watching a game and receive a new list of games.



"\x03" - Send a chat message. The rest of the message is the contents of the message. The server will ignore this message if the user has not logged in.

"\x04" - Log in. The rest of the message is the name you want to login with. The server will truncate this to 20 Unicode code points. Wait for acknowledgement (see above) before assuming logging succeeded.

"\x05" - Send key input. The message after the first character is a JSON-encoded object with following keys and values:

"which": This is a virtual key code value. The name comes from the field in the keyboard event object it is taken from. "code_point": Unicode code point this key corresponds to. It can be 0 if the key has no such representation. "shift": Boolean, true if shift was pressed down when this key was pressed. "alt": Boolean, same as shift but for alt key. "ctrl": Boolean, for control key.



I would be very grateful if someone who actually knows how to make beautiful and functional web interfaces would help. I have barely have experience in user interface design. The web interface is in under web-interface/ directory in the source tree to play around. It should be possible to refine it without having to compile anything in Dfterm3. The administrator panel however, does not actually use the files under web-interface/ except for CSS files.There is no documentation on the current Dfterm3Web protocol but I'll describe how it currently works here:The connection is a Websocket connection using the Hybi10 draft specification. I think the Websocket specification has now has an RFC but the Haskell library I use for Websockets does not support that yet.From Dfterm3 to the browser, every message is a binary message. The first byte specifies what the message is about:From the browser to Dfterm3, all messages are text messages. The first character determines what the message is about:If that's not all of the messages used in the protocol, it is most of it. As you can see, it is a mixture of JSON and custom formats. I think it might be better to encode most of the things in JSON, with the possible exception of screen data that is sent very frequently and the messages can be quite large. Changing the protocol is quite easy. I didn't quite spend time trying to design it properly as I felt there were more important things to develop at hand.I took the trouble to document this protocol in the vain hope that someone appears with an alternative or modified interface that is better than what I currently have there.