add ban endpoint, admin api entry in toc, other stuff

spec/README.mediawiki

@@ -10,8 +10,8 @@ with existing systems of exchange.
 
 Currently, the majority of cryptocurrency trading is performed via centralized,
 custodial exchanges.
-These exchanges have fill important role in the blockchain ecosystem, but are in
-many ways antithetical to the spirit of blockchain.
+These exchanges have filled an important role in the blockchain ecosystem, but
+are in many ways antithetical to the spirit of blockchain.
 Blockchain is decentralized, trustless, and enables self-custody, but when a
 user must send their coin to a third party in order to trade, all of those
 benefits are lost.
@@ -34,7 +34,7 @@ familiar interface based on markets and orders. Decred DEX's novel matching
 algorithm disincintevizes manipulative, abusive trading practices commonly seen
 on centralized exchanges. The epoch-based match cycle is difficult to game by
 the client, while for the server, cryptographic order commitments make
-censorship difficult.
+censorship and unfair matching difficult.
 
 While trades are fully trustless, steps are taken to discourage malicious
 clients from hindering normal trade activity.
@@ -87,7 +87,8 @@ the features described above.
 the tasks required to administer the exchange.
 
 * [[admin.mediawiki/#Exchange_Variables|Exchange Variables]]
-* [[admin.mediawiki/#Per_Asset_Variables|Per-asset Variables]]
+* [[admin.mediawiki/#Perasset_Variables|Per-asset Variables]]
+* [[admin.mediawiki/#Administration_API|Administration API]]
 
 '''[4] [[accounts.mediawiki|Client Accounts]]''' details account creation.
 
@@ -116,7 +117,7 @@ book and place orders.
 * [[orders.mediawiki/#Match_negotiation|Match Negotiation]]
 * [[orders.mediawiki/#Trade_Suspension|Trade Suspension]]
 
-'''[6] [[api.mediawiki| Data API]]''' defines http and websocket APIs to browse
+'''[6] [[api.mediawiki| Data API]]''' defines http and WebSocket APIs to browse
 trade history.
 
 '''[7] [[atomic.mediawiki|Atomic Settlement]]''' walks through the settlement

spec/accounts.mediawiki

@@ -13,7 +13,7 @@ string in API messages.
 
 ==Step 1: Registration==
 
-The user creates a websocket connection and sends their
+The user creates a WebSocket connection and sends their
 [[fundamentals.mediawiki/#Identities_based_on_Public_Key_Infrastructure_PKI_Key_Pairs|public account key]].
 The message is signed with the corresponding private account key. The response
 includes the server's public key. The server's public key will also be

spec/admin.mediawiki

@@ -56,14 +56,16 @@ The server will provide an HTTP API for performing various adminstrative tasks.
 | /config   || the current DEX configuration. See [[fundamentals.mediawiki/#Configuration_Data_Request|Configuration Data Request]]
 |-
 | /accounts || lists information about all known accounts
-| -
+|-
 | /accounts/{accountID} || list information about a specific account
-| -
+|-
 | /markets  || display status information for all markets
-| -
+|-
 | /market/{marketID} || display status information for a specific market
-| -
+|-
 | /market/{marketID}/suspend || schedule a market suspension at the end of the current epoch
-| -
+|-
 | /unban/{accountID} || clear an account's penalties and re-enable trading
+|-
+| /ban/{accountID}/{ruleNumber} || ban an account for violating [[community.mediawiki/#Rules_of_Community_Conduct|a rule]]
 |}

spec/api.mediawiki

@@ -2,4 +2,4 @@
 
 __TOC__
 
-Trade history will be made available to both websocket and HTTP clients.
+Trade history will be made available to both WebSocket and HTTP clients.

spec/comm.mediawiki

@@ -11,14 +11,14 @@ Match notification via HTTP polling or other request interval-based methods are
 thus not suitable for the DEX system.
 Persistent, full-duplex communication is critical to minimizing communication
 latencies and wasted bandwidth.
-Websockets ([https://tools.ietf.org/html/rfc6455 [3]]) are chosen as the
+WebSockets ([https://tools.ietf.org/html/rfc6455 [3]]) are chosen as the
 default and preferred communications protocol for
 the DEX exchange API.
 In addition to fulfilling the aforementioned needs, Websockets are now a
 well-established technology with client software available for integration in
 virtually all popular programming languages.
 
-Websocket messages are secured by encryption on Transport Layer
+WebSocket messages are secured by encryption on Transport Layer
 Security (TLS) [https://tools.ietf.org/html/rfc8446 [4]] connections.
 
 ==Encoding==
@@ -30,6 +30,9 @@ units of time are milliseconds unless otherwise specified. Location-independent
 timestamps are encoded as milliseconds since the UNIX epoch (Jan 01 00:00:00
 1970 UTC).
 
+If a timestamp must be converted to seconds, e.g. for encoding as a locktime in
+a swap contract, the timestamp should be rounded down.
+
 ===Rate Encoding===
 
 Because the rate assigned to a limit order is a quotient, the value is naturally
@@ -145,7 +148,7 @@ The payload for a response has a structure that enables quick error checking.
 
 ==Session Authentication==
 
-Many DEX messages must be sent on an authenticated connection. Once a websocket
+Many DEX messages must be sent on an authenticated connection. Once a WebSocket
 connection is established, the client will supply their account ID and signature.
 
 '''Request route:''' <code>connect</code>, '''originator: ''' client
@@ -182,15 +185,17 @@ the client's absence. A list of any pending matches is included in the response.
 
 <code>result</code>
 {|
-! field      !! type   !! description
+! field   !! type   !! description
+|-
+| matches || &#91;object&#93; || list of [[orders.mediawiki/#Match_negotiation|Match objects]]
 |-
-| matches    || &#91;object&#93; || list of [[orders.mediawiki/#Match_negotiation|Match objects]]
+| sig     || string || hex-encoded server's signature of serialized the serialized connection data
 |}
 
 ==HTTP==
 
 An API using HTTP for message transport may be provided for basic account
-management and server status queries, however websocket connections are to be
+management and server status queries, however webWebSocketsocket connections are to be
 the sole means for
 [[orders.mediawiki/#Client_Order_Management|placing, monitoring, and executing orders]].
 The primary reason for limiting the scope of the HTTP API is to eliminate client

spec/orders.mediawiki

@@ -156,7 +156,7 @@ independently verify matching.
 |}
 
 A client can '''unsubscribe''' from order book updates without closing the
-websocket connection.
+WebSocket connection.
 
 '''Request route:''' <code>unsub_orderbook</code>, '''originator: ''' client
 
@@ -633,7 +633,7 @@ transaction and inform the server with an <code>init</code> notification
 |-
 | side      || int    || the client's side in the match. 0 = maker, 1 = taker
 |-
-| status    || int    || only provided in 'connect' response. See [[https://github.com/decred/dcrdex/blob/master/dex/order/match.go|match.go]] for codes.
+| status    || int    || only provided in 'connect' response. For 'match' requests, status is 0 = 'MakerSwapCast'. See [[https://github.com/decred/dcrdex/blob/master/dex/order/match.go|match.go]] for codes.
 |-
 | sig       || string || DEX's hex-encoded signature of the serialized notification data. serialization described below
 |}