Множественные правки и добавления

HANDSHAKE.md

@@ -2,7 +2,8 @@
 
 После успешной установки защищённого соединения, происходит обмен характеристиками обоих сторон, AKA "рукопожатие". Запрашивающий соединение отправляет пакет следующего формата:
 
-`[magic number: 8B][protocol version: 4B][sizes: 1B][crypto params: 6B][reconnection flags: 4B]`
+<!--`[magic number: 8B][protocol version: 4B][sizes: 1B][crypto params: 6B][reconnection flags: 4B]`-->
+`[magic number: 8B][protocol version: 4B][crypto params: 6B][reconnection flags: 4B]`
 
 - Магическое число
 	- _Тип:_ `uint64_t`
@@ -10,7 +11,7 @@
 - Версия протокола
 	- _Тип:_ `uint32_t`
 	- Поддерживаемая запрашивающим версия протокола.
-- Размерности частей пакета
+<!--- Размерности частей пакета
 	- _Тип:_ `uint8_t`
 	- Описывает некоторые параметры пакетов.
 		- Маска `0b11000000`: выделено под размерности типа событий
@@ -28,7 +29,7 @@
 			- `0b01`: размер данных это `uint8_t`
 			- `0b10`: размер данных это `uint16_t`
 			- `0b11`: размер данных это `uint64_t`
-		- Маска `0b00000011`: резерв
+		- Маска `0b00000011`: резерв-->
 - Параметры криптографии
 	- _Тип:_ `CryptoAlgo[3]`
 	- Описывает используемые криптографические алгоритмы на уровне "клиент-сервер". Первый элемент это используемый алгоритм для хэша полезной нагрузки; второй это алгоритм ассиметричного шифрования; третий элемент это алгоритм симметричного шифра.
@@ -74,7 +75,7 @@
 		- 0x02: неподдерживаемая версия протокола.
 		- 0x03: невозможно выделить новый порт для подключения.
 		- 0x04: указанный транспортный протокол не поддерживается.
-		- 0x05: указанная конфигурация размерностей не поддерживается.
+		<!--- 0x05: указанная конфигурация размерностей не поддерживается.-->
 		- 0x06: недопустимые параметры криптографии.
 		- 0x07: один из указанных криптографических алгоритмов отключён на сервере.
 - Описание ошибки

KLDR RESERVED KEYS.md

@@ -1,6 +1,7 @@
 # Список зарезервированных ключей ячеек
 
 <!-- TODO: сделать папку и там разместить подробное описание некоторых ключей -->
+Перечисленные здесь значения являются либо совсем базовыми, либо предназначены для использования сервером. Все данные транзитных пакетов (т.е. тех, которые предназначены для кого-то кроме подключённого напрямую серверу), для которых критична подлинность, должны передаваться в ячейке `Data` и быть подписанными с помощью ячейки `SignedDataHash`.
 
 
 
@@ -46,7 +47,7 @@
 - CryptoAlgos
 	- _Значение:_ `0x11`
 	- _Тип:_ `CryptoAlgo[3]`
-	- Используемые криптографические алгоритмы. Первый элемент выделен под хэш-функцию; второй элемент для ассиметричной функции; третий элемет для симметричной функции.
+	- Используемые криптографические алгоритмы. Первый элемент выделен под хэш-функцию; второй элемент для ассиметричной функции; третий элемент для симметричной функции.
 - CryptoKeyID
 	- _Значение:_ `0x12`
 	- _Тип:_ `uint32_t`

OVERVIEW.md

@@ -1,14 +1,14 @@
 # Спецификация протокола Stadium v1.0
 
-Протокол Stadium это протокол для безопасной коммуникации общего назначения, работающий поверх любого поддерживаемого транспорта. Данная спецификация описывает лишь базу, поверх которой может быть реализованы расширения (SPX - Stadium Protocol eXtension) для более конкретных нужд. Помимо прочего, данный протокол служит основой для полнофункционального мессенджера Marafon, спецификация расширения которого находится в папке `SPX/Marafon/`.
+Stadium это протокол для безопасной коммуникации общего назначения, работающий поверх любого поддерживаемого транспорта. Данная спецификация описывает лишь базу, поверх которой могут быть реализованы расширения (SPX - Stadium Protocol eXtension) для более конкретных нужд. Помимо прочего, данный протокол служит основой для полнофункционального мессенджера Marafon, спецификация расширения которого находится в папке `SPX/Marafon/`.
 
 Основной фокус при работе над сим проектом идёт на:
 
