WebSocket Chat ============== `wschat` is very simple [WebSocket][] chat server. The project is published under [AGPLv3 License][]. `wschat` does **NOT** support encryption or direct/group messaging. Please, think about `wschat` as *real-time public (moderated) mailing list without history*. Anyone can join to the server and listen to all the messages. [WebSocket]: https://en.wikipedia.org/wiki/WebSocket [AGPLv3 License]: ./LICENSE Messaging ========= When a WebSocket is opened, the server expects (at least) the following fields in a JSON message: { "usr": "Chat user", "msg": "Message from that user" } Then, the server updates the message with current UTC date/time: { "usr": "Chat user", "msg": "Message from that user", "tim": "2020-08-11T22:26:58.118678679Z" } And sends the message to all the opened WebSockets (including the sending one.) JWT validation -------------- If the server is run with `JWT_SECRET` environment variable, it expects another field in the JSON message: { "usr": "Chat user", "jwt": "Encoded JWT here", "msg": "Message from that user" } Then, the server decode each message with `JWT_SECRET` and sends the message only if the docode is successful. This validation does not concern expiration field `exp`. **NOTE:** This is for sending messages only! Anyone connected to the server can receive all the messages, though. Client ====== See `static` directory to check out a simple `wschat` client example. Contribute ========== Use [OneFlow][1] branching model and keep the [changelog][2]. Write [great git commit messages][3]: 1. Separate subject from body with a blank line. 2. Limit the subject line to 50 characters. 3. Capitalize the subject line. 4. Do not end the subject line with a period. 5. Use the imperative mood in the subject line. 6. Wrap the body at 72 characters. 7. Use the body to explain what and why vs. how. When adding feature or hotfix, use [Test-driven development (TDD)][4]: 1. Add unit test and skeleton. 2. Run tests (`cargo test`), check that the test *fail*. 3. Code now. Implement functionality. 4. Run tests again, check that the test *pass*. 5. Refactor. Document new functions, methods, structs, and files. Use *Examples* section as basic unit tests. [1]: https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow [2]: ./CHANGELOG.md [3]: https://chris.beams.io/posts/git-commit/ [4]: https://en.wikipedia.org/wiki/Test-driven_development