First pass docs for rtc capabilities

docs/content/rtc/_index.md

@@ -0,0 +1,36 @@
+---
+title: WebRTC
+anchor: webrtc
+weight: 40
+---
+
+## Configuration
+
+By default web socket servers are bound to port `5648`. 
+The public URL for this server is also defined in the `.env` configuration file under 
+the key value of `PUBLIC_WS_URL`.
+
+Due to how `events` are propagated to users the web socket server also requires
+a special `wss-hmac.secret` file to be in the same directory as the required
+`hmac.secret` file.
+This HMAC is what is used to discern server connections from user connections
+
+## Data structure
+
+Event messages come serialized in JSON form.
+They have the structure of:
+
+```
+{
+	"type": <event-type>,
+	<event-type>: <data-structure>
+}
+```
+
+The full list of supported events are as follows:
+
+* new-message
+* delete-channel
+* create-channel
+* update-nick
+

docs/content/rtc/auth.md

@@ -0,0 +1,29 @@
+---
+title: RTC Authorization
+anchor: rtc-auth
+weight: 41
+---
+
+## For server devs
+
+If you would like to follow the same model that the current build uses for 
+RTC notifications then simply have the REST API server use the `wss-hmac.secret`
+to authenticate a "special" connection to the web socket server which is allowed
+to broadcast messages to the user connections.
+It should be noted that currently user connections that send messages after the
+connection has been established are ignored. _The server is really the only one that 
+can actually broadcast messages to users_.
+
+The architecture for the web socket server is as follows: 
+
+![Basic Architecture](/wss-arch.png)
+
+## For client devs
+
+To authenticate properly you must use the following url structure:
+
+> `<wsurl>/text?jwt=<jwt>`
+
+
+The JWT in the query string is the same JWT used for requests against the REST API.
+The `/text` path listens for changes on all available text channels so even if a 

docs/content/rtc/events.md

@@ -0,0 +1,83 @@
+---
+title: Events
+anchor: events
+weight: 42
+---
+## Pertinent Event Data Structures
+
+This section describes the data you probably care about; the data behind `<data-type>`.
+
+### `new-message`
+
+Each valid `new-message` is completely flat and contains the following fields:
+
+* id: u64
+Public user id
+* time: i64
+
+Unix time-stamp (generated on the server's end)
+
+* content: String
+
+If the content type is `text/plain` then the content _is_ all there is for that message.
+If the content type is another _valid_ type then this field will contain null.
+A second `/message/get?id=<id>` is required. This is done to avoid forcing tons of file data across a network when you don't want it. 
+
+This also gives client devs the choice of putting that network hit behind a button(or some user action) or doing automatically.
+
+
+* content\_type: String
+
+_For valid content-types refer to [/message/send documentation](#messages-ep)_
+
+* author\_id: u64
+
+Public Member id
+
+* channel\_id: u64
+
+Text channel id. It is safe to assume that this field _will_ point to a valid text channel and not a misconfigured voice channel.
+
+* name: String
+
+Public username for that given user
+
+
+### `delete-channel`
+
+Contains only 1 field:
+
+* id: u64
+
+The id of the deleted channel
+
+### `create-channel`
+
+* id: u64
+
+The id of the new channel
+
+* name: String
+
+Name of channel
+
+* description: String | null
+
+Optional description of channel 
+
+* kind: i32
+
+Recall:
+
+* Voice channels := 1
+* Text channels : 2
+
+### `update-nick`
+
+* id: u64
+
+Id of affected user
+
+* name: String
+
+New nickname of user