Lint all MDs files

This commit is contained in:
ChronosX88 2019-12-22 18:39:30 +04:00
parent 50807e52c0
commit 89e14cbcee
Signed by: ChronosXYZ
GPG Key ID: 085A69A82C8C511A
5 changed files with 74 additions and 23 deletions

View File

@ -1,16 +1,22 @@
# Account login by username
## Introduction
This extension is intended for logging into user account on a server by username
## Message type identifiers
- `profile:login`
## Error codes
- 0: limit exceed
- 1: user ID/password isn't valid
## Use cases
*Request*:
```json
{
"id": "abcd",
@ -24,6 +30,7 @@ This extension is intended for logging into user account on a server by username
```
*Response*:
```json
{
"id": "abcd",
@ -38,6 +45,7 @@ This extension is intended for logging into user account on a server by username
```
*<b>Error</b> response*:
```json
{
"id": "abcd",
@ -52,33 +60,40 @@ This extension is intended for logging into user account on a server by username
```
## Business Rules
None.
## JSON Schema
**Payload**
### Payload
- Request:
```typescript
interface LoginRequestPayload {
/**
* The username of account which user wants to login
*/
username: string,
/**
* Password of new account
*/
password: string
}
```
- Response:
```typescript
interface LoginResponsePayload {
/**
* Authentication token which required for various user actions (UUID)
*/
authToken: string,
/**
* Identifier of new user device (created by this login action)
*/

View File

@ -48,7 +48,8 @@ This extension is intended for creating user accounts on a server
}
```
*<b>Error</b> response*:
- Error response:
```json
{
"id": "abcd",

View File

@ -1,14 +1,19 @@
# The Sections of a Cadmium Extension (CE) document
## Introduction
The introduction to a CE document should contain description of the extension and example of problems which this extension can solve.
## Message type identifiers
In this section, specify the identifiers of the new types of protocol messages (which are introduced by the extension)
## Glossary
If your CE document uses terms that may not be familiar to the reader, please define them in this section.
## Use Cases
It is recommended that document authors structure their proposals according to the use cases that the proposal will address. We have found that use cases force authors to focus on functionality rather than "protocol for the sake of protocol". It is also helpful to sort use cases by actor. Include one subsection for each use case.
When writing use cases and the associated protocols, make sure to:
@ -18,6 +23,7 @@ When writing use cases and the associated protocols, make sure to:
* Include lots of protocol examples.
*Example 1. An Example from Shakespeare*
```json
{
"id": "abcd",
@ -29,31 +35,41 @@ When writing use cases and the associated protocols, make sure to:
}
}
```
## Error Codes
If your proposal defines a number of error and status codes, it is a good idea to include a table of all the codes defined in your document.
## Business Rules
You may want to include a section describing various business rules (essentially, a variety of MUSTs, SHOULDs, and MAYs regarding application behavior). This is not required but can be helpful to implementers.
## Implementation Notes
You may want to include a section devoted to implementation notes. Again, this is not required but can be helpful to implementers.
## Internationalization Considerations
If there are any internationalization or localization issues related to your proposal, define them in this optional section.
## Security Considerations
Your proposal MUST include a section entitled "Security Considerations". Even if there are no security features or concerns related to your proposal, you MUST note that fact. For helpful guidelines, refer to RFC 3552.
## JSON Schema
An JSON Schema is required in order for protocols to be approved by the Cadmium Developers. The Cadmium Developers team can assist you in defining an JSON Schema for the protocol you are proposing. Also you can define your schema as TypeScript interfaces, this is also allowed.
## Acknowledgements (optional)
Most CE documents end with a section thanking non-authors who have made significant contributions or who have provided feedback regarding the specification.
# Cadmium Extension Styleguide
## Cadmium Extension Styleguide
CE document are written in English. It is not expected that you will be a fine prose writer, but try to write in a clear, easily-understood fashion.
## Code Examples
### Code Examples
To show the hierarchy of JSON objects, indent two spaces for every level.
If an element possesses a large number of attributes, include a line break before each attribute and indent them so that they are vertically aligned for readability.
@ -61,6 +77,7 @@ If an element possesses a large number of attributes, include a line break befor
If the JSON data of an element is long, include line breaks and indent by two spaces.
*Example*:
```json
{
"id": "abcd",
@ -76,14 +93,19 @@ If the JSON data of an element is long, include line breaks and indent by two sp
}
}
```
Some examples include strings that are the output of a hashing algorithm such as SHA-1 or SHA-256. An easy way to generate these is to use the OpenSSL "dgst" command to generate the hash. For example, the following command will generate the SHA-1 hash `a6cf4baabcefb63189a1a1c56158aa431990bba9`:
```
```bash
echo -n '@juliet@396277b7dcd0f1173f2007baa604de7593529cc3fbf335fb7924851cb25c1fdf' | openssl dgst -hex -sha1
```
Some examples include strings that are encoded using Base64. An easy way to generate these is to use the OpenSSL "enc" command to generate the base64-encoded equivalent. For example, the following command will generate the base64-encoded string `QGp1bGlldEAzOTYyNzdiN2RjZDBmMTE3M2YyMDA3YmFhNjA0ZGU3NTkzNTI5Y2MzZmJmMzM1ZmI3OTI0ODUxY2IyNWMxZmRm`:
```
```bash
echo -n '@juliet@396277b7dcd0f1173f2007baa604de7593529cc3fbf335fb7924851cb25c1fdf' | openssl enc -nopad -base64
```
## Conformance Terms
```
### Conformance Terms
Conformance terms (e.g,, "MUST" and "SHOULD") are specified in RFC 2119. Use them. When such terms are not in ALL CAPS, the special conformance sense does not apply (although it is preferable to use terms such as 'might' instead of 'may' and 'ought' instead of 'should').

