From 222dc7162616bd90548534c86569cb44d188dad1 Mon Sep 17 00:00:00 2001
From: bt <bt@rctt.net>
Date: Sun, 29 Mar 2026 18:44:43 +0200
Subject: [docs] Fix typos

---
 docs/rfc.html    | 34 +++++++++++++++++-----------------
 docs/rfc.md      | 22 +++++++++++-----------
 docs/rfc.txt     | 26 +++++++++++++-------------
 hooks/pre-commit |  2 ++
 4 files changed, 43 insertions(+), 41 deletions(-)

diff --git a/docs/rfc.html b/docs/rfc.html
index 42c570a..796825f 100644
--- a/docs/rfc.html
+++ b/docs/rfc.html
@@ -1304,7 +1304,7 @@ SOLEC system.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
             <p id="section-toc.1-1.1.1"><a href="#section-1" class="auto internal xref">1</a>.  <a href="#name-introduction" class="internal xref">Introduction</a></p>
 <ul class="compact toc ulBare ulEmpty">
 <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.1">
-                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="auto internal xref">1.1</a>.  <a href="#name-decentralization" class="internal xref">Decentralization</a></p>
+                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="auto internal xref">1.1</a>.  <a href="#name-decentralisation" class="internal xref">Decentralisation</a></p>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.2">
                 <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="auto internal xref">1.2</a>.  <a href="#name-user-to-user-communication" class="internal xref">User to user communication</a></p>
@@ -1364,7 +1364,7 @@ SOLEC system.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
                 <p id="section-toc.1-1.2.2.5.1"><a href="#section-2.5" class="auto internal xref">2.5</a>.  <a href="#name-sequential-operations" class="internal xref">Sequential operations</a></p>
 <ul class="compact toc ulBare ulEmpty">
 <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.5.2.1">
-                    <p id="section-toc.1-1.2.2.5.2.1.1"><a href="#section-2.5.1" class="auto internal xref">2.5.1</a>.  <a href="#name-connection-initialization" class="internal xref">Connection initialization</a></p>
+                    <p id="section-toc.1-1.2.2.5.2.1.1"><a href="#section-2.5.1" class="auto internal xref">2.5.1</a>.  <a href="#name-connection-initialisation" class="internal xref">Connection initialisation</a></p>
 </li>
                 </ul>
 </li>
@@ -1386,13 +1386,13 @@ decentralised communication designed for low-speed networks. It uses binary
 protocol to keep required bandwidth as low as possible.<a href="#section-1-2" class="pilcrow">¶</a></p>
 <p id="section-1-3">Current implementation works on top of TCP/IP stack. In future, SOLEC will be
 adapted to work over LoRa.<a href="#section-1-3" class="pilcrow">¶</a></p>
-<div id="decentralization">
+<div id="decentralisation">
 <section id="section-1.1">
-        <h3 id="name-decentralization">
-<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-decentralization" class="section-name selfRef">Decentralization</a>
+        <h3 id="name-decentralisation">
+<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-decentralisation" class="section-name selfRef">Decentralisation</a>
         </h3>
-<p id="section-1.1-1">Recurring problem with modern day instant messaging is its centralization.
-SOLEC solves is it in similair fashion to XMPP or SMTP. SOLEC servers exchange
+<p id="section-1.1-1">Recurring problem with modern day instant messaging is its centralisation.
+SOLEC solves is it in similar fashion to XMPP or SMTP. SOLEC servers exchange
 messages between each other so the users using server A can reach out users
 using server B.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
 </section>
@@ -1445,12 +1445,12 @@ client-server connection can be achieved using TLS.<a href="#section-2-1" class=
 <ul class="normal">
 <li class="normal" id="section-2.1-4.1">
             <p id="section-2.1-4.1.1">Type (8):
-Payload type is indicated by 1 octed which gives 256 types that can be
+Payload type is indicated by 1 octet which gives 256 types that can be
 represented.<a href="#section-2.1-4.1.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-2.1-4.2">
             <p id="section-2.1-4.2.1">Length (16):
-Payload length is 2 octets. It indicates lenght of the payload field.
+Payload length is 2 octets. It indicates length of the payload field.
 The length does not include type and length fields.<a href="#section-2.1-4.2.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-2.1-4.3">
@@ -1475,7 +1475,7 @@ does not carry any data.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
         <h3 id="name-data-types">
 <a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-data-types" class="section-name selfRef">Data types</a>
         </h3>