-- Снижение оверхэдов, по сравнению с классическими решениями (Matrix, Discord, WhatsApp, пр. (Reject HTML+JSON, return to binary.)).
-- Устойчивость к цензуре.
-- Федеративность.
-- Поддержка гибкого сквозного шифрования. (возможность как клиенту так и серверу выбирать, какие криптографические алгоритмы использовать)
-- Совместимость со всеми мажорными оверлейными сетями (Tor, I2P и yggdrasil).
+- Снижение оверхэдов, по сравнению с классическими решениями (Matrix, Discord, WhatsApp, пр. (Reject HTML+JSON, return to binary));
+- Устойчивость к цензуре;
+- Федеративность;
+- Поддержка гибкого сквозного шифрования. (возможность как клиенту так и серверу выбирать, какие криптографические алгоритмы использовать;
+- Совместимость со всеми мажорными оверлейными сетями (Tor, I2P и yggdrasil);
 - Расширяемость.
 
 В сей спецификации вы иногда сможете встретить примеры кода и упоминание типов данных языка C++, так как без них обойтись моментами сложно.
@@ -60,7 +60,7 @@
 
 `[cell_1][cell_2][cell_3]...[cell_n]`
 
-Ключ и длинна данных являются шестнадцатеричными числами, размерность которых задаётся на этапе хэндшейка. Полезная нагрузка не может отсутствовать полностью (кроме особо-оговорённых случаев), а ключ не может являться нулём. Если значение конкретной пары пусто, то длинна данных должна быть нулём.
+Ключ и длинна данных являются шестнадцатеричными числами, размерность которых фиксирована и составляет 8 и 16 бит соответственно. <!--задаётся на этапе хэндшейка.--> Полезная нагрузка не может отсутствовать полностью (кроме особо-оговорённых случаев), а ключ не может являться нулём. Если значение конкретной пары пусто, то длинна данных должна быть нулём.
 
 Исходя из всего вышеописанного, итоговая примерная структура пакета выглядит следующим образом:
 
@@ -70,9 +70,9 @@
 
 ### Зарезервированные события
 
-Некоторые категории событий зарезервированы под нужды базового протокола или просто для событий определённого рода. Второе носит рекомендательный характер; вы также можете использовать иные диапазоны для тех-же целей.
+Некоторые категории событий зарезервированы под нужды базового протокола или просто для событий определённого рода. Второе носит рекомендательный характер; вы также можете использовать иные диапазоны для тех-же целей. Ниже приведены диапазоны зарезервированных значений.
 
-Все из зарезервированных типов помещаются в минимальную размерность типа события (т.е. по одному байту на категорию и подкатегорию). Ниже приведены диапазоны зарезервированных значений.
+<!--Все из зарезервированных типов помещаются в минимальную размерность типа события (т.е. по одному байту на категорию и подкатегорию).-->
 
 Зарезервировано для нужд протокола и запрещено к использованию в частных реализациях (см. также файлы в директории `reserved/` для конкретных примеров):
 
@@ -90,7 +90,7 @@
 
 ### Зарезервированные ключи ячеек
 
-У данных в формате KLDR также существуют зарезервированные ключи, которые аналогичным образом помещаются в минимальную размерность ключа:
+У данных в формате KLDR также существуют зарезервированные ключи<!--, которые аналогичным образом помещаются в минимальную размерность ключа-->:
 
 - `0x00`
 	- Запрещено к использованию.
@@ -129,7 +129,7 @@
 
 Первый тип является восьмибайтным числом без знака (`uint64_t`). Валидный объект не может иметь ID равный нулю.
 
-Второй тип является структурой из одного восьмибайтного числа без знака для ID объекта, массива размером 64 байт для дескриптора сервера и однобайтового числа (`uint8_t`) для использованного алгоритма хэширования дескриптора.
+Второй тип является структурой из одного восьмибайтного числа без знака для ID объекта, массива размером 64 байт для дескриптора сервера и двухбайтного числа (`CryptoAlgo`) для использованного алгоритма хэширования дескриптора.
 
 Сервер должен проверять идентификатор на валидность и отвергать его, если он ложен в текущем контексте.
 
@@ -137,7 +137,7 @@
 
 ## Серверный дескриптор
 
-Серверный дескриптор являет из себя хэш открытого ключа серверной подписи и может быть представлен в виде base64-кодированной строки, если необходимо. Длинна хэша может варьироваться от 128 до 512 бит. Используемый алгоритм хэширования определяется сервером-владельцем дескриптора.
+Серверный дескриптор являет из себя хэш открытого ключа серверной подписи и может быть представлен в виде base64-кодированной строки, если необходимо. Длинна хэша может варьироваться, но всегда менее или равно 512 бит. Используемый алгоритм хэширования определяется сервером-владельцем дескриптора.
 
 Дескриптор может быть ассоциирован с несколькими доменами и/или IP/I2P/Tor-адресами, как на стороне сервера, так и на стороне клиента. Клиент может запросить у сервера список ассоциированных с дескриптором адресов, подписанных закрытым ключом сервера-владельца дескриптора и проверить их на достоверность с помощью его-же публичного ключа.
 

README.md

@@ -3,3 +3,5 @@
 Спецификация протокола Stadium и его официального расширения для нашего мессенджера - Marafon SPX.
 
 **ПРОЕКТ В АКТИВНОЙ РАЗРАБОТКЕ/PROJECT UNDER ACTIVE DEVELOPMENT**
+
+All text will be translated to english later.

reserved/METHOD FORMAT EXAMPLE.md

@@ -6,7 +6,7 @@
 
 ## Client2Server
 
-Какое-то описание метода. На данный момент, "оффициально" поддерживается два формата, в которых могут быть представлены данные: KLDR (расположенные последовательно "ключ-длина-значение") и фиксированная схема. Тут представлен пример в формате KLDR.
+Какое-то описание метода. На данный момент, "официально" поддерживается два формата, в которых могут быть представлены данные: KLDR (расположенные последовательно "ключ-длина-значение") и фиксированная схема. Тут представлен пример в формате KLDR.
 
 **Ячейки:**