View File

@ -6,32 +6,38 @@
- [BaseMessage](#basemessage)
## Transport
For starting we simply use JSON + Websockets.
## Entity ID
* Room alias: `#<roomAlias>@<serverpart>`
* Username: `@<username>@<serverpart>`
* User ID with any 3PID: `%<type>:<data>@<serverpart>`
* Currently supported only following types: `email` and `msisdn`.
* Raw User ID: `@<UUID>@<serverpart>`
* Message ID: `&<uuid>@<serverpart (from which server the message was sent)>`
* Room ID: `!<roomID>@<serverpart>`
* Single server-part: `<serverpart>`
- Room alias: `#<roomAlias>@<serverpart>`
- Username: `@<username>@<serverpart>`
- User ID with any 3PID: `%<type>:<data>@<serverpart>`
- Currently supported only following types: `email` and `msisdn`.
- Raw User ID: `@<UUID>@<serverpart>`
- Message ID: `&<uuid>@<serverpart (from which server the message was sent)>`
- Room ID: `!<roomID>@<serverpart>`
- Single server-part: `<serverpart>`
**Server-part**:
- hostname: `IPv4 / [IPv6] / dns-domain:<port (1-65535)>` (for end-users use)
- server ID: static SHA256 hash string from 4096 characters (for internal protocol use)
**Username/Room alias/RoomID** - MUST NOT be empty, and MUST contain only the characters `a-z`, `0-9`, `.`, `_`, `=`, `-`, and `/`.
**Special business rules**:
- RoomID SHOULD be UUID identifier.
- Servers MUST use server ID in internal purposes instead of normal server-part with hostname. Only end-users MUST use normal server-part with hostname. This is done for easy multi-domain serving.
## BaseMessage
BaseMessage is a basic message model, basis of the whole protocol. It is used for a very easy protocol extension process.
BaseMessage scheme:
```typescript
interface BaseMessage {
/**
@ -63,4 +69,4 @@ interface BaseMessage {
*/
payload: Map<K,V>
}
```
```

View File

@ -1,13 +1,18 @@
# Protocol Errors
## Introduction
Mechanism of error processing included into protocol.
Adds into any response message `ok` variable. If `ok` is true - we have no errors, if `ok` is false - we have an error.
## Message type identifiers
- `*:error`
None.
## Use cases
*Request*:
```json
{
"id": "abcd",
@ -21,6 +26,7 @@ Adds into any response message `ok` variable. If `ok` is true - we have no error
```
*Response*:
```json
{
"id": "abcd",
@ -37,7 +43,8 @@ Adds into any response message `ok` variable. If `ok` is true - we have no error
```
## JSON Schema
**Payload**
### Payload
```typescript
interface ErrorPayload {
@ -56,4 +63,4 @@ interface ErrorPayload {
*/
errPayload: Map<K,V>
}
```
```