Safe Haskell | None |
---|---|
Language | Haskell2010 |
Messages sent to and from the Rendezvous server.
- data ClientMessage
- data ServerMessage
- = Welcome WelcomeMessage
- | Nameplates {
- nameplates :: [Nameplate]
- | Allocated { }
- | Claimed { }
- | Released
- | Message MailboxMessage
- | Closed
- | Ack
- | Pong Int
- | Error {
- errorMessage :: Text
- original :: ClientMessage
- newtype AppID = AppID Text
- data MailboxMessage = MailboxMessage {}
- data WelcomeMessage = WelcomeMessage {
- motd :: Maybe Text
- welcomeErrorMessage :: Maybe Text
- newtype MessageID = MessageID Int16
- newtype Side = Side Text
- generateSide :: MonadRandom randomly => randomly Side
- data Phase
- phaseName :: Phase -> Text
- newtype Body = Body ByteString
- newtype Nameplate = Nameplate Text
- newtype Mailbox = Mailbox Text
- data Mood
Documentation
data ClientMessage Source #
A message sent from a rendezvous client to the server.
Bind AppID Side | Set the application ID and the "side" for the duration of the connection. |
List | Get a list of all allocated nameplates. |
Allocate | Ask the server to allocate a nameplate |
Claim Nameplate | Claim a nameplate. |
Release (Maybe Nameplate) | Release a claimed nameplate. If no nameplate is provided, the server will attempt to release the
nameplate claimed (via |
Open Mailbox | Open a mailbox. |
Add Phase Body | Send a message to an open mailbox. The message will be delivered to all connected clients that also have that mailbox open, including this one. |
Close (Maybe Mailbox) (Maybe Mood) | Close a mailbox. Since only one mailbox can be open at a time, if mailbox isn't specified, then close the open mailbox. |
Ping Int | Internal "ping". Response is |
Eq ClientMessage Source # | |
Show ClientMessage Source # | |
ToJSON ClientMessage Source # | |
FromJSON ClientMessage Source # | |
data ServerMessage Source #
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)
Welcome WelcomeMessage | Sent by the server on initial connection. |
Nameplates | Sent in response to "list" |
| |
Allocated | Sent in response to "allocate" |
Claimed | Sent in response to "claim" |
Released | Sent in response to "release" |
Message MailboxMessage | A message sent to the mailbox |
Closed | Sent in response to "close" |
Ack | Sent immediately after every message. Unused. |
Pong Int | Sent in response to "pong" |
Error | Sent by the server when it receives something from the client that it does not understand. |
|
Eq ServerMessage Source # | |
Show ServerMessage Source # | |
ToJSON ServerMessage Source # | |
FromJSON ServerMessage Source # | |
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
.
AppID Text |
data MailboxMessage Source #
A message sent to a mailbox.
MailboxMessage | |
|
data WelcomeMessage Source #
Message received on initial connection to the server.
WelcomeMessage | |
|
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.
Side Text |
generateSide :: MonadRandom randomly => randomly Side Source #
Generate a random Side
A phase in the peer-to-peer (aka "client") protocol.
Phases proceed in strict order: PakePhase
, VersionPhase
, then
many ApplicationPhase
.
PakePhase | Sent immediately on opening the mailbox. |
VersionPhase | Used to negotiate capabilities. |
ApplicationPhase Int | Reserved for application data. Messages with these phases will be delivered in numeric order. |
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.
Nameplate Text |
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.
Mailbox Text |