-<p id="section-2.3-1">Data typres are basic types that are used in construction of more comples
+<p id="section-2.3-1">Data types are basic types that are used in construction of more complex
 payload types.<a href="#section-2.3-1" class="pilcrow">¶</a></p>
 <div id="numeric-types">
 <section id="section-2.3.1">
@@ -1540,7 +1540,7 @@ Text is encoded using UTF-8.<a href="#section-2.3.3-1" class="pilcrow">¶</a></p
         </h3>
 <p id="section-2.4-1">Payload type attributes describes following characteristics:<a href="#section-2.4-1" class="pilcrow">¶</a></p>
 <ul class="compact">
-<li class="compact" id="section-2.4-2.1">R - Reserved: implementattion should ignore payloads of this type<a href="#section-2.4-2.1" class="pilcrow">¶</a>
+<li class="compact" id="section-2.4-2.1">R - Reserved: implementation should ignore payloads of this type<a href="#section-2.4-2.1" class="pilcrow">¶</a>
 </li>
           <li class="compact" id="section-2.4-2.2">S - Server: can be send only by a server<a href="#section-2.4-2.2" class="pilcrow">¶</a>
 </li>
@@ -1730,16 +1730,16 @@ should ignore this kind of payload.<a href="#section-2.4.6-1" class="pilcrow">¶
         <h3 id="name-sequential-operations">
 <a href="#section-2.5" class="section-number selfRef">2.5. </a><a href="#name-sequential-operations" class="section-name selfRef">Sequential operations</a>
         </h3>
-<p id="section-2.5-1">Some perations require multiple rounds of communication.
+<p id="section-2.5-1">Some operations require multiple rounds of communication.
 In this case payloads are send in a sequence. Payload that is not part of this
-specific operation (for example incomming message) cannot interrupt this process.<a href="#section-2.5-1" class="pilcrow">¶</a></p>
-<div id="connection-initialization">
+specific operation (for example incoming message) cannot interrupt this process.<a href="#section-2.5-1" class="pilcrow">¶</a></p>
+<div id="connection-initialisation">
 <section id="section-2.5.1">
-          <h4 id="name-connection-initialization">
-<a href="#section-2.5.1" class="section-number selfRef">2.5.1. </a><a href="#name-connection-initialization" class="section-name selfRef">Connection initialization</a>
+          <h4 id="name-connection-initialisation">
+<a href="#section-2.5.1" class="section-number selfRef">2.5.1. </a><a href="#name-connection-initialisation" class="section-name selfRef">Connection initialisation</a>
           </h4>
 <ul class="compact">
-<li class="compact" id="section-2.5.1-1.1">Client: Initialize TCP connection.<a href="#section-2.5.1-1.1" class="pilcrow">¶</a>
+<li class="compact" id="section-2.5.1-1.1">Client: Initialise TCP connection.<a href="#section-2.5.1-1.1" class="pilcrow">¶</a>
 </li>
             <li class="compact" id="section-2.5.1-1.2">Client:  Send <em>handshake</em>.<a href="#section-2.5.1-1.2" class="pilcrow">¶</a>
 </li>
diff --git a/docs/rfc.md b/docs/rfc.md
index 089d93f..db79839 100644
--- a/docs/rfc.md
+++ b/docs/rfc.md
@@ -42,10 +42,10 @@ protocol to keep required bandwidth as low as possible.
 Current implementation works on top of TCP/IP stack. In future, SOLEC will be
 adapted to work over LoRa.
 
-## Decentralization
+## Decentralisation
 
-Recurring problem with modern day instant messaging is its centralization.
-SOLEC solves is it in similair fashion to XMPP or SMTP. SOLEC servers exchange
+Recurring problem with modern day instant messaging is its centralisation.
+SOLEC solves is it in similar fashion to XMPP or SMTP. SOLEC servers exchange
 messages between each other so the users using server A can reach out users
 using server B.
 
@@ -82,11 +82,11 @@ SOLEC is using Type Length Value (TLV) structure for data exchange.
 Figure: SOLEC PDU Layout
 
 * Type (8):
-Payload type is indicated by 1 octed which gives 256 types that can be
+Payload type is indicated by 1 octet which gives 256 types that can be
 represented.
 
 * Length (16):
-Payload length is 2 octets. It indicates lenght of the payload field.
+Payload length is 2 octets. It indicates length of the payload field.
 The length does not include type and length fields.
 
 * Payload (variable):
@@ -100,7 +100,7 @@ does not carry any data.
 
 ## Data types
 
-Data typres are basic types that are used in construction of more comples
+Data types are basic types that are used in construction of more complex
 payload types.
 
 ### Numeric types
