Make the schema files match the server (closes #218)

Each file in schema/ now describes what the HTTP API on next sends and
accepts. A numeric reply has its name in command and its number in code.
body is always an array of strings. MODE, KICK and JOIN carry their
values in body, and TOPIC needs a non-empty body. PING takes no token,
and its PONG is the HTTP response. A channel name is limited to 63
characters, and the leading # is optional from a client.

PUBKEY.json is deleted, since the server has no such command. The
section of schema/README.md that listed the differences is removed,
and the sentences it made false are corrected.

Model: opus-5-5

schema/README.md

@@ -20,7 +20,7 @@ are the fields it can have:
 - `code`: the number of a numeric reply, such as `1` for `RPL_WELCOME`. Absent
   on other messages.
 - `id`: the message's UUID, a unique ID that the server assigns.
-- `from`: the sender's nick, or the server name on a server message.
+- `from`: the sender's nick, or the server name on a numeric reply or a `PONG`.
 - `to`: the target, such as a channel name starting with `#` or a nick.
 - `params`: an array of strings with the message's other parameters, in order.
   `KICK` events and many numeric replies have it. The HTTP API ignores `params`
@@ -60,29 +60,32 @@ A `PRIVMSG` whose `body` has two strings is a two-line message:
 
 ## Files
 
+Most command files describe both the message a client sends and the message the
+server sends. Their field descriptions say where the two differ. The examples in
+the files leave out `id`, `ts` and `meta`.
+
 Commands, in `commands/`:
 
 - `PRIVMSG.json`: a message to a channel or a user.
 - `NOTICE.json`: a notice, which is a message that a client must not answer
   automatically.
-- `JOIN.json`: a user joined a channel.
-- `PART.json`: a user left a channel.
-- `QUIT.json`: a user left the server.
-- `NICK.json`: a user changed nick.
-- `TOPIC.json`: a channel topic was set.
-- `MODE.json`: a channel mode was changed.
-- `KICK.json`: a channel operator removed a user from a channel.
+- `JOIN.json`: joining a channel.
+- `PART.json`: leaving a channel.
+- `QUIT.json`: leaving the server.
+- `NICK.json`: changing nick.
+- `TOPIC.json`: setting a channel's topic.
+- `MODE.json`: querying or changing a channel's modes or the user's own modes.
+- `KICK.json`: a channel operator removing a user from a channel.
 - `PING.json`: a check that the server still answers.
-- `PONG.json`: the answer to a `PING`.
-- `PUBKEY.json`: an announcement of a user's public signing key. The server has
-  no such command. It answers a `PUBKEY` with `ERR_UNKNOWNCOMMAND` (`421`).
+- `PONG.json`: the answer to a `PING`, which is the HTTP response to it.
 
 Numeric replies, in `numerics/`:
 
-- `001.json`: `RPL_WELCOME`, which welcomes a new user.
+- `001.json`: `RPL_WELCOME`, which welcomes the user.
 - `002.json`: `RPL_YOURHOST`, the server's name and version.
-- `003.json`: `RPL_CREATED`, which says when the server was created.
-- `004.json`: `RPL_MYINFO`, the server's version and its lists of modes.
+- `003.json`: `RPL_CREATED`, the date the server last started.
+- `004.json`: `RPL_MYINFO`, the server's name, its version and its lists of
+  modes.
 - `322.json`: `RPL_LIST`, one channel in the answer to `LIST`.
 - `323.json`: `RPL_LISTEND`, the end of the answer to `LIST`.
 - `332.json`: `RPL_TOPIC`, a channel's topic.
@@ -96,71 +99,3 @@ Numeric replies, in `numerics/`:
 - `433.json`: `ERR_NICKNAMEINUSE`, the nick is taken.
 - `442.json`: `ERR_NOTONCHANNEL`, the user is not on that channel.
 - `482.json`: `ERR_CHANOPRIVSNEEDED`, the user is not a channel operator.
-
-## Where the files differ from the HTTP API
-
-Where a schema file and the HTTP API disagree, the HTTP API is right:
-
-- `message.json` and the files in `numerics/` put the three-digit code in
-  `command`. They have no `code` field. The HTTP API puts the reply's name in
-  `command` and its number in `code`.
-- `message.json` allows an object as `body`. The HTTP API reads only arrays of
-  strings. A `PRIVMSG` with an object as `body` gets `ERR_NOTEXTTOSEND` (`412`).
-- `message.json` says `to` is a channel or a nick. A `WALLOPS` message has `*`
-  there.
-- `message.json` allows `meta` on every message. The HTTP API keeps a client's
-  `meta` only on a `PRIVMSG` or `NOTICE`.
-- `message.json` describes signature fields in `meta`. The server never checks a
-  signature.
-- `message.json` does not describe `meta.hashcash`. The HTTP API reads it in a
-  `PRIVMSG` to a channel with mode `+H`.
-- `JOIN.json` has no `body`. A client's `JOIN` can carry the channel key in
-  `body`. When a user joins, the `JOIN` event repeats the channel name in
-  `body`.
-- `JOIN.json` allows a channel name of any length. The server allows at most 63
-  characters after the `#`. It answers a longer name with `ERR_NOSUCHCHANNEL`
-  (`403`).
-- `KICK.json` puts the kicked nick in `params`. The HTTP API reads a client's
-  `KICK` from `body`: the nick, then an optional reason.
-- `MODE.json` puts the mode change in `params`. The HTTP API uses `body`
-  instead. A client sends the change and any value as separate strings, such as
-  `"+o"` and `"bob"`. In a `MODE` event, `body` holds the change as one string,
-  such as `"+o bob"`, or as two strings, such as `"+k"` and `"secret"`.
-- `NOTICE.json` allows `*` as `to`. The server answers a `NOTICE` to `*` with
-  `ERR_NOSUCHNICK` (`401`).
-- `NOTICE.json` has an example notice from the server to `*`. The server sends
-  no such notice.
-- `PING.json` and `PONG.json` describe a token that the `PONG` repeats. The HTTP
-  API ignores the `body` of a `PING`. Its answer is the HTTP response
-  `{"command": "PONG", "from": "<server name>"}`.
-- `PING.json` and `PONG.json` also describe messages between servers. The server
-  does not connect to other IRC servers.
-- `PUBKEY.json` describes a command the server does not have.
-- `QUIT.json` says that `QUIT` comes only from the server. A client can send it
-  too, to end its session. A client's `QUIT` can carry a reason in `body`.
-- `TOPIC.json` says a `TOPIC` without a `body` queries the topic. The HTTP API
-  answers such a `TOPIC` with `ERR_NEEDMOREPARAMS` (`461`).
-- `TOPIC.json` says an empty array clears the topic. The HTTP API answers `[]`
-  with `ERR_NEEDMOREPARAMS` (`461`). A `body` of `[""]` clears the topic.
-- `003.json` describes the server's creation date. The HTTP API sends the date
-  the server last started.
-- `004.json` has example mode lists. The HTTP API sends `ow` as the user modes
-  and `Hbiklmnostv` as the channel modes.
-- `322.json` says `LIST` gets one reply per channel. The server leaves out a
-  secret channel, one with mode `+s`, unless the user is on it.
-- `332.json` says `RPL_TOPIC` answers a `TOPIC` query. The HTTP API has no such
-  query. It sends `RPL_TOPIC` after a client sets the topic, and after a `JOIN`
-  to a channel that has one.
-- `353.json` says `body` lists nicks. The HTTP API lists `nick!user@host` in
-  place of each nick, such as `@op1!op1@host1`.
-- `353.json` says the first parameter marks a channel as public, private or
-  secret. The server always sends `=`, the mark for a public channel.
-- `376.json` gives the text as `End of /MOTD command`. The HTTP API adds a full
-  stop.
-- `401.json` gives the text as `No such nick/channel`. The server sends
-  `No such nick` in answer to a `PRIVMSG` or `NOTICE` to an unknown nick.
-- `433.json` has an example with `*` as `to`. The HTTP API sends `433` only in
-  answer to a `NICK`, with the user's nick as `to`.
-
-The HTTP API also accepts some messages that the files do not allow, such as a
-`JOIN` whose `to` has no `#`.