Documentation

A message sent from a rendezvous client to the server.

A message received from the server.

Some open questions: * general message stuff--how are we going to model this? * outgoing messages include a randomly generated id field, which is returned by the server * messages from the server include server_tx, a float timestamp recording when the server received the message * messages from the server that are direct responses include a server_rx timestamp--unclear what this means? * do we want a separate Haskell type for each message type? e.g. PingMessage * if we do that, how do associate request/response pairs? e.g. PingMessage & PongMessage? * do we want to (can we even?) structurally distinguish between messages that make sense outside the scope of a binding (e.g. ping) and messages that only make sense after a bind (e.g. allocate)

Short string to identify the application. Clients must use the same application ID if they wish to communicate with each other.

Recommendation is to use "$DNSNAME/$APPNAME", e.g. the Python wormhole command-line tool uses lothar.com/wormhole/text-or-file-xfer.

A message sent to a mailbox.

Message received on initial connection to the server.

Identifier sent with every client message that is included in the matching server responses.

Short string used to differentiate between echoes of our own messages and real messages from other clients.

TODO: This needs to be cleanly encoded to ASCII, so update the type or provide a smart constructor.

Generate a random Side

A phase in the peer-to-peer (aka "client") protocol.

Phases proceed in strict order: PakePhase, VersionPhase, then many ApplicationPhase.

Get the name of the phase. Used to derive message keys.

The body of a Magic Wormhole message.

This can be any arbitrary bytestring that is sent to or received from a wormhole peer.

Identifier for a "nameplate".

A nameplate is a very short string that identifies one peer to another. Its purpose is to allow peers to find each other without having to communicate the Mailbox identifier, which is generally too lengthy and cumbersome to be easily shared between humans.

Typically, one peer will allocate a nameplate and then communicate it out-of-band to the other peer.

Identifier for a mailbox.

A mailbox is a shared access point between Magic Wormhole peers within the same application (specified by AppID). To get a mailbox, you must first acquire a Nameplate and then claim that nameplate for your side with claim.

A mailbox ID is defined in the spec as a "large random string", but in practice is a 13 character, lower-case, alpha-numeric string.

How the client feels. Reported by the client to the server at the end of a wormhole session.