@@ -146,7 +146,7 @@ Figure: String Layout
 
 Payload type attributes describes following characteristics:
 
-* R - Reserved: implementattion should ignore payloads of this type
+* R - Reserved: implementation should ignore payloads of this type
 * S - Server: can be send only by a server
 * C - Client: can be send only by a client
 * E - Empty: signals an event but does not carry any data
@@ -248,13 +248,13 @@ should ignore this kind of payload.
 
 ## Sequential operations
 
-Some perations require multiple rounds of communication.
+Some operations require multiple rounds of communication.
 In this case payloads are send in a sequence. Payload that is not part of this
-specific operation (for example incomming message) cannot interrupt this process.
+specific operation (for example incoming message) cannot interrupt this process.
 
-### Connection initialization
+### Connection initialisation
 
-- Client: Initialize TCP connection.
+- Client: Initialise TCP connection.
 - Client:  Send *handshake*.
 - Server: If *major* version of protocol differs close the connection.
 - Server: Otherwise send *handshake*.
diff --git a/docs/rfc.txt b/docs/rfc.txt
index a53f170..8d889df 100644
--- a/docs/rfc.txt
+++ b/docs/rfc.txt
@@ -15,7 +15,7 @@ Abstract
 Table of Contents
 
    1.  Introduction
-     1.1.  Decentralization
+     1.1.  Decentralisation
      1.2.  User to user communication
      1.3.  Channels
    2.  Network protocol
@@ -33,7 +33,7 @@ Table of Contents
        2.4.5.  Message
        2.4.6.  Test
      2.5.  Sequential operations
-       2.5.1.  Connection initialization
+       2.5.1.  Connection initialisation
 
 1.  Introduction
 
@@ -47,10 +47,10 @@ Table of Contents
    Current implementation works on top of TCP/IP stack.  In future,
    SOLEC will be adapted to work over LoRa.
 
-1.1.  Decentralization
+1.1.  Decentralisation
 
    Recurring problem with modern day instant messaging is its
-   centralization.  SOLEC solves is it in similair fashion to XMPP or
+   centralisation.  SOLEC solves is it in similar fashion to XMPP or
    SMTP.  SOLEC servers exchange messages between each other so the
    users using server A can reach out users using server B.
 
@@ -85,10 +85,10 @@ Table of Contents
 
    Figure: SOLEC PDU Layout
 
-   *  Type (8): Payload type is indicated by 1 octed which gives 256
+   *  Type (8): Payload type is indicated by 1 octet which gives 256
       types that can be represented.
 
-   *  Length (16): Payload length is 2 octets.  It indicates lenght of
+   *  Length (16): Payload length is 2 octets.  It indicates length of
       the payload field.  The length does not include type and length
       fields.
 
@@ -103,8 +103,8 @@ Table of Contents
 
 2.3.  Data types
 
-   Data typres are basic types that are used in construction of more
-   comples payload types.
+   Data types are basic types that are used in construction of more
+   complex payload types.
 
 2.3.1.  Numeric types
 
@@ -145,7 +145,7 @@ Table of Contents
 
    Payload type attributes describes following characteristics:
 
-   *  R - Reserved: implementattion should ignore payloads of this type
+   *  R - Reserved: implementation should ignore payloads of this type
    *  S - Server: can be send only by a server
    *  C - Client: can be send only by a client
    *  E - Empty: signals an event but does not carry any data
@@ -249,14 +249,14 @@ Table of Contents
 
 2.5.  Sequential operations
 
-   Some perations require multiple rounds of communication.  In this
+   Some operations require multiple rounds of communication.  In this
    case payloads are send in a sequence.  Payload that is not part of
-   this specific operation (for example incomming message) cannot
+   this specific operation (for example incoming message) cannot
    interrupt this process.
 
-2.5.1.  Connection initialization
+2.5.1.  Connection initialisation
 
-   *  Client: Initialize TCP connection.
+   *  Client: Initialise TCP connection.
    *  Client: Send _handshake_.
    *  Server: If _major_ version of protocol differs close the
       connection.
diff --git a/hooks/pre-commit b/hooks/pre-commit
index 8336947..67a1b19 100755
--- a/hooks/pre-commit
+++ b/hooks/pre-commit
@@ -9,6 +9,8 @@ cd $(git rev-parse --show-toplevel)
 echo "Building docs"
 make -C docs txt
 make -C docs html
+git add docs/rfc.html
+git add docs/rfc.txt
 
 echo "Running tests before commit to main"
 go test ./...
-- 
cgit v1.2.3